Traditionally, Agile has been used for software development. However, an awareness is emerging that Agile can be a management tool with value beyond software projects alone.
Numerous books, blogs, and papers offer perspectives on the Agile Development Model as an improvement on the Waterfall Development Model and compare their respective software development lifecycle (SDLC) methods.
- The Waterfall Model is characterized by pre-development planning in a non-iterative approach. Before even one line of code is written, there may be lengthy, laborious requirement definition initiatives envisioning all precursors to delivering functionality to end users. Therein lies the downside of Waterfall. By the time functionality is operational, user requirements have changed, and SDLC teams head back to the drawing board. Like a physical phonebook, the published requirements documents are obsolete before they’re printed.
- In comparison, the Agile Model presumes that unanticipated changes will occur throughout the development lifecycle. With Agile, frontloading budgets and development resources for pre-development planning is replaced by resource allocation for an iterative series of short, focused efforts known as sprints. An Agile approach is designed to mitigate the shortcomings of a Waterfall approach, particularly when user requirements are not fully articulated or entirely understood before coding starts. This allows programs to quickly respond to new vulnerabilities, opportunities, technologies, and priorities without having to trace the impact through all the system’s dependencies.
As we all know, requirements uncertainty is not unique to the realm of software development projects. Complex, multiphase, strategic initiatives typically result in smaller projects that frequently display similar non-linear pathways, and only when one delves into the individual projects do the underlying complexities come to light. The Agile Model should be applied to realize benefits in the following ways:
- Business-driven requirements in iterative evolution
- Cross-functional collaboration
- Stakeholder ownership
- Complex capability modularization
- Measurable operational valuations
With any complex initiative, a critical first step is capturing the project vision or concept of operations. Expressing such a vision or concept is an effective alternative to managing with ambiguous or partially formed requirements, and doing so provides context and a framework for incremental and iterative delivery – the basis of Agile project management. From there, frequent delivery milestones allow project teams to refocus with relative speed to meet evolving customer needs. Regular stakeholder engagement from sprint to sprint throughout the project improves buy-in and increases the overall likelihood of successful project outcomes.
By way of example, let’s look at how one could apply Agile to developing an enterprise architecture (EA). EA is typically part of a complex strategic initiative and characterized by multiple incremental and iterative phases.
One Agile sprint could comprise a draft set of EA artifacts. At the beginning of each sprint, the scope of the EA artifacts to be constructed would be reviewed and refined. Next, resources required to complete the scope of the EA artifacts could be estimated. Knowing some specifics, such as the number of EA artifacts required, necessary expertise to create the EA artifacts, and understanding their complexity, enables us to estimate the overall level of effort and specific resource skill sets needed to generate the artifacts. This type of detailed planning, referred to by the Project Management Body of Knowledge (PMBOK) as rolling wave planning, is repeated with each sprint.
Subsequent sprints might entail refinements or updates to existing artifacts or the development of additional EA artifacts, though it is important to keep in mind that establishing (or refining) performance objectives at the start of each Agile sprint is paramount. This link between Agile sprints and performance measures increases accountability of both the product owner and service provider, precluding open-ended or unfocused iterations. In our EA, we create only those architectural artifacts required to address imminent strategic objectives of the sprint and to enable business executives to answer specific strategic questions. For instance:
- Leveraging EA to determine how new laws and federal regulations will impact enterprise processes and systems.
- Analyzing how a new system will affect the surrounding IT environment
- Creating an EA artifact to identify customer or supplier touchpoints.
Ultimately, the return on investment becomes evident with each rolling wave, directly correlating project milestones, operational gains, and new business value.
We would love to hear from you. The suitability of Agile for broad use is evidenced by the recent Project Management Institute announcement that the PMBOK sixth edition will be more Agile focused. Please share with us how your organization applies the power of Agile innovatively.
Do Good. Have Fun. Add Value.