Scrum Shortcuts: Planning and Protecting
- Shortcut 7: Setting the Scrum Stage
- Shortcut 8: Plan the Sprint, Sprint the Plan
- Shortcut 9: Incriminating Impediments
This chapter is from the book
This chapter is from the book
This chapter is from the book
Now that your organization is eager to adopt Scrum and a team has been selected with the right attitudes and abilities, it is time to snap into action and get the show on the road.
The following three shortcuts not only help you to set the team on their course but also give you some tips and tricks to keep the project on track.
Shortcut 7: Setting the Scrum Stage lays down a range of suggestions to ensure proper foundations have been established to support a successful Scrum team. Shortcut 8: Plan the Sprint, Sprint the Plan provides specific, practical advice to ensure an effective sprint planning session. Finally, Shortcut 9: Incriminating Impediments offers advice to help control the impact of impediments during sprint execution.
Shortcut 7: Setting the Scrum Stage
Scrum teams require chemistry, and just as in a science lab, successful “chemical reactions” are much easier to trigger when the broader organization provides the suitable ingredients and environment to work with. As Mike Cohn (2009) astutely recognizes, “The changes required to reap all of the rewards being agile can bring are far reaching. These changes demand a great deal from not only the developers but the rest of the organization as well.”
Let’s examine some of the key organizational and environmental preconditions that should ideally be considered as part of your Scrum adoption plan.
Ensure Team Stability
Tom DeMarco and Timothy Lister (1999) identify a key mantra that any organization seeking close-knit teams should adopt: “Preserve and protect successful teams.”
I am comfortable admitting that I have worked on Scrum projects that I would consider to be less than successful. I can easily pinpoint the core reason for these subpar results: my inability as a ScrumMaster to keep the team together for the duration of the project. This problem often occurs when key developers are dragged off one project to work on a more urgent project (see Figure 3.1). Couple this problem with continual corporate restructuring (that seems to be happening more and more in these times of global financial difficulty), and it can be challenging to preserve great teams.
)
Figure 3.1. Beware of “more urgent” projects trying to drag team members away.
DeMarco and Lister (1999) also quantified the damage caused when rotating staff, concluding that “a reasonable assessment of startup cost (for a new team member) is therefore approximately three lost work-months per new hire.” This estimate doesn’t even take into account the less tangible costs such as lost momentum, damage to morale, and loss of valuable, tacit knowledge.
Adjust the Physical Environment
Without question, some of my most successful Scrum projects were those in which I was able to physically separate the Scrum teams from the rest of the organization.
DeMarco and Lister (1999) surmise why this may be the case:
- It almost always makes sense to move a project . . . out of corporate space. Work conducted in ad hoc space has got more energy and a higher success rate. People suffer less from noise and interruption and frustration.
I’ve worked with Scrum teams that had to operate in large, open spaces near the sales team who were frantically on their phones all day, every day. I’ve also had teams that had been hamstrung by the corporate facilities department who wouldn’t allow them to move a small, measly round meeting table into their areas. I could go on and on, but the bottom line is that separation and environmental independence is the holy grail.
Irrespective of whether you are able to reach this lofty goal, you should do everything in your power to ensure that the Scrum team sits together. Scrum can certainly work for distributed teams where collocation isn’t possible, but it’s not optimal.
Apart from the obvious daily logistical benefits that sitting in close proximity offers, James Shore and Shane Warden (2007) offer an even more important rationale for the collocation of the team: “Sitting together is the most effective way I know to build empathy. Each group member gets to see that the others are working just as hard.” Shortcut 3 goes into more detail regarding other key inclusions to incorporate into the physical working environment to ensure a physical space conducive to Scrum.
Estimates Are Not Guarantees
How is this for an infuriating scenario? The project sponsor casually strolls over to a team member and asks how long feature XYZ is going to take. The team member takes off her headphones, breaking focus from what she was working on, glances up and throws out a rough estimate to appease the sponsor. Lo and behold, the estimate proves to be inaccurate. The sponsor then applies immense pressure on the entire team to deliver on the promised “commitment,” and dammit, if that means missing your kid’s end-of-year concert, then that’s the price of sticking to commitments!
News flash: An estimate is not a guarantee. If it were, there would be no need for the word. An estimate is simply a prediction based on known information and input at a given point in time. This definition needs to be clearly understood by the project stakeholders before the project kicks off!
Work toward Reciprocity
Mary and Tom Poppendieck, authors of Leading Lean Software Development, put forward the notion that there are two kinds of companies in this world: remuneration companies and reciprocation companies:
- People who work in a remuneration company have this agreement with their company: “I will show up for work and you will pay me for my time. If you want more than that, pay me more.” On the other hand, people who work in a reciprocity company have this agreement: “I will treat you the way you treat me. I expect fair compensation, but if you want care and commitment on my part, then you agree that you will demonstrate care and commitment toward me, and you will help me develop my potential to its fullest extent.” (Poppendieck and Poppendieck 2009)
The best Scrum teams consist of committed and caring individuals, so it naturally follows that companies that embrace the reciprocity model are more likely than remuneration companies to have greater success with Scrum, especially in the long term.
Support Sustainable Development
Shortcut 1 mentioned that one of Scrum’s guiding principles is that team members should work at a sustainable pace.
In Agile Product Management with Scrum, Roman Pichler (2010) points out that
- developing a product is like running a marathon. If you want to finish, you have to choose a steady pace. Many product owners make the mistake of pressuring the team to take on more work.
Any organization that maintains a culture of late-night martyrdom and continues to not only respect but also explicitly reward ludicrous overtime is at conflict with one of the principles of Scrum (or any other agile framework, for that matter). Overtime should be the exception, not the rule, and as recognized by Kent Beck in Extreme Programming Explained (1999), it should be recognized as “a symptom of a serious problem on the project,” not simply business as usual.
Run a Pilot Project
Although there are certainly some advantages to taking the Big Bang approach to rolling out Scrum across an organization, I don’t advocate it. Instead, I’m a big believer in initially running a pilot project. I recommend this approach even if the business is champing at the bit to roll Scrum out en masse. Why do I recommend investing this additional time if not to help obtain validation and buy-in? Mike Cohn (2009) explains the reason perfectly:
- [A] pilot project is undertaken to provide guidance to subsequent projects; it pilots the way in doing something new. . . . As an industry we have enough evidence that Scrum works; what individual organizations need to learn is how to make Scrum work inside their organizations.
I always run pilot projects before rolling out across a broader group, and in fact, without the experimental freedom that a pilot project offers, I’m not sure if you would even be reading this book today!
It may be tempting to select a project to pilot that is low value and therefore low risk. This is a false economy. Shore and Warden (2007) reinforce this point:
- Avoid taking a project with low value as a “learning opportunity.” You’ll have trouble involving customers and achieving an organizational success. Your organization could view the project as a failure even if it’s a technical success.
Regarding team stability and the less-than-successful projects I experienced: the reason I couldn’t keep those teams together was that the pilot projects we were working on were not of high enough priority and value. When push came to shove and shared resources were being stretched between the pilot project and the “more important” projects, no guesses as to which lost out.
How long should a pilot project last? Well, if you’ve been reading this section carefully, you will conclude that your pilot project should be no different from any other important project. As Roman Pichler (2010) states, “There is no rule in Scrum that mandates how long a project can last. But, it is common for agile projects to take no longer than three to six months.”
Have Realistic Expectations
Change takes time, and very often with change, we need to take one step back to take two forward. Adopting Scrum requires a significant shift in organizational mindset that includes breaking entrenched habits, and this feat doesn’t happen overnight.
There is going to be lead time before the developers feel comfortable working in cross-functional teams and before the old command-and-control attitudes disappear. Based on this premise, the organization should not be naïve and expect amazing gains immediately. Patience and nurturing is the name of the game, and a supportive organization will no doubt see its investment reaping dividends in the near future.