Agile Journal

CASE STUDY: Four Myths of Agile Development

Contributed by Mike Burba
Thursday, 07 December 2006

State of Ohio Automated Child Welfare Information System (SACWIS)

Agile development continues to gain traction in enterprise IT organizations, but myths and misconceptions slow the pace
of acceptance and preclude the use of Agile methods in situations where they could otherwise add significant value. Part
of the issue is the simplicity of its philosophy as stated in the Agile Manifesto, which leaves plenty of room for
(mis)interpretation and leads to myths such as Agile is anti-documentation. Other myths arise from misunderstandings of
common Agile practices. Executives, managers and practitioners familiar with traditional waterfall and RAD approaches
are shocked to discover that cherished metrics and practices don't apply on Agile projects, leading to mistaken
assumptions about the lack or inadequacy of project management, requirement management, quality assurance and
other key project controls. Agile purists complete the picture through dogmatic pronouncements of what is and isn't truly
Agile. This article uses experiences from a highly successful large development project to debunk four common myths:
Agile projects don't control scope, Agile projects are difficult to manage, Agile approaches don't scale, and Agile methods
are just for programmers.

Project Background

Agile in practice differs from Agile in theory. Large enterprise projects are naturally messy and fraught with complexities
ranging from legacy integration to organizational politics. Fundamental Agile principles and methods need compromises
and extensions to handle these "real world" conditions effectively. However, real world experience proves that Agile
meets its objective of delivering better software.

The examples in this article are drawn from the Agile project that developed the State Automated Child Welfare
Information System (SACWIS) for the State of Ohio. Compuware Professional Services delivered this project using its
Iterations in MotionTM (IiMTM) Agile methodology and OptimalJ tool for modeling and automatic code generation.
SACWIS projects are complex, very large in scale, {sidebar id=1} and fraught with challenges ranging from constantly
changing business requirements to legacy data and existing system integration issues. Over the years, many states have
fallen victim to schedule and budget overruns when implementing these federally mandated projects. Using Agile
methods, Compuware was able to deliver the Ohio SACWIS project on schedule, with an unprecedented low level of
defects, and for a fraction of the cost of other state's projects.

Myth #1: Agile approaches don't control scope

Scope control is a major issue for IT development projects. History has shown that runaway scope is a primary
contributor to project cost and schedule overruns as well as outright failures. Given today's delivery track record, IT
executives are understandably wary of any development method that doesn't lock down scope at project start, allows the
requirements to change and evolve over the life of the project, and encourages further change through constant user
collaboration and feedback in each development iteration. To someone coming from a traditional project management
background, these Agile practices appear to guarantee scope overruns.

In Compuware's experience, we've found the reverse is true. Rather than being a liability, Agile's approach to handling
scope and requirements is one of its strengths. To define and handle scope, the SACWIS project used a series of 10-day
JAD iterations to capture high-level design requirements, followed by 10-day development iterations for detailed design,
modeling, and coding. Business users were active participants throughout the entire project, helping to define and
prioritize the business and technical objectives and review and refine results upon completion. This approach surfaced
http://www.agilejournal.com Powered by Joomla! Generated: 23 January, 2009, 01:18
 Agile Journal

misconceptions, clumsy workflows, missed requirements, and other issues quickly, and prevented the rote
implementation of unnecessary or unworkable features. The inevitable changes requests that arose were evaluated
against project goals, prioritized, and scheduled within the development iterations.

Bottom line: Refinements during design and development iterations result in functions and features that more closely
match true business requirements while eliminating "feature creep" and other unnecessary efforts. Although the SACWIS
project encountered several significant changes in scope, work remained focused by project goals and the project
completed on schedule and to actual business requirements.

Myth #2: Agile projects are difficult to manage

Agile's lack of traditional project plans and emphasis on self-managing teams strike some observers as development
anarchy and, on larger projects, a recipe for chaos. Executives expect a well-managed project to have a clear roadmap
of objectives and a strategy for achieving them, full visibility into project progress and performance, and tools for
coordinating the activities of multiple parallel teams. Traditional projects meet these requirements with formal plans
containing assigned resources, deliverables, and fixed milestones. In addition to defining the path for delivery, these
plans give managers a checklist for evaluating project progress and coordinating supporting resources. Unfortunately,
these tools simplify project management at the expense of additional overhead and loss of flexibility for responding to
change during the project.

