Chapter 5. Your First Projects

Unless you are operating in stealth mode, all eyes will be on the first project to try Scrum, especially during the first sprints. Selecting the right project and team is critical. Your initial Scrum project should be one that is considered important and significant, so that the results are not discounted, yet not so large that it is ungainly. Team members should be selected with an eye toward not only their compatibility but also their willingness to try something new.

As the first sprint starts, expectations about the advantages Scrum will bring may be sky high. Sometimes this is the result of general optimism; other times it is the result of zealotry by an organization’s early agilists, whose exuberance leads others to think Scrum will cure all ills. You must correctly set and manage these expectations; otherwise an initial project that should be viewed as wildly successful will instead be considered a dismal failure when it does not live up to oversized expectations.

In this chapter we consider the critical topics of selecting the right first project and assembling the ideal team, and the subtle art of setting realistic expectations.

Selecting a Pilot Project

I was about to start this section with something like, “Scrum pilot projects have become more and more rare over the past four years. The benefits of Scrum have become so recognized that companies are now forgoing pilot projects and jumping right in.” And then I decided that perhaps I should look up the definition of pilot project. Perhaps, like inconceivable to Vizzini in The Princess Bride, it did not mean what I thought it meant. What I found was that there are indeed two slightly different meanings. One is that a pilot project is a test, with the results used to determine if more of whatever is being tested will be done. This is the type of pilot project that most companies now bypass—they know they want to use Scrum; they don’t need to “pilot it” to verify that.

The other definition I found is that a pilot project is undertaken to provide guidance to subsequent projects; it pilots the way in doing something new. It is this second meaning that I’m interested in—the pilot that leads the way rather than the one that is conducted as a test. 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. So, they often conduct one or more pilots as learning projects.

Four Attributes of the Ideal Pilot Project

Selecting the right project as a pilot can be challenging. Jeff Honious, vice president in charge of innovation at Reed Elsevier, led his company’s transition to Scrum. He and colleague Jonathan Clark wrote of their struggle to select the right pilot.

Finding the right project was the most critical and challenging task. We needed a meaty project that people would not dismiss as being a special case, yet we did not want a project to fill every possible challenge—too much was riding on its success. (2004)

Not every project is equally suited to be your first. The ideal pilot project sits at the confluence of project size, project duration, project importance, and the engagement of the business sponsor, as shown in Figure 5.1. You may find it impossible to identify the “perfect” pilot project. That’s OK. Consider the projects you do have and make appropriate trade-offs between the four factors presented in Figure 5.1. It is far better to pick a project that is close enough and get started than it is to delay six or more months waiting for the perfect pilot to present itself.

Figure 5.1 The four attributes of the ideal pilot project.

Duration

If you select a project that is too short, skeptics will claim that Scrum works only on short projects. At the same time, if you select a project that is too long, you risk not being able to claim success until the project is over. Many traditionally managed projects claim to be on track 9 months in to a 12-month schedule, yet in the end are over budget and late, so a Scrum project proclaiming the same may not be very convincing.

What I find best is to select a project whose length is near the middle of what is normal for an organization. Ideally and frequently this is around three or four months. This gives a team plenty of time to start getting good at working within sprints, to enjoy it, and to see the benefits for the team and for the product. A three- or four-month project is also usually sufficient for claiming that Scrum will lead to similar success on longer projects.

Size

Select a project that can be started with one team whose members are all collocated, if at all possible. Start with one team, even if the pilot project will grow to include more teams. Try to select a pilot project that will not grow to more than five or so teams, even if such projects will be common in your organization. Not only is coordinating work among that many Scrum teams more than you want to bite off initially, but you also probably wouldn’t have time to grow from one team to more than five anyway if you are also looking for a project that can be completed in three or four months.

Importance

It can be tempting to select a low-importance, low-risk project. If things go badly, not much will be lost. And people may not even notice a failure on a low-importance project. Don’t give in to this temptation. Instead, pick an important project. An unimportant project will not get the necessary attention from the rest of the organization. Additionally, some of the things required of a team transitioning to Scrum are difficult; if the project isn’t important, people may not do all that is required of them. Early agilist and inventor of the Adaptive Software Development process Jim Highsmith advises, “Don’t start with an initial ‘learning project’ that is of marginal importance. Start on a project that is absolutely critical to your company; otherwise it will be too difficult to implement all the hard things Scrum will ask of you” (2002, 250).

Business sponsor engagement

