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,
Advertisement
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 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 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
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.
Error, missing joomlaboard config file!
Comments (4)
Dave Hitchman: ...
Fixed fee == fixed scope ??? Why?? I have been doing fixed fee work using Agile. The customer pays 'per sprint'. The customer then dictates the backlog for each sprint, the project team agrees what of that backlog is possible, discussion ensues, an agreement is reached. This actually works FAR better than the old fashioned fix the scope, and estimate the time (unpaid) take the risk (how much risk are you happy with?), do the work, either deliver something the customer doesn't want or enter into protracted rescoping negotiation and repricing.
I think Agile is an IMPROVEMENT for fixed fee projects.
1
April 24, 2008
chakra_r: ...
I have couple of questions to ask regarding the agile environment
How do we define scalable Architecture How do we estimate Effort like Use case point or Function Point How do we allocate task to developers
2
December 29, 2006
Nguyen: ...
For fixed fee project then the scope lock down is necessary, knowing that some requirements are not truly match the business requirements or even useful at all. The project in your case study seems not to be such kind of fixed fee project and I wonder how you can address the problem if it were one.
3
December 18, 2006
spicetrader: ...
Indeed, Agile methods limit scope to what the team can accomplish during the next sprint. The enterprise never commits more than that.
Articles 
