Succeeding with Agile: Software Development Using Scrum (Addison-Wesley Signature Series (Cohn))

by Mike Cohn

None of these processes as described by their originators is perfect for your organization. Any may be a good starting point, but you will need to tailor the process to more precisely fit the unique circumstances of your organization, individuals, and industry. Alistair

In fact, to even refer to end states in a Scrum transition is incorrect; there can be no end state in a process that calls for continuous improvement.

We can never direct a living system, only disturb it and wait to see the response.... We can’t know all the forces shaping an organization we wish to change, so all we can do is provoke the system in some way by experimenting with a force we think might have some impact, then watch to see what happens. (2005, 22–23)

One factor contributing to the higher productivity and lower costs on agile projects may be that employees enjoy their jobs more. Fifteen months after adopting Scrum, Salesforce.com surveyed its employees and found that 86% were having a “good time” or the “best time” working at the company. Prior

Quality is improved because working at a sustainable pace prevents sloppiness. Quality is also improved through many of the engineering practices such as pair programming, refactoring, and a strong emphasis on early and automated testing.

Awareness that the current process is not delivering acceptable results • Desire to adopt Scrum as a way to address current problems • Ability to succeed with Scrum • Promotion of Scrum through sharing experiences so that we remember and others can see our successes • Transfer of the implications of using Scrum throughout the company

William Bridges, author of Managing Transitions, stresses the importance of selling the problem, not a specific solution to it (2003, 16).

Too many Scrum teams adopt the bare minimum of Scrum and stop there, deciding that the improvements already achieved through their new iterative and incremental work style are sufficient.

By not considering or trying new or improved technical practices, these teams forgo much of the improvement they could have made. I tend to think of such teams as having

learned to work iteratively but having not become agile. Gabrielle Benefield reports having witnessed this problem at Yahoo! while she was the compan...

The most visible symptoms of dysfunction in Yahoo! product development were at the project and team layer (centered around issues of planning, project management, release management, and team interactions), rather than at the technical practices or tools layer. As a result, Yahoo!’s initial focus was on the adoption of Scrum. There was active debate about whether agile engineering practices should als...

It may address the project’s most pressing issues. Introducing a team to the agile technical practices can solve an array of typical project problems, including poor quality, over-engineered solutions, long delivery cycles, and so on. There are other problems, though, that are not addressed by introducing these practices. For example, a project with a disengaged product owner will experience slow or incorrect decision making. This problem will not be remedied solely by introducing new technical practices. The same is true for a project with multiple product owners, each with a competing agenda, or for a project with strong personality clashes among team members. If y...

On the contrary, adopting an agile approach such as Scrum is a process of continuous improvement. There is no predefined end state. Because of this, it is incorrect to talk about a “complete transition” or a change process that takes too long.

As Beck and Andres so aptly point out, the best way to do that is iteratively. We explore how to use the Scrum framework, along with specialized communities of practice called improvement communities, to adopt and spread Scrum, bring about continuous improvement, and transfer agile ideas throughout the organization.

Beck, Kent, and Cynthia Andres. 2005. Getting started with XP: Toe dipping, racing dives, and cannonballs. PDF file at Three Rivers Institute website. www.threeriversinstitute.org/Toe%20Dipping.pdf

Benefield, Gabrielle. 2008. Rolling out agile in a large enterprise. In Proceedings of the 41st Annual Hawaii International Conference on System Sciences, 461–470. IEEE Computer Society. This paper provides detailed information on Yahoo!’s large Scrum

Elssamadisy, Amr. 2007. Patterns of agile practice adoption: The technical cluster. C4Media. This book, which is available as a PDF through www.infoq.com, focuses on the technical practices that should be adopted by agile teams. As such, it is complementary to the patterns presented in this chapter.

Striebeck, Mark. 2006. Ssh! We are adding a process.... In Proceedings of the Agile 2006 conference, ed. Joseph Chao, Mike Cohn, Frank Maurer, Helen Sharp, and James Shore, 185–193. IEEE Computer Society. Mark Striebeck describes how agile was introduced to the AdWords front-end application at Google. He describes the combination of a start-small and stealth approach, with new practices added incrementally.

I believe that the effort of adopting Scrum is best managed using Scrum itself.

Just as Scrum development projects use product backlogs, you should use an improvement backlog to track the effort of adopting Scrum in your organization.

When IBM began to adopt Scrum, its improvement backlog included the following items: • Increase the number of teams using Scrum. • Increase adoption of test automation. • Enable teams to implement continuous integration.

Figure out how to make sure each team has a product owner. • Determine how we’re going to measure the impact of adopting Scrum. • Increase the use of unit testing and test-driven development.

Improvement backlogs, such as the one shown in Table 4.1, are dynamic, with items coming and going as they are thought of, completed, found unnecessary, and so on. Much of what we discussed in Chapter 2, “ADAPTing to Scrum,” will find its way onto an improvement backlog. If you’re just starting with Scrum, your improvement backlog will emphasize creating awareness and desire. If the transition is already well underway, your improvement backlog may contain more items around developing the ability to do Scrum well, to promote successes, or to transfer it to other groups. Si...