Adopting Scrum requires changes on the business side of the development equation, not just the technical side. Having someone on the business side who has the time and inclination to work with the team is critical. An engaged business sponsor can help the team if it needs to push against entrenched business processes, departments, or individuals. Similarly, there is no one more useful in promoting the success of the project afterward than a sponsor who got what was expected. One sponsor commenting to another that a recent project tried Scrum and delivered more than past projects did will do wonders in getting other sponsors to ask their teams to also try the new approach.

Choosing the Right Time to Start

That so many new exercise programs and diets begin on New Year’s Day is testament to the human desire to align change with outside factors, such as the calendar. Just as we may feel that exercise programs should begin on the first day of the year, we may think that a new software development process should be introduced on the first day of a new project. Choosing a new project (or restarting a failed one) for your pilot lets you make a fresh start. Teams who have chosen to start fresh begin by focusing on the product backlog. Such a team will usually wait to begin its first sprint until it has created a product backlog that contains all of the features that are known at the time. Trond Wingård, an agile project manager, has been successful with this approach.

In one of my first agile projects, our client had already spent one year and approximately $150,000 to have another contractor write a classic requirements document. I was able to convince our client that we should replace this requirements document with user stories. So the 150-page document was replaced with a product backlog with 93 user stories. We would not have been able to do agile if we hadn’t done this.

Making a fresh start has only one major disadvantage: Waiting for a new project to appear—and then hoping you think it is a suitable first Scrum project—needlessly delays the benefits Scrum brings.

Resurrecting a failed project can also bring a fresh start feeling to your pilot. Spending a few days creating its product backlog can help restore focus to the project team, reengage stakeholders, and create buy-in throughout the organization. Remember when starting fresh that you don’t want to spend weeks (or months!) bogged down in creating your preliminary product backlog. Consider the irony of starting your Scrum transition with a two-month requirements-gathering phase. When starting fresh, have the discipline to write the backlog quickly and in as lightweight a manner as possible.

Impending Doom

Sometimes starting fresh is either not possible or not the right choice. If a project is in midstream and could benefit from Scrum, I see no reason not to switch. My personal favorite pilot projects are ones that are currently headed toward impending doom yet still have enough time to recover and succeed. Although this can be a risky approach, a struggling project has nowhere to go but up. Delivering at all is often viewed as a success; delivering on time is often viewed as an amazing success. Because of the focus and intensity created through working in short sprints and because of the emphasis on creating at least some forward progress, Scrum is often ideally suited to these types of projects, especially when an experienced Scrum-Master or consultant is available to the team.

As the chief technology officer of Sammy Studios (now High Moon Studios), Clinton Keith knew something drastic was needed. His team was developing what was to be a Triple-A video game for the Sony PlayStation and Microsoft Xbox. Teams were working hard, but the game was not coming together as quickly as the development studio’s off-site owners had hoped. Without a change the project would fail.

Fortunately, at about this time Keith learned about Scrum and decided to introduce it to his teams. Employees of game studios are distinguished by a fierce amount of individualism, so introducing a process that would require lots of talking, collaboration, daily scrums, and other similar hallmarks of Scrum was difficult. Wisely, Keith chose to introduce Scrum at a time when team members were becoming aware that the current process and approach was not likely to lead to the finished product that all desired.

Another common time when you might want to stress the risk of impending doom is when the company will go out of business, or (in a more diversified company) cancel the project, if development continues at its current pace. Anytime a continuation of the status quo has serious repercussions, demonstrating the impending doom of inaction can help fuel Scrum adoption. After all, if doing things the “old way” will only lead to failure, it’s easier to convince team members to try something new, experiment with different practices, and make a leap to Scrum they would otherwise resist.

Forecasting impending doom can be powerful but is also dangerous. For it to work, the peril faced by the project or organization must be real. In one company where I worked, our CEO was notorious for announcing that the fate of the company rested on every project we undertook. Cry wolf enough times and people stop believing. You, too, may be tempted to exaggerate the peril; don’t. However, if a project is on its way to failure unless dramatic action is taken, point it out. Team members probably know already but are reluctant to acknowledge it. Additionally, if team members have become apathetic about their project and their work, I will sometimes point out a likely doom that may occur if things don’t change. I used this recently with a team who knew its company was in merger talks with a competitor. “So,” I asked members, “when this merger finishes and the big bosses of the combined company are trying to figure out which projects are redundant and which teams should get the best new projects, how would you like this project and team to be viewed?” This jolt of awareness is just what some teams need.

Selecting a Pilot Team

