Tips from the trenches: How to startup three new Scrum teams simultaneously.

Introduction

I was hired by a bank to help them to get started with agile and Scrum. The department had assembled business employees to become three teams. Most people who see the value of the Scrum Master role will agree that a seasoned Scrum Master can support up to three experienced teams when sprinting. But is one Scrum Master enough to start up three teams from scratch simultaneously? Yes! In this article you will read a detailed review of how I achieved this.

Startup program details

The Kick-off

We organized a four hour kick-off session to introduce the change. This session would inform all future team members as well as members of the works council. We chose for a physical, 1,5 meter covid-proof session with drinks and snacks. We planned this workshop just before the summer break to make sure we could inform (almost) all people impacted by this change. This would also give them some time to think about the initiative and its consequences.

The head of department opened the workshop by explaining his vision and the reasons for starting this initiative. The three Product Owners, one for each team, shared their future plans by presenting their roadmaps and goals. I took the opportunity to present myself as the Agile Coach facilitating the change and explained in a couple of words the essence of working with Scrum. We concluded the workshop with a sailboat-session to collect and discuss the group’s current challenges. This data allowed us to verify if the Scrum initiative actually might solve the problems we were facing.

• 

I prepared a schedule to startup the three teams consecutively (near-simultaneously). Each team followed a one-week startup program with my full-time support, one team after the other. There were three teams which made it easier to work with three-week Sprints during the startup phase. I’d figure out a way to synchronize the teams later. Before the summer break, I asked the PO’s to prepare a vision and mission statement and create an initial Product Backlog.

The agenda for the one-week startup program contained the following activities:

Day1

• Welcome and check-in using ESVP. Some people brought their laptops and had tasks that needed attention. I needed to make sure everybody was ready to participate and focus on the startup activities. We agreed to plan on a couple of time-slots during the day for them to work on those tasks.
• An icebreaker using random question cards to create some laughter and fun.
• I shared the planned two-day team startup activities and asked everybody if they had any other appointments. Never assume the obvious: Some people did not have an empty agenda. I tried to accommodate the schedule where possible. (In all teams I noticed that all agendas were cleared later that day out of free will. People saw the importance of their attendance and didn’t want to miss a thing.)
• We did a team-member introduction round because most people were colleagues but did not know each other that well.
• I asked all team members to share their “best team experience ever” using the Appreciative Interview technique. This exercise makes people share positive team experiences, helps them to define their core powers and drives and reveals what they need from a team to perform at their best. This is a great way to get positive energy flowing.
• We compiled team agreements. When the team agreements did not come easily, I used the Liberating Structures Triz technique: “How can we sabotage our team success?”.
• The PO clarified mission and vision to ensure everybody understood why this team was being created. I noticed that in every team, the mission (as proposed by the PO) was reformulated with the team inputs. This made the mission statements shorter, measurable, catchy and co-owned by the whole team.
• The team was asked to brainstorm on a team name, which turned out to be more difficult than expected.
• The day ended with a Scrum simulation to learn Scrum by experiencing it. I played the role of PO and let them build a 3d city made of colored paper. In the course of the game, the team learns how the backlog is compiled, what the role of the PO is, how we define and attribute value, how Sprints work and how the team can improve their collaboration.

Day2

• I started the day with my favorite recap-warm-up exercise: building a treasure map of yesterday’s discoveries.
• I lectured the Scrum theory and principles for no more than 2 hours.
• We agreed on the Sprint schedule by planning the Scrum events and Refinements.
• We collected impediments that hindered the team. A problem I discovered that needed to be fixed asap was that some team members were only part- available time for the team. Part-time (as in being a Scrum team member and also be responsible for work outside the team) reduces focus and transparency, therefore it needs to be avoided.
• We started refining real work from the Product Backlog with the whole team. It took us more than a day to refine about a Sprint’s worth of work. That is pretty long but is incredibly important for sharing knowledge.
• Refining a PBI means creating a plan on how to get it to “Done”; i.e., we discussed all activities needed for each PBI to make it Done. That is how we discovered our Definition of Done: the DOD consists of the recurring activities (tasks) that define our product quality such as: “setup company communication”, “create work instructions”, “verify with legal”, etc. 
• I ensured to continuously check everybody’s impressions, emotions and concerns during the numerous breaks.
• We had drinks together (to continue getting to know each other and to continue finding a team name).

Day3

• I explained effort estimation and planning poker. Pokering one small and one large story gave us two benchmarks for relative estimation. Using these benchmarks allowed us to estimate the whole PBL with magic estimation. I purposely postponed the estimation during Refinement to first keep focus on sharing knowledge and then on estimating the work.
• We did a Sprint planning. The teams selected the items for their first Sprint. The PO’s understood that the teams might probably not pick up a lot of work in the first Sprint because the teams were playing it safe. I told the teams that I felt they were not very optimistic planners and reassured them that this is ok, “as long as we agree that new work is picked up when we finish the work before the Sprint is over.”
• To get the Sprint started, we did a Daily Scrum in the middle of the day, right after the Sprint Planning was over. This kicked them off to start on the work.

