New Scrum Team Bootup

“We place the highest value on actual implementation and taking action. There are many things one doesn’t understand and therefore, we ask them why don’t you just go ahead and take action, try to do something? You realize how little you know and you face your own failures and you simply can correct those failures and redo it again and at the second trial you realize another mistake or another thing you didn’t like so you can redo it once again. So by constant improvement, or, should I say, the improvement based upon action, one can rise to the higher level of practice and knowledge”.

You need to startup a new scrum team asap. The new team members come from a diverse set of backgrounds, experience and skill levels. What to do, and where to begin?

1. Training – One persons scrum is another persons recipe for chaos. Get everyone on the same page with the general scrum framework we want to adopt.
2. Product vision – introduce the team to what we expect them to build together – vision, architecture and major feature capabilities.
3. Team building – start the process of building the team by getting everyone to know each other and establishing trust. There are many team exercises available for this purpose. However one simple approach might be to go around the room and have everyone talk about themselves for five minutes – life history, family, formative experiences, what motivates/de-motivates them, interests (both professional and personal), goals (both professional and personal) for the next three years. If the team members have already been working together in some fashion, ask everyone to share one thing about them that no-one knows (I play the bagpipes …). Encourage a bit of risk-taking and exposing of one or two vulnerabilities.
4. Build an initial product backlog. The product backlog will be the single source for all work done by the team. It is a list of requirements or product features, supplied and prioritized by the product owner. One of team’s first jobs will be to refine this backlog to level of detail where the backlog items are sufficiently well understood that they can be estimated with reasonable confidence, and can be completed to a definition of done within the sprint time-box.  The team will need to agree on a definition of ready for backlog items so that they can be pulled into a sprint. The team should strive to have at least 2 sprints worth of ready items in place before planning their first sprint.
5. Team agreements – work on team norms, definitions of ‘ready’ and ‘done’. Clarify roles and responsibilities (scrum master vs. program manager vs. line manager). It might also be useful for teams to define how they will run their backlog grooming, sprint planning and retrospective meetings. Make sure you have a good facilitator to assist with this – make sure every voice is heard.  When done, get each agreement written up and displayed in a team room or someplace that the team will meet regularly (not stored away on Sharepoint or Confluence). Agreements are not carved in stone but always subject to revision or addition by the team.
6. Get started – there are many other things that could be done but at this point the best thing for the team to continue their learning will be to jump in and make a start. Get some initial sprints under the belts and learn what it takes to get through an iteration successfully. Above all, start easy and do not over-commit – learn how to complete an iteration successfully – deliver something valuable that meets the definition of ‘done’. Once that is done work up to a steady pace and attempt to establish a stable velocity.