The intersection of the four factors of Figure 5.1 and the discussion of timing leave out probably the most important factor in the success of a pilot project—the individuals involved. I deliberately chose to leave people out of the discussion of selecting the right pilot project under the assumption that we can select the project and team independently. That is, we can select the best project as our Scrum pilot and can then look around and assemble the right team for that project. I understand this is an uncommon luxury in many organizations—the project and the team often come as a package, just like the ham and eggs in a Scrum team’s favorite breakfast. If you cannot separate the decisions of the ideal pilot project and the ideal pilot team, simply consider all factors together in selecting the best available pilot.

Put initial teams together with an eye toward compatibility, constructive dissension among team members, willingness and ability to learn and adapt, technical skills, communication skills, and so on. Of these, the most important consideration in selecting a pilot team is the willingness of the individuals to try something different. Ideally, all will have moved through the awareness and desire steps of the ADAPT acronym presented in Chapter 2, “ADAPTing to Scrum.” When presented the opportunity to influence who will be on the pilot team, I look to create a combination of the following types of individuals:

• Scrum lobbyists. The project may not be big enough to include everyone who has been lobbying to adopt Scrum, but I want to be biased toward including as many of these individuals on the project as I can. It would be painful for them to have to be on the sidelines even though they’d still be hopeful for the project’s success.

• Willing optimists. These individuals understand that a new development approach is needed but didn’t go so far as to actively argue for a change to Scrum in the past. Knowing what they now do about Scrum, they believe it sounds promising and want to see it succeed.

• Fair skeptics. I don’t want someone on the project who will work to sabotage the pilot or the teamwork necessary to become a Scrum team, but this does not mean I want to avoid all skeptics. It can be very beneficial to include a well-respected, vocal skeptic as long as the skeptic has demonstrated a past willingness to admit being wrong or change an opinion. These individuals can become some of the transition’s strongest supporters when convinced of the benefits through hands-on experience.

Of course, all of this must be mixed with an eye toward combining the right set of skills for the project. If your pilot project’s goal is to develop a video game, you had better put an animator on the team. I also look for individuals who have a track record of working together successfully. Sometimes you find an existing entire team that can become the pilot team. Other times, you can think back over the past few years and put together people who worked together well on past projects.

What if a Pilot Isn’t a Success?

What if, after all your decision making, planning, and hard work, the pilot project fails anyway? First, you would be wise to avoid pinning all your hopes on one big pilot project. Instead, run multiple pilots and keep in mind that the purpose of a pilot project is to illuminate the way for the Scrum projects that follow. The most successful pilot projects will be able to create advice of two forms: do this and don’t do that. As long as the teams involved in the pilot learn about what is likely to work or not work, which aspects of Scrum will be easily brought into the organization, the types and sources of organization-specific resistance, or any other similar information, then I am reluctant to call the pilot a failure.

But, what if the pilot project fails to deliver the expected results?

In these cases I start by assessing whether the expectations placed on the project were realistic. Perhaps before starting the project we agreed they were, but by the end we’ve learned otherwise. If that’s the case, clearly communicate this to all stakeholders. Don’t do so as an excuse for failing to deliver what was expected. Stakeholders need to know that the team accepts responsibility for any part it played in setting or agreeing to overly optimistic plans. But do make sure that stakeholders understand that although the pilot failed to meet all expectations, it may, in hindsight, have done as well or better than should have been expected.

At the end of a Scrum pilot, I find that the pilot project is often compared to the unrealistic assumptions of a perfectly run sequential (“waterfall”) project. There may be an old Gantt chart around showing a project plan that allows for two months of analysis, a month of design, two months of coding, then concludes with a month of testing. This very idealized six months is then compared to the reality of a first-ever Scrum project that, let’s say, also took six months. The opponents of Scrum will say, “See, there are no advantages. It takes the same amount of time each way. And the old process has better design and is more maintainable over the long run.” The unfair comparison here is between the reality of a Scrum project that took six months and a plan showing a waterfall project delivering in the same schedule. Do not allow (or make) comparisons between the reality of one project and the myth of another.

Setting and Managing Expectations

That brings us to our next topic: setting and managing expectations. In 1994 I managed a team that delivered a project that any outsider or any project team member would have considered a success. The product represented a great leap forward for the company. It included far more features than the product that was being replaced, was built using new state-of-the-art technologies with which the company had no prior experience, and included the development of three data centers that went on to provide 99.99999% uptime over the next six years. However, the project was almost considered a failure.

