(Note: Original article published in 2013)
How long does it take an organization to reorganize in order to adopt Scrum? Three hours. Really.
Background and goal
Bank of America's Merrill Lynch (BAML) Global Securities Operations Technology decided to adopt Scrum — and needed some changes to do so. Key among these was forming real "teams" in Scrum: dedicated, true cross-functional and cross-component teams of about seven people who could independently perform all the tasks (analysis, development, testing, etc.) to deliver completely "done" end-to-end functionality.
Before adopting Scrum, the organizational structure was primarily single-function groups (business analysis group, development group, test group). Further, developers were subdivided into single-software-component subgroups, and there was "private code ownership" in each component group (rather than "internal open source"). Consequently, doing one customer-centric, vertical, end-to-end feature involved massive handoff and coordination challenges, since it would span the business-analysis group, component1-group, component2-group, component3-group, and test group. The silos of component groups resulted in long and difficult integration and regression cycles, leading to a seven-week release phase.
Therefore, as an early step in Scrum adoption, the department needed to reorganize the existing groups into new teams — true cross-functional and cross-component (Scrum) teams.
How to form the new teams, from a total of 35 people? Who should decide the team membership?
People and traditional assumptions
As an ex-program manager (Ahmed Fahmy) in a department moving to Scrum with self-organizing teams, who was very interested in the framework and its successful introduction, these questions were present in my mind. I had previously learned of the idea of self-designing teams from our Scrum coach, and I considered it an interesting idea, though perhaps not relevant to our situation.
Why not relevant? For one thing, the manager directing the department at first assumed — we all assumed — that he and the other senior managers would decide the membership of the new teams. This was a default assumption because of our prior culture (and that found in many organizations): Managers decide these matters.
But, unknown to me at the time, he (the department head) had had a meeting with the large-scale Scrum consultant and coach who was helping the group, Craig Larman. Craig offered an idea described in the book Scaling Lean & Agile Development (Larman & Vodde, 2008): self-organizing team creation, or self-designing teams.
Craig shared the story of a department of about 100 people in Hangzhou, China, that was adopting large-scale Scrum and faced a similar problem:
Instead of deciding on the new teams, the Chinese department manager, Lv Yi (along with Bas Vodde, a Scrum expert who worked in the group), invited everyone into a large room, explained the goal of new Scrum teams, and simply asked the group members to decide among themselves. The group agreed it needed four hours for this, and Lv Yi said, "I'll come back in four hours, and if some people have not decided by then, I will decide." Four hours later and after much talk and activity, the group had self-designed their new teams. Then volunteer ScrumMasters were brought to the center of the room, and the teams picked the ScrumMasters that they wanted.
Craig pointed out that this approach was consistent with the self-organizing principle of Agile organizations, moving from a command-control management culture to more self-management. He asked, "What does it communicate to the people if managers say, 'We are going to adopt Scrum and self-organizing principles,' but then managers decide and tell people what their teams are, and who their ScrumMasters are?" Craig also asked, "And if someone doesn't like their new team, who will they blame, if the managers decided things, and what action will that disgruntled team member take to fix it? And on the other hand, who will they blame if they themselves decide their teams, and what actions might they take if they don't like the way things turns out?"
He also suggested experimenting to see if a team could internally "hire or fire," from among its members, its ScrumMaster, rather than having one assigned.
The department head quickly got the point and said, "I love the idea! Let's try it." Another manager in the meeting seemed open and curious, but also concerned that it might not work out in terms of creating well-balanced teams. To help address this concern, Craig suggested that the session start with an overview, given by a senior manager, of the goals and the need for diversity in skills, experience, age, and gender in the teams.
The department head had a bit of reputation as "Mr. Command and Control," so it came as a surprise to many, including me, when he publicly announced that he was allowing his entire department to self-organize with self-designing teams as part of the Scrum adoption.
The "Big Day"
The department head scheduled a half-day session for the self-designing teams event, inviting his entire department. He invited me to join the session as an observer. But minutes before the meeting, he asked me to facilitate the session rather than merely observe. I agreed.
The room held 42 people, including 35 future team members, and some ScrumMasters and other observers. The department head started the session by giving an overview of Scrum. I could sense that some were not only skeptical of the idea of self-organizing their own teams but also of the idea of Scrum in general — primarily those who had not previously been to a Scrum introduction and didn't quite understand the ideas or motivations.
One of the more senior business analysts expressed his concern that Agile wouldn't work for larger groups and might be better suited to small, discrete change items. At this point, I interjected and asked people in the room to vote on their current ability to deliver large-scale change programs, deliver value, and delight the sponsor in our current (traditional) organization and ways of working. The majority voted that the current organization's ability to deliver could be dramatically improved.
At this point, the department head concluded with two constraints on design of the teams:
Teams needed to be co-located.
Teams needed to be cross-functional and cross-component; they should be able to (or be able to learn to) deliver any item from the product backlog.
He left after his last remarks, and I was left with many skeptical people in a big room. We had three hours to reorganize a department that had worked within a fixed pattern for decades. I didn't have a script to follow, or a formula. So, acting on instinct, I ran the session as four cycles of 25 minutes, with a five-minute review at the end of each, plus some breaks.
Facilitating self-designing teams
I gave no indication to the already skeptical room that I was making it up as I was going along, let alone the fact that I didn't believe that this would work. I had discovered long ago that the chances of a new protocol or ritual to be accepted by the hive is much higher if I introduced it as if it had been done for years.
I asked everyone in the room to write their name and primary skill on a Post-it note. In a corner, we set up four flip charts to serve as team boards. I told the group it had 25 minutes to form itself into teams. Everyone was taken aback, as they'd thought they would have three hours to do it. I told them that in this technique, no one is allowed to sit for the three hours, and one must physically move to the team board. And without further ado, I set the timer and they were off.
Cycle One: "We're all for improvement; we just don't want to change anything."
Immediately, cliques began to form based on groups that already worked together. When the timer rang, I was a little disheartened. The miracle I was hoping for hadn't happened. The room had shuffled into its current teams, basically organized by software component. The teams seemed to take delight in this, as if to say, "See, we are meant to be together."
I set the timer for five minutes, and we started the first review. I went to the first team and asked the room for feedback. I noted every defect (variation from an ideal team) on a pink sticky note and put it on the wall next to the team board. This went fairly quickly and we finished within our five minutes. When I'd done this with every team, each averaged six defects.
Cycle Two: Celebrating the courage to change
Now it started to get really interesting. I challenged the teams to change again, and the group became a lot more vocal. I got the sense that people found it very difficult to move around. I wandered the room, trying to help the teams along. Whenever I found one of the more senior members of the team commanding others to go, I would interject and try to facilitate the conversation, with techniques such as the "five whys": Why do you need so many developers? And so on.
Eventually, people in one of the long-established teams said that deciding who had to leave was too difficult, and perhaps it would be best to invite the manager back to decide. Injecting some harsh humor, I responded with, "Perhaps he can decide what we all have for lunch as well? If we do that, we'll just be reinforcing the command-and-control culture." At that point, one of the team members acknowledged the ridiculousness of the situation and volunteered to go to the team that was deficient in his primary skill. I immediately celebrated this fact loud enough so the entire room could hear. This was a bit of a tipping point, and finally other members followed suit.
During the review, the teams averaged around two to three defects each. Things were looking a lot better. It felt as though we were finally over the hump and we could get there. Cycle Two was complete.
Cycle Three: Ahmad discovers another logjam-breaking technique
During the third cycle, things slowed down again and people stuck stubbornly to what remained of their long-standing teams. There was still an imbalance between two of the teams, one having a surplus of a skill and the other having a deficiency in the same skill. I proposed that the deficient team physically walk to the surplus team and ask for help. They liked this idea, did it, and were successful. Having seen it work, I asked the other teams to do the same.
Review time. One team had zero defects; the other teams had only one apiece. Not bad. I asked the teams to do a sanity check and really "look" at their teammates, and we noticed an imbalance of business knowledge on one team. Once this was corrected, we were nearly done.
Cycle Four: Choosing ScrumMasters and team names
The department head and his management team had preselected four ScrumMaster candidates, chosen based on the profile that was given during Scrum training, as well as on people volunteering for the position. With the department head absent from the room, I decided to modify the situation: I informed the teams that they could select their ScrumMaster from the four names suggested or choose anyone from their own team to be their ScrumMaster. I asked the preselected ScrumMasters to leave the room. I gave the teams five minutes to deliberate. In the end, the teams selected from the original candidate ScrumMasters.
We now had four cross-functional, cross-component, newly formed Scrum teams. The mood in the room was good. I decided to inject some humor and finish on a high note by asking the teams to name themselves. This was probably the most animated they got that day, with lots of laughter and light-hearted debate over the names. This too was over in five minutes.
I took a picture of each team with a sign stating the team name. This made the experience more real for many, including me.
Retrospective and wrap-up
I asked everyone to write down positive and negative feedback about the exercise (here summarized in Appendix B). At this point, the session ended.
I immediately emailed the pictures of the teams to the department and senior management.
The next day there was one team member-swap the day after the session. This was done at the team member's own initiative, which we view as a sign of success for the self-organizing team mind-set. It's unlikely that would have happened if a manager had assigned people to teams.
And that is how a department was transformed in three hours. Now it was on to the business of delivering great software with Agility in our world of frequent change and learning.
Reflection
Balanced teams could have been created by the management team, and in all likelihood they would not have been much different from the teams created through this process. A major difference, however, is that the self-designing teams session sets the tone for the cultural change an organization undergoes when properly adopting Scrum. It dismantles many of the command-and-control constructs early on, in a dramatic way. In the case I described, there was a sense of empowerment at the end of the three hours that was not there before.
The need for strong facilitation is also vital to run this session smoothly and effectively. An experienced ScrumMaster or Agile coach is ideally suited.
Considerable thought also needs to be put into who is in the room. These sessions should not be limited only to technology people but should include any groups responsible for delivering business value. This is critical, as it's disruptive if members are "injected" into the teams at a later stage. This can harm team morale and the nascent culture being created.
Finally, it's important to have a good room environment. For example, the large table in the room was an impediment, and was in fact the number-one complaint.
Improving the self-designing teams process: More experiences
Since that first experience we've facilitated two more self-designing team sessions within the bank, and we've improved the process based on inspection and adaptation. We've realized that first, before a self-designing teams event, arrange introductory Scrum education (for example, in a Certified ScrumMaster course) for most participants, so they understand the ideas, motivation, and context.
We've also made two major changes to the session and process, which we recommend:
The whole group (rather than a manager) defines the ideal makeup of a new team at the start of the session. Key precondition: They do this based on having been previously educated about true Scrum teams in general, and with teaching and feedback from the facilitator.
ScrumMasters are not preselected; rather, the teams vote for their ScrumMasters from a pool of volunteers who have demonstrated knowledge and interest.
The updated session schedule is summarized in Appendix A.
Summary
Of course, it doesn't take only three hours to truly and successfully adopt large-scale Scrum; forming the teams in a three-hour session is only one of many changes, both obvious and subtle. But it's worth noting how much can be quickly changed when the organizational will and appropriate hands-on worker and leadership support is in place. And it's worth noting that, with some facilitation, people are quite capable of deciding among themselves how to organize into teams, without command-and-control management.
The views expressed in this article are those of the authors and do not necessarily represent the view of, and should not be attributed to, Bank of America.
Appendix A: Self-Designing Teams Schedule
Introduction and background: 20 minutes
Ideal team definition (define the primary skills required within in any team; this creates a rough guideline, rather a strict rule): 20 mins.
Cycle 1: 25 mins.
Review: 10 mins.
Cycle 2: 25 mins.
Break: 20 mins.
Review: 10 mins.
Cycle 3: 25 mins.
Review: 10 mins.
Team names and photos: 15 mins.
Retrospective: "Plus-delta" feedback: 5 mins.
Conclusion and thanks: 5 mins.
Follow-up session scheduled for the following day to discuss any potential change requests.
Appendix B: Session feedback
Positive
The process, facilitation, and timekeeping: 11 comments
The sense of empowerment: 7 comments
The creation of well-balanced team: 8 comments
The sense of team spirit that was fostered: 3 comments
Areas for improvement
Inadequate room choice: 6 comments
Session too long: 5 comments
More management/facilitation involvement required to break deadlocks: 5 comments
Pressure to join a team you're not happy with: 3 comments
More information required ahead of the meeting regarding individual profiles, session objectives, and the type of work teams will be working on: 3 comments
Reluctance of team members to move out of the initial teams created: 3 comments
Chaotic at times: 2 comments
Process does not create balanced teams: 2 comments