I presented a briefing to an internal agile development group at a major defense contractor this week. The topic was - as always - integrating Earned Value Management with Agile Software Development. The discussion started with connecting the WBS to the Agile domain. The reason for this is simple. All Federal government contracts come with a Statement of Work (SOW), a Program Work Statement (PWS), a Statement of Objectives (SOO), or similar statements of what DONE looks like.
From these documents, which are part of the contract, a Work Breakdown Structure is either provided or built. A Contractor WBS many times is derived from the Government's WBS. These WBS's define the decomposition of the product and the services that develop the product. There is NEVER a decomposition of the departments or work performed by those departments. Things like Design, Test, Integrate are not part of the WBS. The can be a field in the IMS (Integrated Master Schedule) showing which department is assigned to which WBS elements. This is then used in a pivot table to build the RAM (Responsibility Assignment Matrix).
So here's how to connect Agile to the WBS
In the current vernacular of Agile an Epic is the top level outcome of the Agile project. Per several definition an Epic is a collection of User Stories. These Epics can be put up on the wall and arranged into groups - the Epics. This has a very close connection to the Program Events or Milestone in our defense procurement model.
From the Epic, Stories are decomposed and Features are extracted. These Features are the tangible deliverables of the project. They are what the user bought for the budget of the project. Inside each Feature are Tasks that develop the Feature inside the Iteration.
So this is a nice starting point for connecting the dots between the Agile vocabulary and our more traditional IMP/IMS paradigm.
Here's some background on IMP/IMS:
All of this focuses on building a clear and concise of the Grammar of DONE. If you don't know what DONE looks like in tangible units of measure meaningful to the decision makers, than you'll never recognize it when it walks through the door. With this concise description, the only measure of progress to plan is the consumption of money and the passage of time. Agile does a good job of defining the outcomes of each itertaion, and managing the contents of those iterations during the Planning process. What is needed is an upper level process. This is provided by the Epic.
So starting with these connections, traditional project management structures are connected with agile structures.
What's next is to define the work rhythm. Of course Agile does this with Iterations that run a few weeks. Traditional IMP/IMS does this with Work Packages, running 4 to 6 weeks. These Work Packages are embedded in a Rolling Wave, with multiple Work Packages in each Rolling Wave.
So here's how to flow down the WBS to the Work Packages. In Agile the WBS element can be a User Story (a deliverable capability) or a Feature (also a deliverable capability). In all case these Work Packages are single output work efforts.
