The synergy between Agile and program management
Projects are traditionally used to manage change in an ordered way; in the last decade though, they have become more and more ‘unordered’ as project management is increasingly used to manage complex situations in a turbulent environment. These circumstances have shown the need for more responsive forms for managing change and have given rise to disciplines like Agile management and program management, which deal with complex issues that traditional project management is ill-prepared to tackle.
Program management has evolved from the complexity created by a number of interrelated projects and the multiple stakeholders involved in them; from the need to span from strategy to operations; and, from the ambiguity involved in constantly emergent decision-making. For similar reasons, Agile methods have been introduced by a group of thinkers of what was then called ‘lightweight methods’ to tackle complex, fast-moving IT programming projects.
In 2001, these thinkers issued the Agile Manifesto, which states four basic concepts for Agile management:
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
Most practitioners of program management will agree that the principles stated in the Agile Manifesto could very well apply to program management.
Agile management and program management are based on the concept of an integrated, mutually reinforcing set of decisions that form a coherent whole aimed at creating stakeholder value. They share a number of common concepts:
- Responsiveness as a measure of value, which consists of seeing change as opportunities rather than threats;
- An evolutionary and adaptive development, which translates into gradual and measured release of benefits;
- The team as an integrated evolving system where all key stakeholders are actively involved; and finally
- An approach based on simplicity to improve response to changing demands and turbulent environments.
In both programs and Agile development, responsiveness is the measure of value whereas in project and traditional management, efficiency and reliability are the keys to success. Many people in project management still believe that Agile methods are counter effective if used in project management: “Agile and Scrum were developed to allow IT projects to indulge in all the scope creep they wanted,” writes Michael Hatfield in Taking on Project Management Myths.
Complexity and the need to be responsive require the use of Agile or similar methods; Agile projects and program management share the same values and concepts and can learn from each other.
Management mythbusters
First I would like to dispel a myth about both program management and Agile management.
Programs are not big projects. Many very competent project practitioners believe that, if the scope and the deadline of a program is not defined from the start, it is not a program, but some kind of unruly, complex, political process best dealt with by change managers. While this may be true when dealing with large infrastructure and development programs, which are often subjected to a lot of political influence over time, nothing is furthest from the truth when program management is used in complex situations like new product development or organisational change.
The essence of the program is to deliver benefits, but benefits are defined at strategic level and they can only be delivered when the results of the project are implemented into the business through operations, therefore the program extends into both strategy and operations.
According to the two most widespread manuals on the subject—the UK’s Office of Government Commerce (2007) and the Project Management Institute (2008a), programs deliver benefits of strategic importance and/or are part of a strategic plan. Most recent writings on strategy have demonstrated that, in today’s turbulent environment, strategies are constantly in evolution and, by consequence, so are the programs that deliver them. This is not compatible with traditional project management and requires alternative management methods closer to strategy management.
Agile methods do not condone scope creep; they condone tailored delivery of user’s true requirements, even if it involves changing the product along the way. Agile methods were developed to deal with projects that could not be dealt with using traditional project management methodology.
Projects that are complex, involving many unknowns in terms of design and the effect that results have on expected benefits cannot be managed using traditional project management methods. Traditional project management requires a clear scope and defined parameters at the onset. Traditional project management is meant to deal with uncertainty, when the ‘how’ is not defined; Agile methods are meant to deal with both uncertainty and ambiguity, when the ‘what’ is not defined.
Agile management is a development method, not a project method. In fact, Agile management is very similar to fast-track project management, a method where design occurs in parallel with construction. Having worked on a number of large construction fast-track projects in the late 1980s and early 1990s, I can remember having to develop new project management methods very similar to Agile and rely on the same basic concepts.
Craig Larman in Agile and Iterative Development: A Manager’s Guide (2004) describes Agile methods as: “short timeboxed iterations with adaptive evolutionary refinement of plans and goals … iterative development lies at the heart of agile methods.” The goal, at the end of an iteration, is to deliver a fully functional component of an integrated system; the sum of all the iterations adding up to a complete integrated system.
As can be seen through these clarifications, both program and Agile management develop a final outcome in a cyclic, iterative way and are constantly realigned, based on measured transitional results, to ensure they deliver stakeholder value. Both put a great focus on prioritisation of effort and understanding of requirements, which is definitely a value management approach.
Figure 1: Projects, Programs and Agile in Relation to Uncertainty and Ambiguity (© Thiry, 2010)
As displayed in Figure 1, both programs and Agile projects comprise decision-making aspect, based on the perception of stakeholders’ value. The clarification and decisions concerning these ‘expected’ benefits needs to be addressed along with or before traditional project methods can be applied. In projects, it is the pre-initiation and initiation stage that deal with this. Both program and Agile are, in fact, composed of a series of decision-implementation cycles that are mutually self-reinforcing, whereas in projects most decisions concerning scope and expected deliverables are taken before the project starts.
So comparing programs to projects and Agile methods to traditional project management is a mistake, which is what I will cover in this series.
Program and Agile Management: Two birds of a feather? series:
