Working within the constraints of the high-level delivery framework, the team can execute project work according to agile principles, focusing on the delivery of complete, tested, small features that carry inherently lower and more diversified risk than traditional waterfall or “iterative waterfall” development approaches. Attempting to plan, document, design, build, test, and deliver an entire product—or sprints of work, as in iterative waterfall development—can take years to complete and may deliver poorly aligned or unused functionality. The “agile within a framework” approach, however, allows for a more rapid delivery of meaningful program functionality and tighter, story-by-story and iteration-by-iteration control of delivery risk without the fear that the effort will devolve into an open-ended engagement that lacks clear objectives and measurements for success.
Maintaining Program Control, Visibility, and Accountability
In the current “do more with less” environment, government managers often find themselves responsible for multiple, simultaneous delivery efforts in addition to internal responsibilities that leave them little time to play the closely engaged, day-to-day role expected on agile development efforts. Government managers often are unable to participate in daily stand-up meetings and Scrum sessions. They are sometimes not even on the same project site as the majority of their development teams.
Because of this dilemma, government managers may be justifiably concerned that fast-paced, documentation-light agile efforts offer them reduced—rather than enhanced—visibility into the progress, risks, and issues of the projects for which they will be held accountable. Additionally, non-technical government managers may feel that they risk being misled by contractors who are able to constantly redefine the targets for success, making accountability even more difficult.
In this context, project teams that have incorporated more structured management and reporting tools—including clearly documented performance measures—into the project management approach can significantly improve visibility and control at the cost of only slightly increased management overhead (a matter of a few additional hours spent on performance analysis and status reporting over the life of a medium-sized effort). Project work can continue according to agile best practices, with status, risks, and issues being tracked via daily stand-up meetings and captured via the mechanism that best suits the needs of the team. These mechanisms can encompass everything from team whiteboards to electronic status-tracking dashboards.
To supplement their structured management and reporting tools, the project development lead, project manager contractor, or other designated management representative can capture key statistics on project burn rates, cost performance, risks and issues, and other pertinent performance measures mapped against the overall project delivery plan. From there, the designated management representative can summarize the statistics and provide the information to the government lead at regularly scheduled status checkpoints throughout the entire effort.
Through these checkpoints and the informal daily and weekly status checks (performed at whatever frequency the government lead prefers), the government lead can track project performance to his or her level of comfort. Where higher levels of control are required, this periodic reporting enables the government lead to perform a type of earned-value management against the project that, due to the granular, story-oriented nature of agile development efforts, actually enables a higher level of visibility, control, and accountability than would be possible on a traditional project.
Matching Agile to Traditional Program Control Processes
Through years of experience, many government agencies have developed extensive and well-documented engineering and development lifecycles that, for traditional (sequential, waterfall-style) projects, provide a series of “completeness checklists” against which project progress can be monitored and controlled from inception through delivery and eventual retirement. Beyond the familiarity aspect, these engineering lifecycles are closely tied to existing government acquisitions and finance mechanisms (e.g., Federal Acquisition Regulation (FAR) or the Department of Defense’s “DOD5000” Defense Acquisition System). As such, project compliance with lifecycle milestone reviews and milestone-associated documentation is more often than not a mandatory condition for successful delivery.