The project was to be delivered into multiple call centers with more than 300 nurses on the phones. It was to replace a quirky but familiar system that the company was rapidly outgrowing. The nurses’ expectations of what the new system would deliver were sky high. In monthly sprint reviews with the nurses, I was routinely shocked by what they’d come to expect, some of which wasn’t even technically feasible. With about three months left on the year-long project, I realized my focus had to change. From then on, I spent almost all of my time on expectations management. I met with nurses in each of the call centers and described exactly what would and would not be in the delivered system. I toned down their expectations about the system’s impact on world peace, global warming, and personal weight loss. Without this effort, the product would have been perceived as a failure.

Since that project, I have been acutely aware of the importance of expectations management to the overall success of any project. Setting and managing expectations is perhaps even more important at the start of a major shift such as adopting Scrum. In initiating a transition to Scrum, I find it helpful to set and manage expectations about four things: progress, predictability, attitudes, and involvement.

Expectations About Progress

If peripherally involved stakeholders and outsiders have heard one thing about Scrum, it is probably that teams will be faster. I witnessed this when I was invited to speak at a large Silicon Valley company that had been previously visited by a Scrum consultant who oversold company executives on the benefits of Scrum. When I presented to the same group, I started by asking what they knew about Scrum already. All they could recall from the prior session was, “Teams will go faster, and we can change our minds whenever we want.” After recovering from my stunned silence, I told them that those two things could be true but a lot of hard work would be required to get there, and there would be a productivity cost to changing their minds too often.

As for expectations that a team will go faster, Jim Highsmith’s advice is much more conservative and realistic.

In a six-month project, the goal might be to match historic productivity levels (down in the beginning, up at the end) while improving quality and better matching with customer expectations. Putting too much pressure on early will cause teams to abandon their newly minted practices and revert to the older ones in which they still have more confidence. (2005)

Whether a team is more productive or not will largely be a function of how well the team was doing before adopting Scrum. A team that is already doing reasonably well (having learned to work around the inefficiencies and impediments of the current organization and process) will likely, as Highsmith says, slow down at first. In contrast, a team that is really struggling could indeed be faster right from the start.

There are two things, though, that I have observed to be nearly universally true of teams right from the start:

• Most teams will overestimate how much they will achieve in the first sprint. Unless a team has significant prior experience working in truly timeboxed iterations, team members will probably think they can get more done in a few weeks than will be realistic. A team, for example, may collectively commit to completing 850 hours of planned work in the coming four-week sprint. In the end, the team finds that due to interruptions, unplanned work, corporate overhead and other factors, they complete only 725 hours of that planned work. They worked just as hard as they had planned to; they were able to complete less planned work, though, because they underestimated all other demands on their time.

• Most teams will be more useful. I’m using the term “useful” here for what we probably mean by “productive.” But “productive” carries with it connotations of how much product was produced; and usually in a software project it isn’t far from that connotation to measuring lines of code. While I’m not completely opposed to measuring lines of code (and do it myself for some purposes), I don’t want to say that Scrum teams start out writing more code per period of time, especially because more code may or may not be a good thing. What I do want to claim is that right from the start, most teams begin to do more useful work shortly after adopting Scrum. This is because sprints focus their attention on “what can we do in the next such-and-such weeks.” Many traditional projects stall trying to find “the best” or “the right” or “the complete” solution. A Scrum team will be more likely to find a good-enough solution, try it, learn, and change as needed.

Expectations About Predictability

When I was running development organizations, rather than consulting to them as I do today, keeping my teams productive was not my only concern. I was equally concerned with whether I could make predictions about how long a team would take to finish a project. In many ways, I preferred a team that went at a reasonably consistent (and therefore predictable) pace to a team that sometimes went amazingly fast but that also sometimes went very slow. When piloting an organization’s first Scrum projects, you should be clear with stakeholders that the pace will initially be less predictable than with the organization’s prior approach to software development.

Scrum teams measure progress using a metric known as velocity, which is a measure of the work completed (or planned to be completed) in a given sprint. It is expressed in units such as story points or ideal days. Velocity is particularly volatile during a team’s or an organization’s first few sprints. After all, the team is learning to work in a new way, and many of the team members may be learning to work with each other for the first time.

It is important to communicate to stakeholders that early calculations using velocity will be particularly suspect. For example, after a team has established some historical data, it will be useful to say things like, “This team has an average velocity of 20, with a likely range of 15 to 25.” These numbers can then be compared to a total estimate of project size to arrive at a likely duration range for a project. A project comprising a total of 150 story points, for example, may be thought of as taking from 6 to 10 sprints if velocity historically ranges from 15 to 25.

