In those times when I have had more time to work with a team to get them started, I have used the following general outline and found it working. By working I mean, it has struck a good balance between effort invested and value delivered. Investing more time could make things even faster, but not proportionally. Investing less time would reduce value and impact disproportionately. You know.

The Plan for Team’s First Sprints

* Pre-game *

1) Kick-off meeting on first day, to get started (this is more
facilitation than training), including

  • What are the things we don’t know? How critical are they to know before we start Sprint 1?
  • How do we learn together?

2) High level conversations – concept, requirements, UX, design, architecture, technologies, …

3) Initial release planning workshop

  • Vision clarification
  • Writing out user stories
  • Analyzing the stories for consequences, value, risk, possibly also dependencies
  • Building initial release plan

4) Add detail to high priority stories, doing research on unknown stuff (from step 1)

  • Coaching for collaborative design

* First Sprint *

5) Sprint planning for Sprint 1, including coaching on good conversations to have

6) Run the first Sprint

  • Including a couple of refinement meetings to clarify backlog

7) Review and retrospective for Sprint 1

* Second Sprint *

8) Sprint planning for Sprint 2

9) Run the second Sprint

  • Including story estimation workshop and first version of the release burn-up
  • Including more refinement meetings

10) Review and retrospective for Sprint 2

* Third Spring and onwards *

11) Sprint planning for next Sprint

12) Run the next Sprint

  • Including more refinement meetings

13) Review and retrospective for next Sprint

The Coaching Plan Itself

The coaching plan below assumes:

  • There is one team to coach
  • More frequent participation is not possible due to e.g. budget or travel
  • Two week pre-game, two-week sprints
  • Days counted as 5 days per week
  • The project has a SM who can carry the duties while coach is away
  • The team can learn (or already know) the technical practices on their own

Week 1 – days 1 & 2

Facilitate a 1) Kick-Off Meeting to get people to know each other and aligned on shared goal.

Run 2) High-Level Conversations (possibly at least partly on same day, depending on project size), and help teams have good conversations and get started effectively.

Week 2 – day 6

Facilitate 3) Initial Release Planning Workshop with PO, Team, and key stakeholders. Instruct how to refine stories during the other days of the week ( 4) Add Detail to High-Level Stories ).

Week 3 – day 11

Facilitate 5) Sprint Planning for First Sprint.

Train for 6) Run the First Sprint.

Week 5 – Day 21 (possibly extending to day 22)

Facilitate 7) Review and Retrospective for Sprint 1, 8) Sprint Planning for Sprint 2 and 9) Run the Second Sprint.

Coaching on topics the team feels they like help.

Week 7 – Day 31

Facilitate 10) Review and Retrospective for Sprint 2 and 11) Sprint Planning for Next Sprint.

Ensure the team, SM & PO are ready for a two-sprint stretch on their own ( 12) Run the Next Sprint). Prepare them appropriately.

Week 11 – Day 51

Facilitate 13) Review and Retrospective for Next Sprint and 11) Sprint Planning for Next Sprint.

Discuss with team how they plan to go from here on their own (with remote support, as needed).

Further visits are agreed if the team wishes more support (like every 1-3 months or so).

Conversations with, coaching and training management people has to be considered separately.

Conclusion of the above:

  • 7-8 coaching days, 6 visits
  • Expectation is that PO, Team and SM can operate as a well-functioning Scrum team independently after the coaching period, with proper practices and a jelled team.
  • If there is a lot of legacy, the process probably takes a bit longer.

Possible cost-cutting opportunities (with reduced impact / outcome):

Skip the visit on week 2, and do 3) Initial Release Planning Workshop on the same visit as 1) Kick-Off Meeting & 2) High-Level Conversations.

  • Negative impact: the team hasn’t had enough time to familiarize with project information, can be mitigated with up-front study before kick-off.

On week 5, have everything in one day, even if it takes longer.

  • Negative impact: people get tired and the planning quality suffers. No real mitigation strategy (coffee doesn’t count ? ).

Longer term goals

Teach someone (like the SM from the first project) to be able to coach new teams (instead of external coach). Then start building a community of SM’s who know the process and can run the process for their teams.

Interested team members start helping other teams in adopting good engineering practices and team behaviors.

Management learns how to support these Agile teams, and barriers for effective operation are removed as they are found.