WITH A CAPITAL “A”
On June 3, 2009, Plante & Moran attended the ABSTRACT
Midwest Technology Leaders (MTL) Conference, an Many organizations believe they’re software
event that brings together top technology development methodologies are agile. More still
professionals in the Midwest to share trends, best
want to become agile.
practices, and opportunities.
Interestingly, there are levels of agility. There’s
With the help of MTL, Table Sponsors, CIOs, and “agile,” and there’s “Agile.” How do you really
additional conference attendees, we conducted 12 know when you’re Agile with a capital “A”? Read
roundtable discussions on a variety of timely and on to learn more.
important IT topics.
As an outgrowth of the roundtable discussions, we INTRODUCTION
produced a series of educational white papers. In the late 1990s, several software development
methodologies began to receive public attention.
Each had a different combination of old ideas,
new ideas, and transmuted old ideas. However,
they all emphasized close collaboration between
Contents the programming team and business experts;
face‐to‐face communication (which has been
Abstract 2 proven to be far more efficient than written
Introduction 2 documentation); frequent delivery of new,
Agile Adoption Rate Survey 3 deployable business value; tight, self‐organizing
Conclusion 6 teams; and, sometimes, unique ways to craft the
code and the team such that the inevitable
requirements churn was not a crisis.
In the context of software and systems
development, the term "agile" (with a small "a")
means that development teams are nimble,
flexible, responsive to business needs, and able to
adopt new technologies and techniques that can
improve software delivery. We’ve seen
development organizations trying to become
more agile for a number of reasons, including:
• Competition: "If we can't deliver new
features or products quickly, we'll lose
business to our competitors."
• Credibility: "Our customers and business
users hate us; they have no confidence
that we will deliver what they want or
need— at least in this lifetime."
• use of another. Many, such as Scrum and XP, are
Fear: "If we don't improve our quality and speed
up our project delivery, the company will quite complementary.
outsource development to someone else." Why is this distinction important? We have two
There are many ways that a software development main reasons for stressing the difference
team can become more agile. Delivering software in between "Agile" and "agile" processes:
smaller, more frequent releases; instituting frequent 1. Companies adopting Agile processes must
feedback cycles from customers; and using component‐
be prepared to really change the way they
and service‐based architectures are just a few
build software, and this change is hard.
examples. All of these can improve a team's ability to
But companies that do achieve this change
meet users' needs and deliver value to the business.
will realize some significant benefits in the
And, developers can adopt these techniques
productivity, quality, and value of the
incrementally, without having to disrupt or overhaul
software that they deliver.
their current development process or environments.
The widely used Rational Unified Process (RUP) is agile. 2. Companies that aren’t ready or able to
RAD approaches are agile. Even running repeated undertake this level of change can still
series of short waterfall projects, rather than delivering become more responsive and flexible in
one large release, can make you a bit more agile. the ways that they build software. Then
they'll become more agile and will begin
In contrast, the term "Agile" (with a capital "A") refers to reap the benefits that Agile practices
to a very specific set of processes that have evolved can deliver. This incremental approach can
over the past 15 years, including eXtreme Programming ultimately lead to a truly Agile shop, but at
(XP), Scrum, Feature‐driven Development (FDD), some point the organization will have to
Crystal, DSDM, and Lean Software Development. The step back and acknowledge that it's not a
Agile Alliance (http://www.agilealliance.com/), a direct path.
nonprofit organization created by the thought leaders
behind most of the Agile processes, promotes a core Agile Adoption Rate Survey: February 2008
set of values that all Agile processes must follow: The survey was performed in early February 2008,
• Individuals and interactions over processes and and there were 642 respondents. Some findings
• Working software over comprehensive 1. 69% of respondents indicated that their
documentation organizations are doing one or more agile
• Customer collaboration over contract negotiation projects. Of those that hadn't yet started,
• Responding to change over following a plan 15% believed their organizations would do
Every Agile process supports these values, albeit in so within the next year.
different ways. Some, like Scrum, address team 2. 61% of developers think that their
management. Others, including XP or DSDM, address organizations are doing agile
core development activities or other activities of the development, whereas 78% of
development life cycle. Note that users of Agile management thinks so.
processes do not have to follow all of a process's Agile
practices, nor does use of one process preclude the 3. 82% of organizations doing agile were
beyond the pilot project phase.
4. Respondents overwhelmingly indicated that
agile teams are producing higher quality, have
greater productivity, and enjoy greater
stakeholder satisfaction. See Figure 1.
5. Agile success rates: 82% for co‐located teams,
72% for near located (people in different
cubes, on different floors, working from
home), 60% for significantly distributed
(planes would be involved to get people
together). See Figure 2.
6. 84% of agile teams have iteration lengths of 4
weeks or less, and 2‐week iterations are the
7. Although, on average, the costs are lower on
agile teams, 23% of respondents believe
they’re experiencing higher average costs.
40% said costs were unchanged, and 37% had
8. Co‐located agile projects are more successful
on average than non‐co‐located, which in turn
are more successful than projects involving
Figure 1. Effectiveness of agile software development compared with traditional approaches.
Figure 2. Agile success rates by level of team member distribution.
CONCLUSION Sources Cited
There are still some limitations of the agile process— Liz Barnett. "Agile Versus agile Development"
Agile projects in most organizations are influenced by http://www.agilejournal.com/index2.php?option
non‐Agile elements. When external factors come into =com_content&do_pdf=1&id=18
play, it skews the agility of the process to a certain
extent. If an Agile project has a dependency on a Agile Alliance. http://www.agilealliance.com/
project that’s non‐Agile, then its priorities get
rearranged to accommodate the non‐Agile element. Scott W. Ambler "Why Agile Software
Project dates are preset into a definite number of Development Techniques Work: Improved
sprints to do a predetermined scope of work. Though Feedback"
these limitations are worked around, it definitely does http://www.ambysoft.com/essays/whyAgileWork
impact the Agility of the process. Being Agile and sFeedback.html
working on overcoming these limitations is what this
process is all about. Agile is not a solution to all the IT
development process shortcomings, but it definitely
bridges the gap between IT and business value more
than any other process.
Overall, Agile is a big step toward more efficient
development, but it’s still a long way from being
Plante & Moran would like to thank Chris Beale, Table
Sponsor from Pillar Technologies, Gary Baker, CIO at
Gale Cengage, and all roundtable participants for their
For more information, please contact: