The Criteria for Choosing a Successful Scrum Pilot

[article]

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,

User Comments

1 comment
T. Pot's picture

"...an opportunity to illustrate the value of Scrum-in boosting quality,"  In my experience, SCRUM, most definitely, does not increase software quality.  It helps to "test in" quality (we'll fix it in the next release), a known worst-practice.

If done right, Agile can produce quality software.  Make sure there is heavy Product Owner (end-user SME) involvement.  If the stories don't pan out at demo time, drop them from the iteration, so only quality code is released.

January 2, 2014 - 3:59pm

About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 22
Sep 24
Oct 12
Nov 09