Part Three: Implementing CMMI and Government Requirements in an Agile Development Shop

Over the past ten years, more software development shops have transitioned from traditional waterfall development methodologies to agile.  This transition has proven effective in many cases; however, some contractors struggle to make the shift on U.S. government development contracts because these contracts often either contain requirements written for waterfall methodologies or require CMMI Level 3 or higher achievement.  Part Three of this series discusses how to approach and overcome key challenges to implementing traditional development requirements within an agile development environment.

We will address the following key challenges:

• Shifting from contract requirements to contract value
• Moving from ‘agile’ to ‘Agile’ (Big “A”  Agile)
• Addressing CMMI requirements

Shifting from Contract Requirements to Contract Value

As government contracting evolves to improve requirements for agile development methodologies, current procurements often contain documentation requirements more closely linked to the traditional waterfall approach.  This typical documentation includes:

• System Specifications
• Concepts of Operation
• Subsystem Requirements Specifications
• Interface Requirement Specifications
• System Design Documents
• Interface Design Documents
• Software Development Plans
• Database Design Documents
• Version Description Documents
• Site Preparation and Installation Plans
• System Test Plans and Procedures

The items above are not an exhaustive list for larger development programs, but they allow the government to show progress on the development by pointing to documentation milestones along the traditional waterfall lifecycle.  This situation becomes even more apparent when the project requires earned value management.  Documentation isn't a bad thing; in fact, it's necessary for any development project.  However, this points to the fundamental difference between how waterfall and agile projects are managed.  Simply put, it's all about the management of software or system requirements. 

The traditional waterfall approach tends to emphasize software or system requirements definition (including design).  It sides with the theory that if the requirements are correct and detailed, the resultant product will meet specifications and perform as intended.  This theory happens to be absolutely true and nearly impossible to implement.  Here's why: 1) it is difficult to articulate and create detailed requirements, 2) people change their minds on the requirements once they begin to see the product, and 3) technologies and the environment often change before the product can be designed, developed, and released.  In project management terms, waterfall projects create a fixed scope relating to requirements with a variable cost and schedule to development them.

Agile attempts to address this issue by turning the requirements problem upside down.  With agile, the schedule and cost are fixed and the scope is the variable.  Scope and the subsequent requirements are driven both by customer value and what can be delivered during a development sprint.  The ability to deliver that scope is based on the complexity and capacity of the team.  Getting the development team and the customer to fundamentally flip the requirement, schedule, and cost triangle in this way is critical to making the shift to agile.

Moving from ‘agile’ to “Agile’

There are large numbers of contractors claiming to use agile as their development methodology.  However, most tend to be implementing agile with a the little ‘a’ instead of Agile with a capital 'A'.  The former can range from just doing shorter iterative development cycles to planning sprints, using agile estimation methods and assessing customer value of backlog items.  Both of these cases emphasize small iterative development cycles or sprints.

Focusing all planning and development on the sprint ignores the larger context needed to effectively plan the work.  In most cases, there are three levels of planning in a big ‘A’ Agile development project.  It begins at the portfolio level.  This is where the iterative backlog grooming helps move customer requirements from Epics into usable-sized chunks that can be planned and developed.  This is also where the product roadmap is developed to provide a longer-term development vision for the project.   An effective roadmap should lay out the expected number of releases and notional schedule expected to meet the customer’s definition of done.  Of course, requirements can change and the methodology allows the product roadmap to evolve, but the chances of project success significantly increase when there is at least some end-game in sight. 

The product roadmap also provides a mechanism to communicate progress to the customer.  In this construct, the release level becomes the planning unit for agreements with the customer.  At this level, the developing backlog should be reviewed and approved.  Release planning will include many of the sprint details and may even seem a bit redundant, but it increases customer interaction to a more meaningful level.  Having customer agreements at the sprint planning level are often burdensome for the customer and not helpful for the development team.  By engaging the customer at the release level instead, the development team can manage expectations about what the customer will see in the sprint demos and update the customer long before the release of new, usable, and integrated functionality.  This is easily communicated with the use of sprint and release burndown charts.

Moving from ‘agile’ to ‘Agile’ for most organizations is about creating discipline in the process beyond the sprint level and understanding the longer-term vision of the product(s).  It also involves creating workable and meaningful planning units at the right level to successfully engage the customer and manage development expectations.

Addressing CMMI requirements

Most businesses assume CMMI is steeped in the traditional waterfall method, primarily due to the model's language used, not the meaning or intent of the process areas.  For example, the Project Planning (PP) process area specific practice 1.1 states, “Establish a top-level work breakdown structure (WBS) to estimate the scope of the project.”  Reading this might makes most agile evangelists cringe from head to toe, but the trick is to look closer at what the practices and the process area are trying to achieve. 

The intent is to ensure that work is decomposed into workable units that can be planned and developed.  Agile certainly does this as part of its backlog grooming. During portfolio planning, release planning, and sprint planning, this grooming process provides greater fidelity.  For example, epics are broken into features, features into Product Backlog Items (PBI's), and PBI's into tasks.  Sizing is estimated with greater fidelity throughout the backlog grooming using T-Shirt, Fibonacci, or story point estimation methods.  Acceptance Criteria is addressed for each item, in order to define 'done'.  When the backlog items are planned as work at the release and sprint level, they are broken into specific functionality to be delivered during a sprint or set of sprints over the duration of a release. If this isn’t work breakdown, I don’t know what is.

There's no question that the CMMI Institute needs to update its vernacular (and is expected to do so in Version 2.0), but the current intent is spot on and lines up with modern and disciplined Agile development.  The CMMI Institute recently released a document called “A Guide to Scrum and CMMI: Improving Agile Performance with CMMI.”  It's available on the CMMI Institute website and if you have CMMI requirements and are implementing or planning to implement Agile, it's a must read.

Agile development (and DevOps) are the wave of the future (at least for now), and the U.S. government and most businesses are quickly moving towards this way of doing business.  As requirements and procurement regulations evolve, the clash between traditional development methods and agile will likely grow smaller.  The use of CMMI should not be considered an obstacle to organizations looking to make the move over to agile.  In many ways, it helps mature the small ‘a’ agile development shop into a mature capital ‘A’ Agile organization.  Adding the appropriate portfolio and release planning levels to existing sprint-oriented agile implementations improves project success and customer confidence in the approach.

INFORMATIONAL SERIES

Over the next few weeks, this informational series will explore details of various implementation scenarios and the unique challenges of implementation in the U.S. contractor environment.  Stay tuned for the next installments in this series:

• Part One: Common Challenges for Implementing in a U.S. Government Contractor Environment. 
• Part Two: Implementing ISO and CMMI for Staffing Services Contractors
• Part Three: Implementing CMMI and Government Requirements in an Agile Development Shop
• Part Four: Leveraging ISO 27000 to Address FISMA and NIST 800-53 Cyber Security Requirements
• Part Five: Implementing ISO 20000 as a Practical Path to Address Government ITIL Implementation Requirements.

ABOUT I3 DESIGN AND CONSULTING LLC

i3 Design and Consulting LLC is a boutique Information Technology, process consulting, and products firm headquartered in Leesburg, Virginia.  Our company is defined by its deep content knowledge of its staff and partners.  We bring twenty years of information technology and business process improvement knowledge to the table, with a record of success producing business value, increasing operational efficiency through IT innovation and process improvement, and driving customer focused service excellence.  i3 provides consulting support to senior executives, as well as, leadership to transition organizations to the next level by transforming business processes and improving growth, margin, customer engagement, IT, and quality.