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.
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 the figure below. 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 the figure shown below. 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. 
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 to them and to 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 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 gave advice about this in Agile Software Development Ecosystems.
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.
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.
And Finally: People.
I’m not forgetting the importance of the people involved to the success of a pilot. The people involved are, of course, the most important factor in the success of any project. The advice provided in this blog post assumes that you have already chosen the appropriate team and are now seeking to match them to the best possible pilot. Additional advice on selecting the individuals who will form pilot teams is given in the “Selecting a Pilot Team” in Chapter 5, “Your First Projects” of Succeeding with Agile.