Until a team has sufficient historical data, though, projections like this can be very risky. This means that a high-risk contract with large penalties for late delivery is probably not an ideal Scrum pilot. (Nor is it an ideal pilot for any process change.) So how much data do you need before you can make projections like this? The easy answer is the more, the better. You can start making predictions after a team has completed its first sprint, but you should do so with a wide margin of assumed error around that first observed velocity. Perhaps more helpfully, I’ll say that the velocity of most teams will stabilize sufficiently after the third or fourth sprint. Don’t take this as a rule; if there are a lot of other things changing in a project’s environment (such as new technologies, team members coming and going, and so on), velocity may very well bounce around longer.

Expectations About Attitudes Toward Scrum

After having been given time to adjust to working in a new way, most developers prefer Scrum. A survey at Yahoo! found, for example, that 85% of all team members would continue using the Scrum approach they’d adopted if the decision were left solely to them (Deemer et al. 2008, 16). But this usually won’t be where attitudes start. Those initiating the transition need to be prepared for lots of objections and complaining at first. Common complaints include the following:

• All the time wasted in daily scrums

• The time wasted in making sure the product is well tested at the end of each sprint, even though it won’t ship that often

• Managers not being able to assess me well enough to write my annual review because they can’t tell which work is mine

• The system falling apart six months after release because we’re not producing adequate maintenance and support documentation

At the first sign of trouble, there will be a temptation to give in and fall back to the old way of doing things. As Daryl Conner, author of Managing at the Speed of Change, has written, “It is relatively easy to get your people to acknowledge that a change is to be made and to get started on it. The really tough job is to get them to stick with it when the going gets tough” (1993, 116). One of the best ways to head off a slide back to old habits is to anticipate it and talk about it in advance and for team members to agree that when obstacles arise, they will stick to Scrum despite the discomfort and worry.

Expectations About Involvement

One of the most important expectations to set early on is about involvement in the process. Many project stakeholders accustomed to traditional-style development view their role in a software development project as akin to dropping a car off for service: You tell someone what you need done and come back at an appointed time to pick up the finished work. Stakeholders, especially anyone in a product owner role, will need to understand that this is not the right way to build software-intensive products.

Be sure to discuss expectations with the product owner and with other stake-holders whose input and feedback you will solicit either during the sprints or during sprint reviews. Make sure that each stakeholder knows what level of commitment the team expects and needs.

Scrum is not a silver bullet that will eliminate a development organization’s problems. You should work right from the start to make sure that expectations do not rise to unrealistic levels. Managing expectations will be perhaps one of the most important things you can do early on. If you don’t, you run the risk of an otherwise successful Scrum transition being viewed as a failure.

It’s Just a Pilot

Pete Deemer, an independent Scrum consultant, was the chief product officer at Yahoo! when he initiated a program there to pilot Scrum. He recognized that a pilot project is an experiment, and the purpose of that experiment is to gain knowledge that will help later projects succeed. Deemer also recognized that by calling them pilot projects, he was acknowledging that he knew things would not always go smoothly. He said his hope was that “when difficulties cropped up, people would be more likely to just roll up their sleeves and try to find a solution.” Deemer was using the label pilot to create some safety around the execution of the process.

Deemer recognized this safety as the valuable thing it was. It created the comfort zone teams needed in which to experiment so that they could be successful in finding the right ways to do Scrum. A year into the company’s transition effort, though, and with well over one hundred Scrum teams, Deemer was still calling every project a pilot. I asked him when he would stop calling them pilots. He told me that until every project at Yahoo! had adopted Scrum and until they knew everything there was to know, he would continue to call them pilots.

Whether you view every project as a perpetual pilot, the first few sprints will be tremendously important. You can help ensure these initial sprints start your teams on the right path by carefully selecting the right first project and team members and by accurately setting and managing expectations.

Additional Reading

Karten, Naomi. 1994. Managing expectations. Dorset House.

A good, easy-to-read book with solid advice. The book is focused on customer communication but almost all of its advice is applicable to other workplace relationships. Advice is provided on topics such as listening, clarifying perceptions, avoiding conflicting messages, and creating win/win solutions.

Little, Todd. 2005. Context-adaptive agility: Managing complexity and uncertainty. IEEE Software, May–June, 28–35.

Author Todd Little, a board member of the Agile Alliance and cofounder of the Agile Project Leadership Network, presents a framework for categorizing projects as Bulls, Colts, Cows, or Skunks based on the amount of uncertainty and complexity inherent in the project. The framework could be applied to choosing an initial Scrum project, where you avoid selecting the type of projects that Little calls Bulls (high-uncertainty, high-complexity projects).