Each week, I find myself using
Jenga, Hasbro's wooden building block game, as an analogy for introducing agile
into the enterprise. Few topics are more hotly debated throughout the software
development community than how to apply the simple values of agile to big
business. Many approaches favor knocking down the entire Jenga tower to start
from scratch with an entirely new foundation of values and practices. Others opt
for the comfort of traditional management processes, with some agile practices
— like pair programming and stand-up meetings — sprinkled on top.
The reality is that most enterprise
customers are proud of their overall structure and starting over isn't an
option. So a game of agile Jenga is required to make it work. There are people
out there who know how to build bigger, better towers
and can identify the right pieces to move, doing so with a light touch.
Unskilled players can topple the tower by removing one wrong piece or by moving
the right pieces too roughly. Yes, there are plenty of case studies documenting
successful agile transformations, but there is little consensus in the agile
community about how to create a framework for the enterprise that doesn’t
sacrifice agile values. But the answer already exists: Scrum combined with
smart agile engineering practices.
Enterprise customers want a
framework that is structured enough to lean on when development is chaotic, but
also based on agile principles. After all, the Manifesto for Agile Software
Development outlines vital principles, but it doesn't provide a framework for
actually completing work. Therefore, many organizations have interpreted the
principles as antithetical to structure, allowing chaos to reign in what they
call a
Advertisement
"generalized agile implementation." Others have attempted to
integrate popular management frameworks such as ITIL, Cobit, and CMMI with
agile principles in order to introduce agile concepts in a less disruptive way,
but the result is often waterfall-ish.
The key to striking a balance that
is neither anarchistic nor traditional lies in our ability to break from the
assembly line mentality, in which a product's quality is perceived to be dependent
only on the quality of its individual parts. Traditional business process
experts seem to be addicted to compartmentalizing processes into functional
disciplines, which often unfold as a sequential chain that moves through
specification, design, build, integration, and testing to shipment. To
create teams that excel at those activities, we look for professionals who are
experts at their functional disciplines. There is an assumption that if each
individual contributor is the best, the end product will also be the best. On
the flip side, some general agilistas believe that churning out extremely high
quality product increments will guarantee success because a high quality
product is all they need. Whether a company is extremely traditional or
extremely agile, it still relies on the idea that high quality parts inevitably
create a high quality end product.
I argue that if we focus first on
the high quality vision or direction of the product, the necessary
requirements, architecture, engineering practices, and staff requirements will
materialize. Unfortunately, traditional development methodologies and processes
tend to focus on getting the inputs right first, while generalized agile emphasizes
micro-outputs rather than organizational success. If neither traditional nor
generalized agile answers how to organize teams of 50 to 500 developers in a
way that puts vision first, how do we ensure the organizational Jenga tower
doesn't have to be entirely dismantled, yet allow enterprises to maintain some
of their existing structure? And secondly, how can we do that while maintaining
a focus on agile values?
In order to remain relevant, agile
must shed its myopic view of engineering needs and software quality as ends in
themselves. Instead, agile needs to address software quality, engineering
efficacy, and the output of product in a way that supports the needs of the
business. In other words, agile processes should emerge from the drive to
create business value. The only framework I can identify that accomplishes this
without violating the values of the Manifesto or stepping on the autonomy of
engineers is Scrum.
Scrum asks that Product Owners (POs)
articulate, as specifically as possible, their vision of the product to
development teams. There is an underlying assumption that the PO represents the
interests of the organization at large because he or she is solely responsible
for determining what direction development output will take. The PO is also
responsible for prioritizing requirements that result in increments of
potentially releasable product at the end of every sprint. Collectively, the PO
and team members are responsible for authoring requirements that reflect both
the business interests and technical interests of the organization. The team is
responsible for executing on the requirements or stories to yield the highest
quality product possible, while communicating concerns about quality to the PO.
The tension between what the business wants
and what the team can do is what
makes Scrum such an effective vehicle for high quality production.
So where does engineering fit into
this mix? Scrum also asks that a PO communicate prioritized business needs, so
that the team can focus on technical output. Despite the illusion that
stakeholders and project managers in traditional projects provide detailed
business requirements to teams, the reality is that teams are often left to
interpret requirements documents without detailed input. The result is that
business decisions are made by software developers who may lack the necessary business
acumen. The flip side is that project managers, sometimes with no technical
expertise, end up interjecting themselves into technical decisions. Scrum
provides for defined roles in which POs are exclusively responsible for
business decisions, teams are specifically responsible for technical decisions,
and ScrumMasters watch the process to make sure those lines are not blurred,
trespassed, or ignored. This division of decision-making authority creates the
right tension to result in quality output with real business value. Although a
team with great Scrum business processes can generate business value, a team
that employs both the Scrum framework for management and agile engineering
practices -- such as test-driven development, continuous integration, merciless
refactoring, and pair programming -- can create higher quality output that
answers business needs, faster.
Agile engineering without Scrum's
structured framework can be chaotic and tends to succeed for small
organizations, in which business domain knowledge can be readily shared. Agile
engineering, when coupled with the framework of traditional management
processes, compromises agile’s values, forcing teams into a system that
requires functional divisions and big, speculative planning up front. Agile
engineering with Scrum allows agile values to spread across the organization,
imbuing business practices with an unrelenting focus on people, quality, and
output, rather than input-driven decision making.
As we seek to shift organizational
Jenga pieces around the tower to change everything from foundational principles
to engineering practices, we need glue to hold the enterprise together. Scrum
is that glue, especially for medium and larger sized enterprises. In practice,
it improves employee morale and retention, giving responsibilities to those who
can competently handle them. It creates trust within and outside of teams by
reducing unnecessary bureaucracy and builds awareness of business objectives by
incorporating product vision into each requirement.
If agile is to evolve from a set of
smart technical practices best suited for small teams into the best possible management framework for organizations of any size, it needs a wrapper that pulls together
covers everything from vision to tactics without impeding developers to do the
work they love. Scrum is that wrapper: a set of guiding principles and
practices that empower professionals to develop products that make everyone in
the organization proud. About the Author Katie Playfair is a CSM and Director of Client Services at Danube
Technologies, Inc. (www.danube.com). As such, she works closely
with the five Certified Scrum Trainers, strategic partners, and client service
representatives who comprise Danube's ScrumCORETM
team, coordinating hundreds of public and private Scrum training sessions
worldwide. She is committed to finding the right combination of Scrum services
for achieving successful Scrum outcomes, excellence in service and solid ROI. She
can be reached at
This email address is being protected from spam bots, you need Javascript enabled to view it
or visit www.danube.com.
Comments (5)
Tobias Mayer: ...
Good article, Katie. Thanks. I agree with you that Scrum works exactly because it is not a prescriptive methodology or a pre-defined process. It is a simple framework of principles and practices that allows organizations to create an Agile process suited to their own people, products and context.
Scrum offers organizations the freedom to be creative and releases them from the dictates of "industry experts". If Scrum does appear to fail for some, it will usually (arguably always) be seen that the failure comes from the mis-application or misunderstanding of the simple framework.
1
July 16, 2008
KatiePlayfair: ...
Hi John - Indeed, I think the point is that moving agile to the enterprise doesn't actually require something new - it simply requires the application of an agile management framework (Scrum) with smart agile engineering practices. We don't need to reinvent the wheel in trying to move agile beyond small-team/small-project environments. We already have Scrum that works to organize single teams of 9 or 100 teams of 9. I've considered how other flavors of agile address the enterprise-level implementation that is becoming more and more common and I can't think of any but Scrum that can do it, or that I've seen good examples of in diverse environments. Case study: Intel - http://danube.com/docs/case_studies/Intel_case_study.pdf
Gerald - I agree that many organizations underestimate the amount of discipline it takes to do either Scrum or agile engineering well. A common excuse is "oh we don't need to do THAT - we're agile!" Yes, a good Scrum and agile implementation may relieve some unnecessary overhead but it puts in to place necessary and effective overhead costs like regular meetings and communication. When teams leave off all overhead, we're back to chaos - another technique for burying organizational problems.
Paul - It's true - any process that's not done well will fail. But my question is what is the answer for enterprise level implementations if not Scrum? I'm having a hard time picturing how you can scale XP to meet business needs. That said, along with Scrum I think we need to advocate good engineering practices because you simply won't get all possible agility gains without a framework that answers both engineering and management issues. Thoughts?
2
July 15, 2008
John Voris: ...
I found little that the author said that was new. However, the emphasis on focusing on software quality and then applying that quality-centered focus on the other areas of Agile -- and using the basic tenets of Scrum - made the article useful to me.
3
July 10, 2008
Gerald Williams: ...
Re Pauls comment - interesting - Scrum has very few rules - so few in fact that I wondering which ones you would break once you have learned how to use them properly?
I believe that an organisation that is performing SCRUM in teams across the software delivery chain will soon find the issues preventing easy delivery - how it chooses to fix them once found will be the make or break for the organisation on whether it thought SCRUM was helping them or hindering them. The answer of course is it was helping them to identify constraints. It will be painful to have them visible each day -but they always existed - right?
http://www.scrumlabs.com
4
July 10, 2008
Paul Klipp: ...
I like scrum. I've used it at Lunar Logic Polska with all sized of projects without fail for five years. That said, there's more options on the table then scrum and chaos. I agree with Kent Beck, Ken Schwaber, and others who agree that an agile process should be modified to suit the team's needs only after it has been implemented correctly in its entirety. XP done wrong or Scrum done wrong, or any other agile process done wrong is just not dabbling with agile, it's screwing up in a colossal way and the solution is not necessarily scrum, but just learning to follow the rules before you learn to break them. A team that can't do that will fail with any method they choose.
Each week, I find myself using
Jenga, Hasbro's wooden building block game, as an analogy for introducing agile
into the enterprise. Few topics are more hotly debated throughout the software
development community than how to apply the simple values of agile to big
business. Many approaches favor knocking down the entire Jenga tower to start
from scratch with an entirely new foundation of values and practices. Others opt
for the comfort of traditional management processes, with some agile practices
— like pair programming and stand-up meetings — sprinkled on top.
