Bank of America’s Merrill Lynch (BAML) Global Securities Operations Technology decided to adopt Scrum, and needed some changes to do so. Key among those was forming real “Teams” in Scrum: dedicated true cross-functional and cross-component teams of about seven people that could independently perform all the tasks (analysis, development, testing, …) 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 sub-divided 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, 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 their 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 (Ahmad here) an “ex-program manager” 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 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, during which he 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 turn out?”
He also suggested experimenting if a team could (internally) “hire or fire” (from their team) their ScrumMaster, rather than one being 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 (by a senior manager) of the goals and the need for diversity of 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 somewhat of a surprise to many, including myself, 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, and invited 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.
There was a lot of chatter ahead of the meeting. One of the most seasoned developers quietly pulled me aside before the meeting and expressed his concern to me that he might not be picked. I was taken aback. I thought, the whole thing smells of grade school.
The room in London held 42 people, including 35 future team members, and some ScrumMasters and other observers. The session started with the department head giving an overview of Scrum, though some people had previously been to an introduction with Craig. I could sense that some were not only skeptical of the idea of self-organizing into their own teams, but also of the idea of Scrum in general – primarily those that had not been previously been to a Scrum introduction and did not quite understand the ideas or motivations.
One of the more senior business analysts expressed his concern that Agile would not work for larger groups and may be better suited for small discrete change items. At this point, I interjected and asked 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 the current organization’s ability to deliver could be dramatically improved.
At this point, he concluded with two constraints on design of the teams:
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. Instinctively, I got an idea to run 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 its been done for years.
I asked everyone in the room to write their name and primary skill on a Post-it note. Four flip chart sheets which would serve as team boards were put up in the corner of the large room. I instructed the group that they had 25 minutes to form themselves into teams. They were all taken aback as they 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 who already worked together. When the “Pomodoro” timer rang, I was a little disheartened. The miracle I was hoping for hadn’t happened. The group had shuffled into their current teams, basically organized by software component. The teams seemed to relish 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 I 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 was done fairly quickly and we were able to keep to the five minutes. When finished, each team averaged six defects.
Cycle Two: Celebrating the Courage to Change
Now it started to get really interesting. This is when the group started to get a lot more vocal. I got the sense that people found it very difficult to move around. I wandered around 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 “5 whys”: Why do you need so many X developers? And so on.
Eventually, people in one of the long-established teams said that deciding who had to leave was too difficult, and that 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 will just be reinforcing the ‘command and control’ culture.” At that point, one of the team members acknowledged they were being ridiculous 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 then, finally, other members followed suit.
During the review the teams averaged around two-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 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 two in total. Not bad. I asked the teams to do a sanity check and really “look” at their teammates. This was done 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 pre-selected four ScrumMaster candidates. These were 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 pre-selected ScrumMasters to leave the room. I gave the teams five minutes to deliberate. In the end, the teams selected from the original candidate ScrumMasters. There was some vying for one of the ScrumMasters, but this was quickly resolved through a silent vote.
We now had four true cross-functional and 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 I saw them on that day, with lots of laughter and lighthearted debate over the names. This too was over in five minutes.
I took a picture of each team under their team name. This made the experience more real for many, including myself.
Retrospective and Wrap-up
I asked everyone to write down positive and negative feedback on the exercise before they left, and this article summarizes their feedback in the appendix.
Once done, the session ended.
I immediately emailed the pictures of the teams to the department and senior management.
This 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.
After this session – and after the subsequent two self-designing events described in the next section – there was one team member swap the day after the session. This was done at the team member’s own initiative, and we view that as a sign of success for the self-organizing team mindset. It is very unlikely that would have happened if a manager had assigned people to teams.
Reflection
Balanced teams could have been created by the management team and in all likelihood they would not be 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 dismantled many of the command and control constructs early on in a very dramatic way. There was a sense of empowerment at the end of the three hours that was not there before (see Appendix B).
The need for strong facilitation is also vital to run this session smoothly and effectively. An experienced SrumMaster or agile coach is ideally suited to run a session such as this.
Considerable thought needs to be put into whom is in the room. These sessions should not be limited only to technology people, but should include any groups responsible in delivering business value. This is critical as it’s disruptive if team members are “injected” into the teams at a later stage. This can harm the nascent culture that is being created, as well as team morale.
It is important to have a good room environment. For example, the large conference-room table in the room was an impediment and was the number-one complaint (see Appendix B).
Improving the Self-Designing Teams Process: More Experiences
Fortunately, after that first experience, we have facilitated two more self-designing teams sessions within the bank, and have improved the process based on inspection and adaptation.
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 have made two major changes to the session and process that 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 pre-selected; 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.
Scaling to 100 team members
After facilitating three self designing team formation sessions, I was recently asked to help facilitate the creation of 14 teams across 100 people. Due to the scale, I did the following:
added another hour to the original format
divided the room into 3 parts and solicited the help of two other scrum masters to help facilitating the review
a pre-defined criteria was provided, but the “room” was giving 25 minutes to overload the team definition rules.
The result was that the team formed an hour early in three hours. The process can indeed scale so long as a scrum master facilitates the review process of no more than five teams.
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 obvious and subtle change elements. But it is noteworthy how much can be quickly changed when the organizational will and appropriate hands-on worker and leadership support is in place. And it is noteworthy that with some facilitation, people are quite capable of deciding amongst 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 Potential schedule
