To be able to understand the Agile Project Management approach correctly, you should first familiarise yourself with the issues the best project managers can face.
So, in the past, project management has been ruled by a waterfall approach. What this means is that one task cascades on from the next job until you get to the end goal of the project.
In essence, there is a sequential progression through tasks that complete everything in a single shot.
There is said to be a lot of failure in this approach, as the end must be well defined at the beginning and becomes difficult to change once on the path to project completion.
The project passes through a series of separate departments until it is delivered to market and these departments may or may not communicate well.
The result of this is a project that does not fully meet a requirement, or it runs over deadline and budget, and the return on investment is reduced.
This waterfall approach is excellent if the requirements of a project are set in stone. If a project manager has a solid business case and this vision is unlikely to change, then the sequential approach is perfectly workable.
It is still the primary methodology of project management in the world today. However, in a fast-moving global world little is set in stone and the inflexibility of such a sequential model is troubling for most companies.
Enter a new philosophy that allows the project to be responsive and flexible – agile, some would say.
The primary failure rate was felt in the software sector – or at least this is the sector that first felt the pain and sought the solution to such project failures.
These software people developed something called The Agile Manifesto – a set of values and principles that can be quickly summed up as build quick, get customer feedback, reflect and adapt.
The Historical Timeline of Agile:
2001 seventeen software developers, including Sutherland, Schwaber and Cockburn met and published the original document called Manifesto for Agile Software Development.
In 2005 Cockburn and Highsmith wrote a set of project management principles that guided others in the application of this philosophy, called Declaration of Interdependence.
In 2009 Martin wrote an extension of these principles, called Software Craftsmanship Manifesto. It shows us that the philosophy was still highly specific to the software sector.
In 2011 the Agile Alliance produced the Guide to Agile Practices, also known as Agile Glossary, which is a gathering of all the different Agile practices and extends beyond the software sector.
What Is the Philosophy Behind Agile?
Agile itself is not a methodology. There are a good number of methods that have emerged from the Agile approach to project management, including Scrum, which is sometimes wrongly seen as interchangeable.
Agile is a mindset more than it is a set of fixed practices. It is about coming up with a hypothesis of what might work, build this quickly, test and get real customer feedback and then iterate – or repeat after reflecting.
The Agile values laid out in the manifesto are:
- Individuals and interactions over processes and tools
- Working software (replace with other product/ service) over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The principles by which this should be achieved include:
- Gain information about customer experience early in development
- Welcome a change to the scope, as it will make the product/ service relevant in the end
- A working product/ service is frequently delivered
- It requires close cooperation between the business and the developers within a company
- Individuals are motivated by the trust placed in them to provide a product
- Communication in person is the best
- Working service/ product is the measure of progress
- The pace is constant throughout
- Keep it simple
- Best structures emerge from self-organising teams
- The team regularly reflects on what is or is not useful and changes accordingly
Behind this philosophy is the frustration of a fixed scope delivered from senior executives that teams are forced to perform even if they feel there are problems with this approach.
The emphasis is on empowerment of teams to work independently to a vision, which can be adapted if empirical evidence suggests something different should happen.
How Does Agile Project Management Work?
The primary choice an Agile Project Management team would make is the breaking of a more extensive outcome into small incremental steps, completed in short periods.
This means that no work continues for too long without testing, reflection and adaptation, if necessary.
The short periods of work are called timeboxes and can last between one and four weeks. Each timebox is also referred to as an iteration – as at some point it will require the team to reflect and change based on this reflection.
A second choice made, if adopting the Agile philosophy of project management, is that a team will be cross-functional.
This means there will be business working alongside design working alongside marketing and customer experience, and so on.
The whole team will work on tasks. Some tasks will be delegated to individuals based on suitability rather than on specialism.
The principle is that a lot of tasks will cross over specialisms and sometimes a team member will take on responsibilities held by others, as they are the most able for the most part to complete that task.
Next, if adopting Agile Project Management, you will accept that face-to-face communication is preferable to all other forms of passing information.
There are meetings held at the end of each iteration with the customer or stakeholder present. Each day should be started with a team meeting where the work done by each team member is transparent to the rest.
Transparency is key to this philosophy, so the work done by all should be on show for all to see.
Finally, the philosophy is marked by a short feedback loop and an adaptation cycle.
The point is to build in points of reflection so that work is not repeated or done when there is no point.
Therefore, making sure each team member is reflecting on the usefulness of the work done by all should mean the whole team is efficient. There is no wasted effort.
It also means the approach is quality focused – with testing built into the continuous cycle of improvement.
Should You Try Agile Project Management?
If you have a complex problem to solve and you need this broken down into simple steps that are easy to change if necessary, the Agile Project Management makes a lot of sense.
It is adaptive to feedback and does not rely too heavily on predictive models. However, the chance for scope drift within a highly adaptive model is higher.
It requires strong leadership, with a firm vision of the business case and growth outcomes, to keep the project in line with expectations. Predictive methods are often built on sound data and the expertise of the executive in this area.
Therefore, a sequential model from this well-planned starting point should be adequate in most cases – and the chance of the scope to drift is minimised.
Choosing an Agile methodology does help to reduce the danger of failure towards the end of a project. With a sequential model of project management, the product goes to testing after an extended period of planning, development and production.
If there are problems, the delay is going to be significant and costly. As Agile is an iterative approach any testing problems will show up early and changes made quickly to the direction the team is making.
This does mean that Agile best suits a product manager’s needs than a project manager’s. It deals with the what more than the why – which is the crucial difference between the two roles.
A final reason to choose Agile Project Management methods is that it places the customer at the centre of the development process.
It requires the team to deliver products/ services to the stakeholder or customer and not paperwork that suggests what might be. The production of documentation rather the creation of a product/ service is one of the significant advantages of such an approach.
However, many project managers will tell you that detailed early planning can reduce risk and manage dependencies – so such documentation should not be avoided.
Should you take on an Agile philosophy to project management? It depends on your project and your outcomes and your company’s comfort with a structural change from distinct departments to cross-functional teams.
In Conclusion
Agile Product Management was created as a response to project management failures. The perception is that the world is changing too quickly for the end outcome of a project to be too fixed.
There needs to be an element of reflection, adaptation and a development of the scope. The emphasis is on empowering the team and listening to the customer to get the best return on investment.
It is a philosophy that is marked by a proliferation of complex terminology but in practice promotes small steps over one big push to an outcome.
If you want to compare the Agile Project Management Methodology, read our explanation of the Scrum Methodology.