There may be, for example, a community and associated improvement backlog for figuring out how best to do automated testing on Scrum projects, another for developing and becoming great ScrumMasters, and so on.

The small group that initiates, encourages, and supports an organization’s effort to introduce and improve at Scrum is known as the Enterprise Transition Community, or ETC.

As part of adopting Scrum, Farm Credit formed an Enterprise Transition Community it calls the Agile Champions Team (ACT).

Write a preliminary improvement backlog by convening a 30- or 60-minute meeting. Invite either your team members, a few people you know will be interested, or the whole department. Brainstorm things that you’d like to see improved. Conclude the meeting by asking if there is sufficient passion to pursue just one or two of the items, and then start with those.

He recalls how that team made a mistake common to many new Scrum development teams—talking about its plans rather than demonstrating its progress.

“Agile adoption requires a passionately engaged sponsor willing to make tough organizational changes that serve agile teams and their success” (2007).

Communityship requires a more modest form of leadership that might be called engaged and distributed management. A community leader is personally engaged in order to engage others, so that anyone and everyone can exercise initiative. (2009, 141; emphasis his)

An ETC is a working group. It is not a steering committee. During sprint planning, the ETC commits to completing some amount of work and demonstrating it at the end of the sprint. However, even more important than the tangible things the ETC accomplishes is that it ignites the interest of others. Members of the ETC can only achieve so much themselves.

In a self-organizing system, the leader has an important role to play, but creative and long-lasting change depends on the work of many individuals at many different levels and places in the organization. (2001, 5)

Articulate the context. Beyond conveying a vision of the organization’s agile future, the ETC must also help employees both understand the need to change and develop a desire to change. They do this by articulating the context of the change: Why? Why

now? Why Scrum?

Stimulate conversation. All sorts of good things happen when people talk. Debating the merits of various technical practices, sharing success stories, probing reasons for failure, and other discussions will generate ideas.

Provide resources. Adopting Scrum will take time, effort, and money. For example, individuals who are trying to figure out how to be more agile (say, learning how to write automated unit tests on a complicated code base) may need to be granted time away from their development projects. Because the ETC includes the most senior people involved in the transition, the ETC is in a position to ensure that both time and money are available.

Set appropriate aspirations. Change efforts with clearly defined and truly transformational goals are ten times more likely to succeed (McKinsey & Company 2008). The ETC is responsible for setting and communicating appropriate goals for the transition, which may (and probably should) change over time as the ...

To harness that passion, individuals with a common interest in improving the organization in a particular way (perhaps its adoption of automated testing) come together, form a community of their own focused on that improvement, and then run their own

sprints. These communities are known as improvement communities and are the topic of the next section.

If you don’t already have an ETC or equivalent group, identify several people who ought to be on the ETC. If you are one of them, begin forming this group. If you are not, share the idea of an ETC and improvement communities with others in your organization who can help form these groups.

An improvement community (IC) is a group of individuals who join together to work collaboratively to improve the organization’s use of Scrum. An IC may form when individuals notice an item on the ETC’s improvement backlog and decide to work together to achieve that goal. Or an IC may form because individuals see and are passionate about an improvement opportunity that hasn’t made the ETC’s radar yet. IBM, for example, has five ICs, which are focused on test automation, continuous integration, test-driven development, the role of the product owner, and the general use of Scrum itself.

This approach should be scaled up or down depending on the size of the organization undertaking the transition. A software development department of 30 people may have an ETC of 5 people and nothing more. A company-wide transition for a department of 200 developers may have a 10-person ETC (including representatives from groups outside development) plus a handful of improvement communities at any time. Things can scale from there as needed; IBM, for example, has over 800 people in some of its improvement communities.

An ETC states what it would like to see improved but not necessarily how to achieve that improvement. The how is left up to the improvement communities or Scrum teams. Additionally, keep in mind that an ETC’s biggest goal is to create an environment such that improvement communities identify their own goals and form spontaneously to address them. We will look at self-organization in detail in Chapter 12, “Leading a Self-Organizing Team.”

“grouplets.

We started with engineers from all over the company meeting every couple of weeks to brainstorm. Slowly, over time, we started turning into activists, planning to actually start improving things. We started building better tools and giving informal talks to different technical groups. (2007)

Notice that although this community met initially to brainstorm, they soon found themselves as activists with plans for actual improvements. Improvement communities act. This

What the testing community at Google did instead was find direct and immediate ways to help teams. Mediratta recalls how, in addition to building tools, the community found a unique way of providing concrete, short examples and advice about testing.

One day, toward the end of a long brainstorming meeting, we came up with the idea of putting up little one-page stories, called episodes, in bathroom stalls discussing new and interesting testing techniques. Somebody immediately called it “Testing on the Toilet,” and the idea stuck. (2007)

The most effective communities are usually those that form not in response to management dictate but because company culture or the ETC has created an environment in which communities can naturally emerge. J. F. Unson, a coach at Yahoo! during its large-scale Scrum rollout,...

At Yahoo!, in our Santa Monica campus, all the entertainment agilistas started a monthly ScrumMaster lunch. This happened organically as Scrum started to grow in the organization, witho...