In contrast, Agile handles each of these management requirements, but in a different way. Agile project do not plan
upfront; instead, planning occurs throughout development with different frequencies at the individual, iteration and
release levels. This continuous planning enables Agile teams to respond to changes rapidly and avoids the continual
reconciliation of plans to project realities that occurs on traditional projects. New tools such as burn down metrics and
velocity charts replace linear project tracking methods such as Gantt and PERT to provide executives with the necessary
visibility into project operations. Large complex efforts such as the Ohio SACWIS project use multiple development, QA,
and data conversion teams. While each Agile team follows Agile practices internally, Compuware recommends that each
iteration is formally managed as a project within an overall engagement portfolio and tracked using a project dashboard.
This approach ensures alignment between teams and provides management visibility into progress without
compromising the agility of individual teams.

Bottom line: Agile projects are no more difficult to manage than their traditional counterparts, however, different tools and
metrics are required. Using a project portfolio management approach to tracking an coordinate individual Agile efforts,
enables Agile to scale without compromising Agile practices at the team level.

Myth #3: Agile approaches don't scale

One of the most pervasive misperceptions about Agile methods is that they cannot scale to meet the needs of Enterprise
IT organizations. Typical concerns include Agile's robustness, manageability, ability to handle large projects, and
compatibility with legacy systems and data. Unlike the small "green field" projects delivered by Agile's high tech early
adopters, enterprise projects are usually much larger in scope, encounter many technical, logistical and political
constraints, and have the technical challenge of integrating existing business features, functions, and data. Compuware's
experience on the SACWIS project debunks this myth and proves that Agile methods can address these concerns
effectively.

The Agile community continues to extend and improve Agile's enterprise capabilities, and Compuware developed its
IiMTM methodology specifically to handle large, complex enterprise projects. IiMTMaddresses the management of
multiple Agile teams working on a large assignment and addresses enterprise issues such as rapid requirements
gathering, quality assurance, test data generation, and legacy data conversion using Agile techniques.

Bottom line: Using Agile methods, Compuware was able to deliver the Ohio SACWIS project -- a very large initiative
http://www.agilejournal.com Powered by Joomla! Generated: 23 January, 2009, 01:18
 Agile Journal

fraught with enterprise challenges - within an aggressive development schedule while absorbing multiple significant
scope changes without impacting the delivery timeline.

Myth #4: Agile methods are just for programmers

Given their heavy focus on software development, Agile methods appear to be for programmers only, not the rest of the
development team. Agile methods seem to focus on efficiency and speed of the developers rather than related areas
such as quality assurance and operations. Principles such as "individuals and interactions over processes and tools" may
be fine for capturing requirements and coding, but seem less suitable for testing, quality assurance, and data conversion
teams.

Figure 1: An "End-to-End" Agile Approach

Compuware's experience proves this myth wrong. Although originally created for developers, Agile principles apply to
many situations, and all project disciplines can be made Agile. Extending Agile concepts to areas such as testing, quality
assurance, and data conversion provides these disciplines with same flexibility and responsiveness benefits as
development. And, more importantly, this extension adapts otherwise linear functions to Agile development's iterative
style enabling those disciplines to better integrate and support a large Agile effort. Compuware used this approach on the
SACWIS project to create an "end-to-end" Agile environment that embedded quality assurance and data conversion
within the development processing using carefully aligned and managed 10-day iterations (see Figure 1). Since
requirements are adjusted at the start of each iteration, having the supporting teams operating with the same cycle and
approach is critical to maximize the business promise of Agile.

Bottom line: Including disciplines such as quality assurance, testing, and data conversions within a common framework
allows Agile methods to be used on larger and more complex enterprise projects. Compuware Professional Services was
able to use this approach to deliver a fully operational SACWIS system containing of over 4 million lines of code with an
unprecedented low level of defects. The overall defect rate for defects found during user acceptance testing and system
testing was 2.85 per 1,000 lines of code, significantly under the overall industry average of 15-50 defects per 1,000 lines
of code.

In conclusion, successful Agile development is a mixture of theory and pragmatic adaptations. No myth should be
accepted at face value. With a little creativity and open-mindedness, an Agile solution can be developed to handle most
perceived limitations.

About the Author

http://www.agilejournal.com Powered by Joomla! Generated: 23 January, 2009, 01:18

 Agile Journal

Mike Burba is a Director for Compuware's Application Delivery Management Solutions and a frequent speaker on
software development and architecture topics at industry conferences.

{mos_sb_discuss:10}

http://www.agilejournal.com Powered by Joomla! Generated: 23 January, 2009, 01:18