– This article was published on Training Journal (September 2015)
Few people who work in the world of project management can have missed the on-going debate about the use of Agile and its suitability for projects of different types.
Agile is a not so new approach to software development, which brings together the developer and user community in order to create integrated teams who can develop and approve software swiftly and thus bring new products to market quicker. In the world of Agile, time is the fixed corner of the project Management triangle and the product is developed within agreed timescales. If there is a compromise to be made (as inevitably there will be) then this would be in terms of functionality (scope) in order to achieve the agreed deadline.
A product is always delivered, it just may not be as capable as the one originally asked for, but it will be delivered nevertheless. Having delivered the new product the project team can then make incremental improvements to the new product over time should the business case to do so still make sense. In the Agile world delivery is quicker and it is preferable to deliver something early.
This is generally compared in the debate to what is known as the waterfall approach taken by traditional methods such as PRINCE2. The waterfall approach broadly follows the plan, do, review cycle of work. We initiate a project, do some detailed analysis to understand the requirement, do some design work to create a specification for the solution, build the software, fully test it and then at the end of the project when everything is complete we deliver.
The Agile debate generates uses a lot of oxygen and ink discussing the pros and cons of each method and whether then can co-exist. The argument goes something like this. Agile projects deliver capability quickly, so that the customer can make use of some of the functionality sooner rather than later whereas the waterfall approach delivers capability much later by which time the requirements have probably already changed. More importantly, the argument continues, because Agile software is iterative and developed in collaboration, we don’t need plans and or a specification of requirements as we develop this as we go.
Can PRINCE2 and Agile Co-exist?
The first myth to shatter is that PRINCE2 takes a waterfall approach to project management – it does no such thing. PRINCE2 provides a structured framework within, which projects can be managed in a controlled way. There are no technical stages within PRINCE2 and provided you justify your project with a solid business case and follow a few basic principles you can structure the project work in any way you want delivering as early or as late as you like. You can provide incremental implementations or a big bang delivery at the end. PRINCE2 provides that flexibility.
Agile and its variants use time boxes to control the flow of work – in PRINCE2 these time boxes are known as work packages and each work package will deliver one or more finished products. There is no difference as the project manager will set parameters for each work package and its completion – time will generally be fixed. There is even a tolerance on scope, which allows your development team to make those decisions around what will and what won’t be delivered.
You still need a plan and a precise statement of requirements. How else could the business make any decision to commit the associated resource and funding. Furthermore, on the subject of requirements, if you are planning to allow the development team to make proactive decisions about what will and wont be included in the final version, you absolutely must have a statement of what features are expected and, in addition, a clear steer on where any compromises would be acceptable. Agile does not mean relinquishing control and still requires rigour. In fact, it is possible to give more freedom if the boundaries are clearly specified and the controls are in place to provide re-assurance.
Rapid software development has been known by different names for the last thirty years and methods such as PRINCE2 were designed with this in mind. They have been built to work together and the connections are obvious. One client recently told me that they had adopted Agile and had been instructed to “throw away your PRINCE2 and MSP books.” Nothing could be more ridiculous.
What do you need to know as a leader?
I suppose as a programme leader, there are several questions you would need to have answers to in order to determine whether Agile is the right approach for you:
- Is the environment and the requirement changing so quickly that early delivery is a key driver and if so will your deliverable allow compromise and/or part delivery?
- Do you understand the requirement in sufficient detail to be able to recognise those compromises which are acceptable and those which are not?
- Is the stakeholder community willing and able to collaborate closely on the development and are they empowered to make decisions on a feature by feature basis.
- Is there a tangible benefit to delivering capability early.
- Finally, is there any other specific advantage to adopting a new approach to an already challenging project?
The debate will continue to smoulder I am sure but this is driven more by a lack of understanding rather than a real question to be answered. Agile has its uses and in appropriate circumstances can help to make a real difference in capability to any organisation.