Ask any Scrum trainer and they'll tell you the same thing: Adopting Scrum is hard. There are many reasons for this. Chief among them is that Scrum is so dramatically different-in terms of practices and principles-from traditional project management paradigms that it requires team members to truly reorient their attitudes and working behaviors. It's innate to human psychology to resist change and organizational change of that order is no exception. So, once an organization makes the commitment to adopt Scrum, how does it go about it? What first steps should it take to begin its Scrum transformation? One common way to initiate a Scrum transformation is through a pilot project. But even then, how does a team that's never used Scrum before tell if a project is a strong candidate for a successful pilot?

Unfortunately, there are no black-and-white criteria for selecting a pilot, but there are some very important considerations to take into account. When an organization is ready to try Scrum, there's more at stake in that pilot than the success of the project itself. Namely, it's also an opportunity to illustrate the value of Scrum-in boosting quality, reducing costs, and slashing overall cycle time-to management and stakeholders. When management supports the initiative, it's much easier for organization-wide change to occur and the likelihood of Scrum spreading to additional teams increases.

Before we move on to examine which attributes the most successful pilot projects possess, it's worth considering what the effects of a poorly chosen pilot are. Quite simply, a haphazardly selected trial project will supply an organization with the proof that Scrum can't work there. Of course, that diagnosis would likely have as much to do with the project itself as Scrum-or any other management paradigm for that matter. Remember: Scrum isn't a silver bullet. If a project is floundering, whether from an incommunicative or unavailable manager or code that is irreversibly buggy, then Scrum can't be expected to revive it. Instead, a Scrum pilot requires as much of a "blank slate" as the organization can provide. Only those projects with few pre-existing impediments have the potential to showcase how Scrum can radically impact collaboration and productivity and, from a business perspective, costs and release forecasting.

So what attributes of a project make it a good pilot from a business perspective? A project with high visibility for managers and stakeholders is a good place to start. Of course, the best way to ensure that management will be paying close attention to a project is to choose one that has a direct impact on the bottom line. After all, no testimonial of Scrum's potential can speak as loudly or as convincingly as the facts of finishing on-time and under budget. Pilots with the potential to contribute significant business value are ideal because, when they succeed, they generate a buzz around the new paradigm that starts at the top and spreads organically throughout the organization.

Of course, what kind of project the pilot is also plays a crucial role in its prospects for success. For example, is the work to be done new development or is the project already underway? Given a choice between those two options, we'd always recommend that organizations use greenfield projects as pilots because it gives developers a carte blanche for Scrum to succeed. When a team inherits a migration project, it must navigate existing code, which, when added to the task of acclimating to Scrum, can be a distracting burden.

Similarly, an ideal pilot has a single business customer or, in Scrum parlance, Product Owner. In fact, this single factor is likely the most important in determining if a pilot will sink or swim. Given the inherent uncertainty that accompanies a pilot project, a committed Product Owner can dramatically reduce indecision and inaction. With a single individual who can communicate vision, resolve conflicts, and remain available to answer questions, a team can enjoy some stability in the midst of feeling its way through a new process. Without a committed business customer, the team has less leadership and direction to help them succeed. When their attention is monopolized by guesswork (i.e. trying to figure out what the business customer wants them to do), they are hardly equipped to focus on learning the principles and processes of a new management paradigm. In that scenario, the uncertainty of a new method of working would only compound the confusion generated by deficient leadership.

Perhaps it goes without saying, but it should nonetheless be mentioned that a Scrum pilot is subject to the same issues that make other projects successful or plague them with impediments. If a team is spread out geographically-across multiple offices or even time zones-the ease with which it can communicate and collaborate effectively is reduced as the distance between them grows. Likewise, if the team is not cross-functional, it may be hamstrung with dependencies. And, as described above, a team that lacks dedicated leadership and clear direction is likely to waste time and effort attempting to interpret poorly defined Sprint goals. When these factors are in play, it can be assumed that it's not an ideal situation for implementing a new management framework. However, when teams are collocated, made up of cross-functional members, and working with a set of clearly defined requirements, Scrum projects will always fare better - and that is especially the case with Scrum pilots.

Another ingredient for a successful pilot addresses technological issues. Namely, does the pilot team have access to the necessary tools and is it using agile engineering techniques? Clearly, a team requires the right tools to do its job, but it can also increase the likelihood of the project's success by using development practices that complement Scrum. Examples include Continuous Integration, Test Driven Development, and Pair Programming. Moreover, when teams are geographically distributed, a Scrum tool may be required to bring teams together for the kind of high-impact collaboration that Scrum facilitates.

Finally, the single biggest asset for identifying the right Scrum pilot is experience. An experienced Scrum coach or mentor can essentially intuit which projects will make the best pilots. Having lived through multiple Scrum projects, this individual can quickly assess how all the factors in play will affect the outcome of the trial project. An experienced coach might recognize red flags and other negative signals that would fly under the radar of someone who has learned about Scrum as a student, rather than practitioner. As such, there is no substitute for experience and such a mentor or coach can be an organization's biggest ally when introducing Scrum. Not only can they steer teams away from common pitfalls, but they can shepherd teams toward the kind of best practices that yield highly performing teams. Moreover, he or she serves as a Scrum authority, who can quickly reiterate Scrum's principles and processes, often with real-world examples that illustrate the philosophy that informs them. For an individual with that breadth of hands-on Scrum experience, spotting the right pilot is second-nature.

While there's no magic formula for choosing a Scrum pilot, the above considerations-business value, project type, and technology issues-can help teams make an informed decision about where to begin their Scrum journey. Yes, Scrum is both hard and disruptive, but, by taking into account the above factors, those disruptions can be minimized. An organization's greatest asset is always someone who's gone through the process before and knows how to navigate the myriad organizational factors that influence a pilot's success. After all, an experienced Scrum practitioner can help teams make wise decisions at every stage of a Scrum transformation, especially where to begin.

Based on the original work of Kane Mar, "Agile Project Selection from a Portfolio of Projects"

About the Authors

Kane Mar is a Certified Scrum Coach and one of Danube's Certified Scrum Trainers, specializing in Scrum and Extreme Programming. Mar has worked exclusively with Agile software development teams since 2001 and has worked with clients such as Qpass, Microsoft, Capital One, Progressive Insurance, and TransCanada Pipelines. His focus is on creating highly performing Scrum teams that deliver high quality software and maximize business value.

In August 2000, Laszlo Szalvay, along with his brother Victor, co- founded Danube Technologies, Inc. in Seattle. Although Danube originally was created to manage outsourced software projects, the company's focus soon shifted to helping organizations transform to Scrum software development management practices. Danube first developed an internal tool to improve its own processes and then offered it for free to the market. It became such a success with clients that, two years later, Danube developed and introduced its flagship product, ScrumWorks® Pro. In 2005, Danube extended its offering by developing a new services division, ScrumCORE^TM, which provides Scrum coaching to clients through public and private courses as well as onsite engagements.