At a recent Financial Service Industry conference a number of the speakers commented that their companies had “gone agile”, or implemented agile as their Project Management Methodology. Since this conference a number of other clients and organisations in the industry have said similar things.
Having spent the last decade and a half delivering projects using a broad range of traditional project methodologies like: PMP, PMBOK and Prince2, I am curious as to how agile has taken over as the primary project methodology, or has it? It is also interesting to ponder how strictly agile is being adhered to in the larger financial services organisations that are historically governance heavy and have traditional project methods ingrained in their project methodology DNA.
It is important to be clear about what agile really means. Agile methodology uses incremental and iterative cycles to evolve requirements to deliver the project outcome through collaboration and using a dedicated team. Agile methodologies were evolved through the 1970’s to the 1990’s until they the Agile Manifesto (2001) was established by a group of like-minded software developers who got together in the U.S. to discover a better way to develop software.
- Individuals and interactions over Processes and tools
- Working software over Comprehensive documentation
- Customer collaboration over Contract negotiation
- Responding to change over Following a plan
It is from this point that agile has become more acceptable and more broadly adopted within organisations. Some more commonly used agile methods include Scrum, Extreme Programming, and the Rational Unified Process. In my experience the majority of people in Australia refer to scrum when they think of agile.
Is it really agile or is it a traditional approach dressed up to look agile?
It is sometimes difficult to apply agile in its purist form within the constraints of the majority of organisations as they require: business cases, financial forecasting for capital expenditure 6-12 months out from the commencement of a project, have set implementation/ release windows, and a degree of certainty of process and outcomes for stakeholders such as legal and compliance.
The reality is that some, well suited, projects will be delivered using a pure agile approach but most will follow a more hybrid Water – Scrum – Fall approach. This ensures that the benefits of an agile approach can be leveraged within a more traditional waterfall context and organisational governance and control requirements can still be adhered to.
It is encouraging and exciting that many organisations are talking about implementing projects using agile approaches and I think that it will provide these organisations with additional flexibility to meet the rapidly changing demands of their market. It is likely that traditional project management methods will continue to be used within organisations and that agile and traditional will become symbiotic over time. Organisations need to be flexible and open minded about how they execute their projects and a establishing a framework for selecting the appropriate projects method to be applied for each project is a vitally important to ensure project success.
There is still a degree of wariness about the agile approach with some executives believing agile is just code for allowing project teams to do what they want without controls around quality, time and money and that agile just applies to IT application development projects.
Doesn’t agile just mean people can do what they want?
Often when an executive is asked to support agile you here that they are concerned about the lack of control using this approach. Interestingly, agile methods have created some rigorous processes and products to ensure control through the project lifecycle. You may be familiar with terms such as sprints, daily stand ups, burn down charts, scrums, sprint reviews, these are all terms used in agile to ensure control within the project. Agile projects are also time boxed and focus on generating the minimum viable offering for the user ensuring that the priority features or requirements are delivered within the specified time.
Isn’t agile just about IT application development
Agile isn’t only applicable to IT related projects, the approach can be used to solve any business challenge that is to be addressed through a project as long as it meets the agile selection criteria. The concepts and methods can be readily applied to business projects such as a change management project.
How to pick an agile project
It is really important to understand that not every project is suitable to be delivered using an agile approach. Typically the best projects have the following attributes:
- can be delivered in increments
- are assigned relevant dedicated resources
- are time constrained; and
- have a strong sponsorship.
Projects in the digital domain, like web sites or mobility applications, are ideally suited to an agile approach. Conversely, something like an infrastructure project isn’t a likely candidate to use an agile approach. This is not to say that valuable agile principles such as iteration and collaboration can not be applied to every project. If you are implementing your first agile project it is paramount that you choose the right project as its important to have a successful project first up so to build confidence in agile throughout your organisation.
John Desmond, Director