Day 4 and 5

These days consisted of Daily Scrums, Refinement and the team doing the actual work. I was available to help them find answers to their questions as they were working through their first Sprint on a day to day basis. I facilitated, taught or coached them during their first week of Scrumming the work.

Week 4: End of Sprint for Team 1

In week 4, the 3-week-sprint of team1 ended, so I returned to team 1 to help them prepare their Sprint Review and hosted a Sprint Retrospective. The first Sprint Review session was used to help them discover and learn the Sprint Review mechanics, not to actually have a Sprint Review. We created the Sprint Review agenda which made them discover all the stuff they need to prepare each Sprint to be ready for the Review: Iterating over the team goals, clarifying the Sprint Goal, sharing their challenges, demo the result, collect feedback, discuss metrics. This session also delivered each team a new item on the DOD: “Prepare for demo”.

We looked back on the first Sprint in the Sprint Retrospective, shared experiences and closed the Sprint with a fun team activity (drinks!). The next day, I supported them with the Sprint Planning of Sprint 2. This is where the support for the full Sprint cycle ended for team 1.

Note that all Scrum events and activities in Sprint 1 were not performed on the scheduled days and times and we did not adhere to their time-boxes. I ensured this was understood by all team members.

As soon as all teams had their Sprint started, I was free to support the teams that needed facilitation support for their refinements and randomly joined Daily Scrums of various teams. The remainder of my time I worked on removing organizational impediments: Helping to find solutions for the work no longer picked up by the new teams and informing and teaching the new way of working to the stakeholders.

Synchronizing the Sprints

The goal was to synchronize the three teams so that they all got into the same cadence. We wanted the group to have one Sprint Review per Sprint where all teams can collect feedback from the stakeholders. This makes things simpler and more transparent. I made sure that the PO’s understood that shorter Sprints are preferred because this gives us more opportunities for inspection. With a bit of puzzling I found a sweet spot where each team had sufficient time practicing with their three week Sprint and could switch to two-week Sprints. From there on, everybody started with a synchronized two-week Sprint.

Coaching

Most people embraced the new way of working. However, not everybody was equally happy with the new multidisciplinary teams. Friction was caused due to:

• responsibilities for “old” work,
• some people did not join the new teams voluntary,
• and some simply had difficulties getting used to the new team collaboration and processes.

I ensured the team’s previous managers were “helping in the right direction”. If needed I sat with team members to find out what was bothering them and I coached them to set new goals that would solve their impediments and stimulate collaboration.

When starting up new teams, the Scrum Master needs to take special care of to those people who are showing signs of doubt or struggle. Keep your ears and eyes open for signals. In many cases, people who have fears or doubts will not show them directly but share them with by cracking a joke or by silently organizing “their life” around “your“ Scrum.
I tend to be very cautious to intervene. Things simply need time (days, weeks) to settle in. I also want to give the team the opportunity to fix the problems by themselves. Sharing a thought with a team member about things I observe is enough in most cases.

Was it successful?

The organization wanted to adopt Scrum in order to become faster and more flexible in delivering products with happier customers and happier employees. 

The teams immediately ran into dependencies on other departments for delivering Done. In the first Sprint already, three capabilities were identified as main blockers for 80% of the work. We started a dialogue with these departments to agree on new ways of collaboration trough:

• acquiring permissions,
• add subject matter experts to our teams
• provide us with the necessary knowledge
• handing off responsibilities

With this, the teams were able to expand their DOD, which according to me is a proof of real organizational change. The vast majority of the people were enthusiastic and delighted with the new way of working: they belonged to a real team working on a clear goal, where colleagues help each other and the team succeeds in delivering valuable results.

Conclusion

One Scrum Master can get three teams started with Scrum near-simultaneously (in six weeks). The degree of success depends on a couple of factors:

• The preparation and willingness of the team members. In my case, two of the three teams were rather easy. If there is much resistance in the new teams, they will need more coaching time than you can give.
• A second critical success factor is management support. Introducing a new way of working will cause friction in the organization. We need top-down management support to talk to people outside of the group who otherwise would not be inclined to collaborate. We also need horizontal management support to ensure managers of a nearby departments no longer dispatch work to Scrum team members but go to the Product Owner instead.
• Communication is key. Ensure that everybody in the organization gets the opportunity to inform themselves about the change initiative. We spread the news via the internal newsletter and organized walk-in sessions. The team members discovered that they are the key evangelists to explain repeatedly to their colleagues outside the team about the new way of working.
• We chose the first week to be physically in the same location. We did not want to take the chance of setting up the teams remotely. I think working remote makes this kind of work more difficult because it is not possible for a Scrum Master to remotely observe the new group dynamics very well.
• Social events matter. Have lunch, grab a beer. (The team names came easily in the bar after work ;-).