- Your Starting Condition
- The Kickstart Process
- The Kickstart Event
- Some Final Thoughts
- Tying It All Together
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Kickstart Process
Coaching Tip!
Prefer to bypass the background detail provided in this section? Check out our quick Kickstart reference in the Appendix.
The kickstart process covered here is particularly effective when you’re faced with limited time or resources—in other words, when teams or organizations need to better manage workflow, but don’t have sufficient resources to develop those better ways. Naturally, this is not the only way to introduce Scrumban to teams.2 Always use your understanding of Scrumban principles to modify the process to fit your context.
Incidentally, this process is modeled after a Kanban kickstart process developed by Christophe Achouiantz, a Lean/Agile coach, and Johan Nordin, development support manager at Sandvik IT. Sandvik needed a way to empower its company’s teams to begin a process of continuous improvement that wouldn’t involve a significant initial investment of time or effort. Achouiantz and Nordin have documented this process and made it available to the public as a reference guide. While the particulars may not apply directly to your needs, it’s an outstanding summary of the key points and objectives relevant to any process.
Preparation
As systems thinkers, it’s critical to first understand the context of the environment before attempting to kickstart anything. At a minimum, preliminary preparation should include the following steps:
- Identifying the current conditions and organizational priorities (e.g., increased quality, productivity, predictability)
- Developing working relationships with key managers and team leads
- Ascertaining areas of desired change
- Introducing Kanban/Scrumban as a framework for evolutionary change
- Starting to educate staff on Scrumban’s core principles and practices
- Identifying any risks and potential impediments to introducing Scrumban to targeted teams
Regarding that last item, it’s important to recognize that some teams or contexts may not benefit from introducing Scrumban until certain conditions or impediments are addressed. These can include teams in an active state of reorganization, teams with serious internal conflicts, and so forth. Your context will determine how you address these situations. For example, Sandvik’s needs dictated that such teams be bypassed until circumstances changed.
Though it’s possible for teams to initiate Scrumban adoption without organizational buy-in, as previous chapters indicate, broader engagement is necessary to achieve the full breadth of desired outcomes and to sustain them over time. As such, Scrumban is not substantially different from a pure Scrum context.
PMO/Program Managers:
If you’re overseeing a pilot program or broad-based transformation effort, we strongly encourage you to consider the recommendations outlined here. The choices you make in the early stages will greatly influence your ultimate success.
In his book Succeeding with Agile: Software Development Using Scrum (Boston: Addison-Wesley, 2009), Mike Cohn addresses a variety of considerations that apply when you’re selecting the project context in which to roll out a new process (these considerations are made with an eye toward building off demonstrated success). Though less critical in a context where the Scrumban or Kanban framework is employed, they nonetheless represent worthy considerations (see Figure 5.1 for a graphical illustration of the convergence of these considerations):
)
Figure 5.1 The convergence of key considerations in selecting a pilot project for introducing Scrum. These same considerations apply to Scrumban.
Source: Michael Cohn. Succeeding with Agile: Software Development Using Scrum (Boston: Addison-Wesley, 2009).
Project size: For Scrum pilots, Mike suggests selecting a project that will not grow to more than five teams, and limiting initial efforts to just one or two of those teams. Coordinating work among more Scrum teams represents more work than you can effectively tackle.
For Scrumban rollouts, there’s substantially more leeway. With fewer concepts to learn and master (again, we start out respecting current roles and processes), working with a slightly larger number of teams is feasible.
- Project duration: Select a pilot project of average duration for your organization, ideally around 3–4 months. This is plenty of time for teams to begin mastering the framework and seeing benefits. It’s usually also sufficient for demonstrating that your new approach will lead to similar success in other contexts.
Project importance: Mike suggests that with Scrum pilots, it’s critical to select high-profile projects. Unimportant projects will not get the organizational attention necessary to make Scrum successful, and team members may be disinclined to do all the hard things Scrum requires.
There’s slightly more leeway with Scrumban. Building momentum and trust through success is still an important objective, but the framework’s service-oriented agenda and active management of psychological barriers to change represent additional capabilities that can be leveraged to ultimately satisfy these needs.
Business owner’s level of engagement: As previously mentioned, Scrum and Scrumban ultimately require changes in the way both the business and the technology sides of the house approach things. Having an engaged player on the business side can be invaluable for overcoming challenges and evangelizing success across the organization.
Executives
Your efforts to educate your organization’s nontechnical employees about how this undertaking is important to the business, and encouraging their active engagement in the process, will go a long way toward creating long-term success.
Scrumban modifies the weight of this factor substantially. To function properly, Scrum requires active engagement on the business side—its prioritization and feedback functions depend on it. Scrumban won’t function well without business engagement, but it does afford teams the ability to create positive changes by allowing knowledge discovery to “stand in” for disengaged business players.
In a similar vein, Scrumban is ultimately designed to respond to business demands. If the business isn’t demanding change, then Scrumban’s pragmatic “response” is to reflect the absence of any need to change (although a culture of continuous improvement will continue to spawn incremental changes to make what you’re already doing well even better).
Initial Considerations
Many topics can be addressed during a kickstart. What constitutes “information overload” for a particular group will vary from context to context, and must always be judged against the level of ongoing support available following the kickstart (for example, you will likely cover more material if teams will have coaching support following the kickstart than if they will have none at all).
With these considerations in mind, incorporating themes that reinforce the service-oriented philosophy and the organization’s core values will go a long way toward positioning teams to evolve more effectively. There are many ways to do this, and it’s one area where an experienced practitioner or coach will really add value to the process.3
One special consideration for existing Scrum teams may be to introduce the concept of Sprint 0 (if this tactic is employed within the involved team or organization). There’s much debate about the “appropriateness” of Sprint 0 in Scrum circles. These special sprints are often described as necessary vehicles for managing what needs to be done before a Scrum project can start. For example, the team may need to be assembled, hardware acquired and set up, and initial product backlogs developed. Purists’ feathers may be ruffled by the notion of differentiating sprints by type and, more importantly, by the idea that any sprint would be structured in a way that fails to deliver value.
The Scrumban framework obviates the need for debate on these issues. The tasks associated with ramping up a new project can be easily accommodated and managed within the Scrumban framework as a special work type. If it’s important for your environment to ensure Scrum ceremonies hold true to their Agile objectives, then Scrumban provides a ready solution.
It also makes sense to assess existing Scrum practices with an eye toward understanding their impact on performance. Larry Maccherone and his former colleagues at Rally Software have analyzed data from thousands of Scrum teams in an effort to assess how differences in the way Scrum is practiced affect various elements of performance. This data mining exposed some interesting realities about how our choices involving Scrum practices can influence various facets of performance. Incidentally, Maccherone’s analysis is consistent with data mined from hundreds of teams using my own Scrum project management platform (ScrumDo.com).
Maccherone elected to adopt a “Software Development Performance Index” as a mode of measuring the impact of specific practices. The index is composed of measurements for the following aspects:
- Productivity: Average throughput—the number of stories completed in a given period of time
- Predictability: The stability of throughput over time—how much throughput values varied from the average over time for a given team
- Responsiveness: The average amount of time work on each user story is “in process”
- Quality: Measured as defect density
How You Choose to Organize Makes a Difference
)
As noted, Larry Maccherone’s analysis reflects a definite correlation between certain choices and software development performance. Although correlation does not necessarily mean causation, we can use these relationships as a guide for tailoring a kickstart process to address specific factors relevant to a particular implementation. Teams can be guided to position their visualizations and practices to better understand and discover which choices regarding Scrum practices are likely to work best for their desired outcomes.4
Determining Team Size
Humans are the slowest-moving parts in any complex organization. Teams can help us counteract this reality by making us smarter and faster. However, this outcome is possible only if we get teams right. Team dynamics is Scrum’s strong suit—and an arena Kanban addresses only tangentially, if at all. In fact, providing a framework that helps us improve team dynamics is a great example of how Scrum boosts Kanban’s capabilities.
To this end, size stands out as the most significant predictor of team success. There’s a right size for every team, and like so many other aspects of managing systems, that size should be dictated by overall context. Even so, having guidelines doesn’t hurt.
The military is a great starting point for gaining perspective on ideal team size. The basic unit in the U.S. Army’s Special Forces is the 12-person team. The army arrived at this number after recognizing there are certain dynamics that arise only in small teams. For example, when a team is made up of 12 or fewer people, its members are more likely to care about one another. They’re more likely to share information, and far more likely to come to each other’s assistance. If the mission is important enough, they’ll even sacrifice themselves for the good of the team. This happens in business, too.
The founders of Scrum understood these dynamics. Ask anyone in the Scrum community about ideal team size, and you’ll hear 7 members plus or minus 2.
The reasons for maintaining small team sizes are valid, but not every 12-person military unit is right for a particular assignment. Likewise, not every 9-person Scrum team is right for a given environment. Your system ultimately will dictate your needs, and it may very well require expanding your teams to incorporate a larger number of specialists or address some other need.
Scrumban supports this flexibility through its enhanced information sharing and visualization capabilities. Even the cadence of daily stand-ups is different: We’ve seen daily stand-ups in a Scrumban environment involving almost 100 individuals that are both effective in addressing organizational needs and capable of being completed within 15 minutes. This would be impossible in a Scrum context.
Iteration Length
Many organizations seek to establish uniform iteration lengths because they mistakenly believe this is a good approach for aligning different systems to the same cadence. Yet for many years, the general consensus among Scrum practitioners has been to recommend two-week iterations. What does the data tell us?
Rally Software’s data shows that almost 60% of the software development teams using its tool adopt two-week sprints, and I’ve seen similar patterns among users of ScrumDo. The data also suggests a team’s overall performance tends to be greatest at this cadence (Figure 5.2).
)
Figure 5.2 A view into the relationship between iteration length and team performance.
Source: © 2014 Rally Software Development Corp. All rights reserved. Used with permission.
Dig more deeply, however, and differences begin to show up among the various components of the index. Throughput, for example, tends to be greatest among teams adopting one-week iterations (Figure 5.3).
)
Figure 5.3 A closer look at productivity.
Source: © 2014 Rally Software Development Corp. All rights reserved. Used with permission.
Quality, in contrast, trends highest among teams adopting four-week cadences (Figure 5.4).
)
Figure 5.4 A closer look at quality.
Source: © 2014 Rally Software Development Corp. All rights reserved. Used with permission.
Every organization possesses characteristics that drive different outcomes, which is where Scrumban’s visualization and added metrics can help teams discover what’s best for their unique circumstances. The higher throughput typically associated with two-week cadences won’t magically materialize if the historical lead time for most of your completed work items is three weeks. Similarly, delivering completed work every two weeks won’t magically produce better outcomes if the customers can’t accept it at that rate.
Also, be wary of inferences drawn from data associated with teams that have adopted longer iterations. For example, Frank Vega recently made an interesting observation on this topic, recounting instances where teams chose longer iteration periods as a means of opposing (consciously or subconsciously) Agile transformation efforts because agreeing to a shorter iteration cycle would counteract their position that nothing of any real value could be delivered in such a short time period.
Estimating Story Points
Scrum prescribes the Sprint Planning ceremony as an event that determines which specific stories can be delivered in the upcoming sprint and how that work will be achieved.
Although Scrum itself doesn’t prescribe a particular approach or method that teams should use to assist with this decision making (other than expecting it to be based on experience), most Scrum teams use story points and team estimation techniques as components of this process.
Another process that teams use to aid their estimation efforts is Planning Poker—a consensus-based technique developed by Mike Cohn. With this approach, which is used primarily to forecast effort or relative size, team members offer estimates by placing numbered cards face-down on the table (rather than speaking them aloud). Once everyone has “played,” the cards are revealed and estimates discussed. This technique helps a group avoid the cognitive bias associated with anchoring, where the first suggestion sets a precedent for subsequent estimates.
Scrumban enables teams to begin measuring the correlation between story point estimates and the actual time spent completing development, measured from the time work on a story begins until the story is completed. Some teams reflect a strong correlation between their estimates and actual work time. Others are more sporadic, especially as the estimated “size” of stories grows. Teams using exponentially based story size schemes tend to be more precise with their estimates. Comparing the two charts in Figure 5.5 and Figure 5.6, it’s fairly evident that exponential estimation reflects a tighter band of variability in lead time—especially among smaller stories. The spectrum of variability is much wider across the Fibonacci series.
)
Figure 5.5 There tends to be only a loose correlation (if any at all) between estimated story points and actual lead time.
)
Figure 5.6 The correlation is slightly better in an exponential points scheme.
As with the data on sprint length, the way teams estimate the size and effort of work tends to correlate with overall performance (Figure 5.7).
)
Figure 5.7 The relationship between team performance and estimation schemes.
Source: © 2014 Rally Software Development Corp. All rights reserved. Used with permission.
It is not uncommon to find a lack of correlation between a team’s velocity, the average number of story points completed during a sprint, and actual throughput. Nonetheless, there are many instances when the estimating process works well for individual teams. As mentioned previously, it’s more challenging to work with this metric on a portfolio level involving multiple teams. Calculating relative correlation is one way that Scrumban helps teams gain a better sense of whether the ceremonies they engage in, such as estimation events, are providing sufficient value to justify the investment of time and effort.
Contextual Responsibilities
As teams begin to employ Scrumban, members will assume a range of new “responsibilities.”
First and foremost, team members must be groomed to challenge and question their team’s policies, facilitating team interest in and ownership of how they work. Fortunately, this basic concept should not be foreign to people already used to a Scrum context. A great way to promote and support this mindset is through the establishment of “working agreements.”5
Not surprisingly, Scrum’s existing ceremonies and artifacts implicitly support the notion of working agreements. Scrumban’s framework goes one step further, calling for the team to make such agreements explicit and to visualize them on their boards as appropriate. In many respects, they are akin to establishing an internal service level agreement between team members.
Ultimately, we want to develop leaders who help all team members acquire the ability to see and understand concepts like waste, blockers, and bottlenecks. Good leaders also ensure teams don’t get stuck in a comfort zone, by prodding team members to always seek out ways to improve.
As previously mentioned, although teams will experience work improvements simply from employing Scrumban independently, an active management layer is essential to realizing benefits at scale. Systemic improvements are less likely to occur without a manager who maintains contact, helps resolve issues outside the team’s domain, and oversees the extent to which teams devote time and effort on pursuing discovered opportunities for improvement. Setting expectations for this need at the kickstart helps ensure a more sustainable implementation.