Getting started with Scrum is one thing; spreading it across the organization is another. Unless you have chosen an all-in transition, you will need to build upon the successes of the first few teams as you move Scrum into other teams. There are three general patterns you can use for spreading Scrum beyond the initial teams. The first two patterns involve taking a team that has begun to be successful with Scrum and then using its members to seed new teams. The third pattern takes a different approach and involves spreading Scrum using internal coaches.
Split and Seed
The split-ami-seed pattern is typically put into use after the first couple of teams have adopted Scrum and run at least a handful of sprints. By that point, team members are beginning to understand what it is like to work on a Scrum team. They certainly won't have figured everything out, but sprints should be ending with working software, and team members should be working together well. In short, the team probably has a long way to go to get good, but Scrum is starting to feel natural.
It is at this unlikely point that we split the team up.
In the split-and-seed pattern, one functioning Scrum team is split in two, with each half of the original team forming the basis of a new team. New people are then added to these splinter teams to form new Scrum teams. A large initial team could be used to seed as many as four new teams, especially if the initial team included some members with previous Scrum experience or a natural aptitude for it.
The new team members can be either newly hired employees or existing employees moving onto their first Scrum projects. The idea behind the split and-seed pattern is that newly formed, second-generation Scrum teams will have an easier time learning the mechanics and practices of Scrum because they will have guidance from the experienced members of the team. The new teams are left together for a few sprints until that team begins to jell and its new members have developed a feel for Scrum. Then, again, the functioning teams are broken up into smaller teams and new members are added to fill out the teams. This cycle is repeated until Scrum has been fully introduced.
In a large, enterprise rollout of Scrum, you do not need to leave each generation of teams together for the same number of sprints. You can instead split each team whenever it's ready.
Grow and Split
The grow-and-split pattern is a variation of the split-and-seed approach. It involves adding team members until the team is large enough that it can be comfortably split in two. Immediately after splitting, each of the new teams will probably be on the small end of the desirable size range of five to nine members. After allowing the new teams one sprint at this reduced size, new members are added until each team becomes large enough that it can also be split. This pattern repeats until the entire project or organization has transitioned.
Internal Coaching
Philips Research's Scrum adoption is an example of the third pattern for spreading Scrum: internal coaching. Philips had begun adopting Scrum and was facing a problem. Like many organizations, it had some teams that were excelling with their new agile approach and others that were struggling. Philips' Christ Vriens solved the problem by using internal coaching. On each team that was doing well, he identified one person who truly understood what it meant to be agile and designated that person as a coach to another team that had not yet progressed as far in its understanding and use of Scrum.
Coaches were given specific responsibilities, such as attend sprint planning, review, and retrospective meetings; attend one daily scrum each week; and be available for two hours each week to provide other assistance to the mentored team as needed. Coaches were not excused from their responsibilities on their original teams, but it was acknowledged that each coach would have fewer hours to contribute to those teams.
Reasons to Prefer Split and Seed
The split-and-seed pattern's advantages are rooted in its quick-spreading nature.
• You can add teams more quickly than with most other approaches. Each new team should ideally include at least 2 members of the previous team. This means that possibly as soon as after 2 or 3 sprints, a team of 8 people could conceivably be split into four 2-person groups used to seed a second set of teams. If each of those 4 teams had 8 people you would have 32 Scrum team members. A few sprints later these 32 people could be used to seed 16 more teams, each with 8 team members for a total of over 100 Scrum experienced people after only 5 or 6 sprints.
• Each team has someone with Scrum experience to help guide them. Only the very first teams to transition will be forced to do so without someone on the team with Scrum experience. All subsequent teams will benefit from having at least two (and hopefully three or four) team members with at least a couple of sprints of experience under their belts. This can help reduce the discomfort some people will feel about transitioning to something new and unfamiliar.
Reasons to Prefer Grow and Split
The grow-and-split pattern spreads Scrum a bit more slowly than does the splitand-seed approach but comes with some key advantages.
• You don't have to destroy any existing teams. The primary problem with the split-and-seed strategy is that teams who are just starting to jell and get a handle on Scrum are demolished to form the basis of new teams. Breaking up a good team is always something that should be done with caution. Growing the team before splitting it overcomes this shortcoming because the team is kept together until it is large enough to form two complete teams, each with agile experience.
• Team members feel more continuity from sprint to sprint. When using the split-and-seed pattern, teams are constantly being split and reformed before a true sense of team camaraderie is established. Because the growand-split approach divides a team only when it has gotten too big, members can stay together longer, and there is less feeling of disruption.
Reasons to Prefer Internal Coaching
The internal coaching approach is generally my preferred approach. Not surprisingly, there are a strong set of advantages to it, including the following:
• Well-running teams do not need to be split. A drawback to the prior patterns is that functioning teams are split to form the foundations of new teams. When using internal coaches, teams stay intact with only the minor disruption of an occasional outsider (the coach) joining the team.
• Coaches can be hand-selected for new teams. An approach like the splitand-seed pattern takes a whole-team approach to coaching: The new team is coached collectively by the seeding team members. Some of those individuals will be good in that role; some will not. With internal coaching, the most appropriate coach can be selected for each new team.
• Coaches can be moved from team to team. After awhile a team and its coach become stale. A fresh pair of eyes can be helpful in identifying new ways to improve. When internal coaches move from team to team they act like bees, pollinating each team with new ideas.
Choosing Your Approach
There are two driving factors in choosing among these three patterns for spreading Scrum: How quickly do we need to spread Scrum to additional teams, and do we have good internal coaches who can assist the new teams? The answers to these questions will be key to helping you choose the pattern that best fits your organization.
In general, consider using split and seed when you are in hurry. The splitand-seed approach can be one of the fastest ways to spread Scrum through an organization. The approach can be accelerated in a couple of different ways: First, you can split teams a bit earlier than might be ideal. Second, you can split teams into more new teams than might be ideal, perhaps four new teams instead of two, even if this means that some new teams get some less-than-ideal coaches from the earlier teams.
Be cautious, though, about using split and seed if the technology and domain cannot support moving people among teams. Changing team membership is always detrimental to productivity. That loss can be offset, however, by the benefits of quickly spreading Scrum through a large project or organization. However, in some cases, it is just not practical to move people between teams. For example, seeding a .NET team with Java programmers just because they have three sprints of Scrum experience would not be a good idea.
The grow-and-split pattern is perhaps the most natural approach, as it mirrors what would probably happen if no one intervened to help the spread of Scrum. In most organizations, people move between projects, carrying good practices with them. The grow-and-split approach is simply a more directed approach than letting this happen naturally, which would take much, much longer.
Consider using grow and split when there is not enough urgency to push you to the split-and-seed approach. Because growing and splitting a team is a less aggressive (and less risky) approach than splitting and seeding a team, it is often used in similar situations but when there is a bit less urgency. Also consider using grow and split when the team size is growing anyway. True to its name, the grow-and split approach works best when teams are expanding.
Internal coaching can be used as a spreading strategy on its own, or it can be used to augment either of the other approaches. This approach works best under certain conditions:
• When the group is large enough that good practices won't fully spread on their own. One of the strengths of this pattern is that coaches can move from one team to another, spreading good practices as they do so. If your organization is small enough that sharing good practices won't be a problem, then you may not need this approach.
• When splitting teams is not practical for your projects. If any of the drawbacks to splitting teams concern you, the internal coaching approach is a good antidote.
• When you have enough internal coaches or can bring in outside help. An ideal coach is someone who fundamentally understands Scrum and has probably worked in an agile way for years before even hearing the word. These individuals can be hard to identify in advance; they aren't necessarily the most experienced team members. If you don't have enough good coaches, consider using one of the other patterns initially. After enough teams have run a few sprints, you can begin to augment a seeding approach with internal coaches. You can also spread the coaches you do have out a bit more by having each coach assist more than one team. If budget allows, you can also bring in outside consultants until you have built up your internal coaching corps.
Iterating Toward Agility
Historically, when an organization needed to change, it undertook a "change program." The change was designed, had an identifiable beginning and ending, and was imposed from above. This worked well in an era when change was necessary only once every few years. Christopher Avery has written, "I think in the 1960s and 1970s this approach was probably more frequently successful than it has been in the 1990s and today because the frequency of change has intensified as competition has become global, and the model has broken down". Avery continues by saying that "if the changes are coming so fast and furious that programmed change won't work, perhaps we have to arrange ourselves (organizationally speaking) to digest many more smaller changes on a continual basis".
Whether you are just starting to adopt Scrum or you are at the point where you are ready to fine-tune your use of Scrum, you should manage the effort in an agile way. Following an iterative transition process—making small changes on a continual basis—is a logical way to adopt a development process that is itself iterative. Doing so will be much more likely to result in a successful and sustainable transition. This is why I believe that the effort of adopting Scrum is best managed using Scrum itself. With its iterative nature, fixed timeboxes, and emphasis on teamwork and action, it seems best suited to manage the enormous project of becoming and then growing agile with Scrum.
In 2004, the leaders of Shamrock Foods realized that change was coming too quickly in their industry. As one of the ten largest food distributors in the United States, Shamrock had for 20 years used a conventional, top-down strategic planning process, dedicating months each year to creating a 5-year plan that was out of date before the ink dried. To address this problem, CEO Kent McClelland abandoned the company's 20-year-old approach and began to apply a Scrum-based iterative strategic planning process.
Shamrock's process revolved around quarterly strategic "scrums" [sprints]: Team members met at an offsite location for a day to evaluate the company's performance against the action plans from the previous quarter. We asked them to identify the most important things they had learned about the company's strategy since the previous meeting and to suggest how those insights should be integrated in the strategy going forward. The group created new action plans for the upcoming period. In addition to the quarterly scrums [sprints], the participants met every year for three days, during which time people were asked to step further back and revisit the company's strategic assumptions.
Forty-five managers and employees participated in these sprints and were chosen to represent each division and functional area. At the start of each quarterly sprint, this group selected up to a handful of key areas in which they agreed the company should improve. These were referred to as themes. Because Shamrock was applying Scrum to an organizational improvement effort rather than software development, the themes represented broad business goals. Examples included increasing revenue on Shamrock's house brands, improving how it serviced large customers like Burger King, and improving the company's ability to recruit, retain, and develop good talent.
Many corporate improvement initiatives fail because plans are not made specific and actionable. Because they were using Scrum, Shamrock employees went beyond just identifying themes for improvement: "Planning participants created and prioritized a handful of specific and measurable strategic initiatives that would advance each strategic theme. Then they built detailed action plans and set measurable outcomes they thought could be achieved within 90 days".
Not only does the Shamrock story illustrate the broad applicability of Scrum, it serves as an example of how Scrum can be used to manage an organizational improvement effort. In this chapter, we look at how to use Scrum first to adopt Scrum and then to continuously improve by engaging communities of like-minded employees, such as the 45 people who guided Shamrock's improvement effort.
Source of Information : Pearson - Succeeding with Agile Software Development Using Scrum 2010
Split and Seed
The split-ami-seed pattern is typically put into use after the first couple of teams have adopted Scrum and run at least a handful of sprints. By that point, team members are beginning to understand what it is like to work on a Scrum team. They certainly won't have figured everything out, but sprints should be ending with working software, and team members should be working together well. In short, the team probably has a long way to go to get good, but Scrum is starting to feel natural.
It is at this unlikely point that we split the team up.
In the split-and-seed pattern, one functioning Scrum team is split in two, with each half of the original team forming the basis of a new team. New people are then added to these splinter teams to form new Scrum teams. A large initial team could be used to seed as many as four new teams, especially if the initial team included some members with previous Scrum experience or a natural aptitude for it.
The new team members can be either newly hired employees or existing employees moving onto their first Scrum projects. The idea behind the split and-seed pattern is that newly formed, second-generation Scrum teams will have an easier time learning the mechanics and practices of Scrum because they will have guidance from the experienced members of the team. The new teams are left together for a few sprints until that team begins to jell and its new members have developed a feel for Scrum. Then, again, the functioning teams are broken up into smaller teams and new members are added to fill out the teams. This cycle is repeated until Scrum has been fully introduced.
In a large, enterprise rollout of Scrum, you do not need to leave each generation of teams together for the same number of sprints. You can instead split each team whenever it's ready.
Grow and Split
The grow-and-split pattern is a variation of the split-and-seed approach. It involves adding team members until the team is large enough that it can be comfortably split in two. Immediately after splitting, each of the new teams will probably be on the small end of the desirable size range of five to nine members. After allowing the new teams one sprint at this reduced size, new members are added until each team becomes large enough that it can also be split. This pattern repeats until the entire project or organization has transitioned.
Internal Coaching
Philips Research's Scrum adoption is an example of the third pattern for spreading Scrum: internal coaching. Philips had begun adopting Scrum and was facing a problem. Like many organizations, it had some teams that were excelling with their new agile approach and others that were struggling. Philips' Christ Vriens solved the problem by using internal coaching. On each team that was doing well, he identified one person who truly understood what it meant to be agile and designated that person as a coach to another team that had not yet progressed as far in its understanding and use of Scrum.
Coaches were given specific responsibilities, such as attend sprint planning, review, and retrospective meetings; attend one daily scrum each week; and be available for two hours each week to provide other assistance to the mentored team as needed. Coaches were not excused from their responsibilities on their original teams, but it was acknowledged that each coach would have fewer hours to contribute to those teams.
Reasons to Prefer Split and Seed
The split-and-seed pattern's advantages are rooted in its quick-spreading nature.
• You can add teams more quickly than with most other approaches. Each new team should ideally include at least 2 members of the previous team. This means that possibly as soon as after 2 or 3 sprints, a team of 8 people could conceivably be split into four 2-person groups used to seed a second set of teams. If each of those 4 teams had 8 people you would have 32 Scrum team members. A few sprints later these 32 people could be used to seed 16 more teams, each with 8 team members for a total of over 100 Scrum experienced people after only 5 or 6 sprints.
• Each team has someone with Scrum experience to help guide them. Only the very first teams to transition will be forced to do so without someone on the team with Scrum experience. All subsequent teams will benefit from having at least two (and hopefully three or four) team members with at least a couple of sprints of experience under their belts. This can help reduce the discomfort some people will feel about transitioning to something new and unfamiliar.
Reasons to Prefer Grow and Split
The grow-and-split pattern spreads Scrum a bit more slowly than does the splitand-seed approach but comes with some key advantages.
• You don't have to destroy any existing teams. The primary problem with the split-and-seed strategy is that teams who are just starting to jell and get a handle on Scrum are demolished to form the basis of new teams. Breaking up a good team is always something that should be done with caution. Growing the team before splitting it overcomes this shortcoming because the team is kept together until it is large enough to form two complete teams, each with agile experience.
• Team members feel more continuity from sprint to sprint. When using the split-and-seed pattern, teams are constantly being split and reformed before a true sense of team camaraderie is established. Because the growand-split approach divides a team only when it has gotten too big, members can stay together longer, and there is less feeling of disruption.
Reasons to Prefer Internal Coaching
The internal coaching approach is generally my preferred approach. Not surprisingly, there are a strong set of advantages to it, including the following:
• Well-running teams do not need to be split. A drawback to the prior patterns is that functioning teams are split to form the foundations of new teams. When using internal coaches, teams stay intact with only the minor disruption of an occasional outsider (the coach) joining the team.
• Coaches can be hand-selected for new teams. An approach like the splitand-seed pattern takes a whole-team approach to coaching: The new team is coached collectively by the seeding team members. Some of those individuals will be good in that role; some will not. With internal coaching, the most appropriate coach can be selected for each new team.
• Coaches can be moved from team to team. After awhile a team and its coach become stale. A fresh pair of eyes can be helpful in identifying new ways to improve. When internal coaches move from team to team they act like bees, pollinating each team with new ideas.
Choosing Your Approach
There are two driving factors in choosing among these three patterns for spreading Scrum: How quickly do we need to spread Scrum to additional teams, and do we have good internal coaches who can assist the new teams? The answers to these questions will be key to helping you choose the pattern that best fits your organization.
In general, consider using split and seed when you are in hurry. The splitand-seed approach can be one of the fastest ways to spread Scrum through an organization. The approach can be accelerated in a couple of different ways: First, you can split teams a bit earlier than might be ideal. Second, you can split teams into more new teams than might be ideal, perhaps four new teams instead of two, even if this means that some new teams get some less-than-ideal coaches from the earlier teams.
Be cautious, though, about using split and seed if the technology and domain cannot support moving people among teams. Changing team membership is always detrimental to productivity. That loss can be offset, however, by the benefits of quickly spreading Scrum through a large project or organization. However, in some cases, it is just not practical to move people between teams. For example, seeding a .NET team with Java programmers just because they have three sprints of Scrum experience would not be a good idea.
The grow-and-split pattern is perhaps the most natural approach, as it mirrors what would probably happen if no one intervened to help the spread of Scrum. In most organizations, people move between projects, carrying good practices with them. The grow-and-split approach is simply a more directed approach than letting this happen naturally, which would take much, much longer.
Consider using grow and split when there is not enough urgency to push you to the split-and-seed approach. Because growing and splitting a team is a less aggressive (and less risky) approach than splitting and seeding a team, it is often used in similar situations but when there is a bit less urgency. Also consider using grow and split when the team size is growing anyway. True to its name, the grow-and split approach works best when teams are expanding.
Internal coaching can be used as a spreading strategy on its own, or it can be used to augment either of the other approaches. This approach works best under certain conditions:
• When the group is large enough that good practices won't fully spread on their own. One of the strengths of this pattern is that coaches can move from one team to another, spreading good practices as they do so. If your organization is small enough that sharing good practices won't be a problem, then you may not need this approach.
• When splitting teams is not practical for your projects. If any of the drawbacks to splitting teams concern you, the internal coaching approach is a good antidote.
• When you have enough internal coaches or can bring in outside help. An ideal coach is someone who fundamentally understands Scrum and has probably worked in an agile way for years before even hearing the word. These individuals can be hard to identify in advance; they aren't necessarily the most experienced team members. If you don't have enough good coaches, consider using one of the other patterns initially. After enough teams have run a few sprints, you can begin to augment a seeding approach with internal coaches. You can also spread the coaches you do have out a bit more by having each coach assist more than one team. If budget allows, you can also bring in outside consultants until you have built up your internal coaching corps.
Iterating Toward Agility
Historically, when an organization needed to change, it undertook a "change program." The change was designed, had an identifiable beginning and ending, and was imposed from above. This worked well in an era when change was necessary only once every few years. Christopher Avery has written, "I think in the 1960s and 1970s this approach was probably more frequently successful than it has been in the 1990s and today because the frequency of change has intensified as competition has become global, and the model has broken down". Avery continues by saying that "if the changes are coming so fast and furious that programmed change won't work, perhaps we have to arrange ourselves (organizationally speaking) to digest many more smaller changes on a continual basis".
Whether you are just starting to adopt Scrum or you are at the point where you are ready to fine-tune your use of Scrum, you should manage the effort in an agile way. Following an iterative transition process—making small changes on a continual basis—is a logical way to adopt a development process that is itself iterative. Doing so will be much more likely to result in a successful and sustainable transition. This is why I believe that the effort of adopting Scrum is best managed using Scrum itself. With its iterative nature, fixed timeboxes, and emphasis on teamwork and action, it seems best suited to manage the enormous project of becoming and then growing agile with Scrum.
In 2004, the leaders of Shamrock Foods realized that change was coming too quickly in their industry. As one of the ten largest food distributors in the United States, Shamrock had for 20 years used a conventional, top-down strategic planning process, dedicating months each year to creating a 5-year plan that was out of date before the ink dried. To address this problem, CEO Kent McClelland abandoned the company's 20-year-old approach and began to apply a Scrum-based iterative strategic planning process.
Shamrock's process revolved around quarterly strategic "scrums" [sprints]: Team members met at an offsite location for a day to evaluate the company's performance against the action plans from the previous quarter. We asked them to identify the most important things they had learned about the company's strategy since the previous meeting and to suggest how those insights should be integrated in the strategy going forward. The group created new action plans for the upcoming period. In addition to the quarterly scrums [sprints], the participants met every year for three days, during which time people were asked to step further back and revisit the company's strategic assumptions.
Forty-five managers and employees participated in these sprints and were chosen to represent each division and functional area. At the start of each quarterly sprint, this group selected up to a handful of key areas in which they agreed the company should improve. These were referred to as themes. Because Shamrock was applying Scrum to an organizational improvement effort rather than software development, the themes represented broad business goals. Examples included increasing revenue on Shamrock's house brands, improving how it serviced large customers like Burger King, and improving the company's ability to recruit, retain, and develop good talent.
Many corporate improvement initiatives fail because plans are not made specific and actionable. Because they were using Scrum, Shamrock employees went beyond just identifying themes for improvement: "Planning participants created and prioritized a handful of specific and measurable strategic initiatives that would advance each strategic theme. Then they built detailed action plans and set measurable outcomes they thought could be achieved within 90 days".
Not only does the Shamrock story illustrate the broad applicability of Scrum, it serves as an example of how Scrum can be used to manage an organizational improvement effort. In this chapter, we look at how to use Scrum first to adopt Scrum and then to continuously improve by engaging communities of like-minded employees, such as the 45 people who guided Shamrock's improvement effort.
Source of Information : Pearson - Succeeding with Agile Software Development Using Scrum 2010
|
|
0 comments
Post a Comment