A few weeks ago, a junior Scrum Master asked me for a check-list of tasks for starting a new Agile project. I'm not a fan of check-lists, but this topic seemed appropriate, and useful. It also is a good one to ask for feedback and additions - what would you add to this?
My starting point would be to imagine what a Scrum Master should ask or do when beginning a new, long-term engagement (at least 6 months) at a client location, with a team who don't know each other or Agile methods! Here goes....
- What is the security, building pass, access times policies of the client location?
- What is the Desk policy? What furniture is available - can you bring in more?
- Can you use the client’s printers, scanners, video conference, rooms, stationary?
- Network, Wi-Fi, Servers, databases infrastructure: Can you use the client’s or bring your own? Who supports them?
- Can the team sit together? Who else is around? Can you control how hot/cold, bright/dark, noisy it is?
- What can be used as a physical Scrum board? Can you stick stuff on the walls?
- Do you have a TV or projector for reviews, etc.
- Find a Talk token, get a notice board, hang posters, calendars, etc.
Assuming the team doesn’t know each other, it is important to create good social relationships first to then build them as a team with a shared understanding, culture and skill base to prepare for development work. Try to get them from ‘forming’, through ‘storming’ to ‘performing’ as easily and quickly as possible…
- Use team games for Introductions, get to know each other, team socializing
- What snacks, food, music, dress code is acceptable? Not everyone welcomes donuts!
- Collect and publish team contact info, locations (virtual and physical)
- Agree and publish the team’s availability – including PO & SM
- Agree working agreements
- What are the core working hours of the team?
- How to deal with holiday, illness, and absence requests, etc.
- Coaching ‐”Shu Ha Ri”
- This is a good time to offer some Agile coaching to the team to raise their awareness of their Agile journey, for example, through “Shu Ha Ri”. This helps sets the culture of realistic expectations, improvements, coaching…
- Training. This is also a good time to organize some basic / refresher training in the following topics to bring everyone to the same understanding.
- How to behave as an “Excellent team”
- Effective Story breakdown techniques
- What Tools will we use e.g. for CI, Jira, etc.
- Values: Now the team is forming, what values will it embody?
- E.g. Commitment, Focus, Openness, Respect, Courage?
- Pick a Team name, create some culture
- On-boarding. When new team members join, how will they be brought up to speed? Can the training, teams values be documented? Use a buddy system?
- Future Retro: Now the team has formed, get them to start looking forward to the work ahead in terms of outcomes. A nice way to do this is to hold a retrospective looking forward to the future, asking “What would you like to celebrate at the end of the project?” The focus should be not only on what they deliver, but how the team delivers, how they behave when issues come along, what the client/users/managers will say about them. It also helps practice their first retro in a safe environment.
- Practice review – PO and team: Similar to the future retro, hold a practice review to find out how to hold effective reviews. Important stakeholders should be attending, so make it as good as it can be. How are the team’s presenting skills? What room and setup is best? What progress indicators will the team show? The review subject can be all the activities the team has done so far.
4.Ready to Sprint
After building a functioning, informed team, the final stage is to get ready to Sprint, to identify the specifics of Scrum and the vision and existing backlog of the project. These should be carried out by the team collaboratively:
- Choose an Estimation scale (e.g. Fibonacci) and Identify stories as references
- Write the Definitions of Ready and Done, and publish them
- Choose a Sprint length and schedule, including:
- Sprint Start day
- Planning location
- Daily stand-up time and place
- Review, retro
- Backlog refinement
- Product Vision, Features, Non-functional requirements. This is where the Product Owner can now step forward and introduce the team to the specifics of the product, presenting the business situation, current backlog, risks etc.
- Milestones, phases, release plan: How has the product schedule been planned – e.g. Discovery, Alpha, Beta?
- What Metrics will the team publish? What is their audience, their ownership and frequency?
One of the key parts to a Scrum Master’s role is to guide the team’s success and productivity, and the most important part of this is when the members first come together. Once these points have been met, the team will be in a great place to start development and negotiate the challenges during the lifetime of the project.
But is there anything more that should be included? What would you add or change for your teams? please add your comments below.