Where to Begin?: Criteria for Choosing a Successful Scrum Pilot
|
 Based on the original work of Kane Mar, "Agile
Project Selection from a Portfolio of Projects"
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.
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.
Mar lives in Seattle.
When he isn't helping lead organizations through Scrum transformations, Mar
enjoys running with the bulls in Pamplona, Spain, big wave surfing in Hawaii, and free diving. To read his
thoughts on Scrum, visit his blog at www.danube.com/blog/kanemar.
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, ScrumCORETM, which provides
Scrum coaching to clients through public and private courses as well as onsite
engagements.
Currently, Szalvay serves as president of Danube Technologies, Inc.
In this role, he helps develop and define the company's vision and creates
initiatives that influence every aspect of the organization. In 2004, the Small
Business Administration recognized his leadership by naming him the Young
Entrepreneur of the Year.
|
