Not a rugby aficionado? The term
means the mass of interlocked players – tough lads, fearless lasses – facing
off against their opponents when play restarts, each trying to kick the ball
back to their side for possession. Think order out of chaos. Some bleeding may
result.

Minus the cuts and bruises, the
Scrum development methodology is similar. Scrum calls for a single,
cross-functional group, ideally with 10 people – including business
stakeholders, multitalented tech folks and a ScrumMaster playing project
coordinator – all located in close physical proximity. Together they focus not
on tools or technologies, per se, but business results.

To do that, Scrum employs sprints –
originally four weeks long, now
typically two weeks in duration. Each sprint is a plan to deliver fully working,
tested and implemented code. For every sprint, the team together decides which
capability has top priority, creates a plan, delivers, then reviews what it’s
done.

Time to Sprint

Benefits to this "controlled
burst" approach include delivering more relevant software, lowering
business risk and creating more satisfied coders. "Every two weeks we get
the chance to improve what we’re doing, and we can do it with the customer,"
says Alan Atlas, a certified ScrumMaster trainer and agile development coach
with Rally Software in Boulder, Colo.
"No longer do we have to spend two years to see if something we build will
work."

Hierarchy? Stuff it. Scrum teams
self-organize. Waterfall approach? Don’t bother. What if the customer requests
change? Of course they will, so build in a mechanism for change requests and
reassessing priorities.

What if the business request doesn’t
work? "We’re very quickly able to tell the business
whether it’s viable or not, or whether it’s something they need to rethink,"
says Adam Monago, VP of client service for ThoughtWorks
Studios in Chicago.
In other words, the two-week Scrum sprint was still time well spent.

The Scrum Rush

Scrum isn’t news to many
businesses. Indeed, according to a 2009 survey conducted by Tom Grant, senior
analyst at Forrester Research in Cambridge, Mass., roughly one in three
software development teams used at least some kind of agile development – an
umbrella term that includes Scrum, Crystal Clear and Extreme Programming (XP),
Crystal Clear, lean and now kanban.

"Though Scrum is clearly, by
far, the most commonly adopted," says Grant, "it’s important to
stress that what teams are doing is a mixing and matching exercise."

Why mix and
match? One reason is to augment Scrum with software engineering best practices.
For that, Monago at ThoughtWorks Studios says many organizations also embrace XP, which
emphasizes test-driven development ("only write the code you need"),
continuous integration (build and link code regularly to prevent costly errors)
and refactoring ("constantly tweak the code and make it prettier").

Developers Play Ball

If you build Scrum teams, will
developers sign on? "Done well, Scrum seems to speak to a large portion of
the high-tech development community," says Rally’s Atlas. Points in its
favor include empowering teams, letting people see their direct impact on a
project, keeping people cross-skilled and thus marketable, and reducing
paperwork to a minimum.

But Scrum does have pitfalls. "Lots
of organizations leave a lot of money on the table by not going all the way,"
says Atlas. "There’s a great deal of difficulty and discipline involved to
get past 50 years of organizational memory about how we’re supposed to do
projects." Indeed, everything from management and support to HR systems
and compensation require rethinking.

Get Scrum Savvy

When it comes to mastering Scrum,
either as individuals or organizations, experts recommend studying the
fundamentals, but also bringing a coach onsite for the first few months to help
put Scrum theory into practice, starting with one team. Pick an important – but
not the most important – project. Do it well, start to turn heads, then expand
the Scrum rollout.

Remember that Scrum isn’t dogma,
but a lightweight, flexible mindset and framework focused not on tools and
technologies, but business results and short project phases planned and
executed in two-week bursts. In other words, practice Scrum well, and what
looked at first like chaos turns out to imbue software development speed,
flexibility and control.