At its core, Agile Methodology is straightforward. It is a philosophy that suggests you make incremental steps towards the completion of a project rather than completing it all at once.
The methodology was designed for delivering software incrementally within a series of timeboxes. A timebox is another way of saying a defined period within which a goal will be completed.
In short – Agile Methodology equals small steps delivered in shorts of time.
This works particularly well in software development because you can break down the functionality you are going to deliver to the user.
These are called user stories – the user can start to use the software before all functionality is available to them – meaning revenue comes in sooner on the project, and the user is given small insights into the possibilities for the future of the software.
The user can then expect a series of software updates that increase functionality as each goal is delivered.
This process is iterative, which means that during each timebox you build in reflection and attempt to deliver improvement to the whole project continuously.
A two-week cycle of production and thinking is therefore called an iteration.
Although designed for software delivery, Agile Methodology can be used in all Project Management. The small chunks of functionality could instead be smaller deliverables that lead to the completion of the more extensive project.
Ultimately, Agile Methodology is a means of avoiding fatal flaws in projects being discovered too late and at too high a cost to the company.
How Does Agile Methodology Work?
The opening statement that this is a very simple approach now seems inaccurate.
There is a whole new vocabulary – time-boxed, incremental, user stories, iterations… all of which seem to make Agile seem complicated.
However, like all methodologies ever created, the language created around the actions is designed to exclude rather than include. It gives the impression that you need qualifications to be able to apply the methodology fully.
Here is how it works on a fundamental level, in a way that could be applied today:
- Take a high-level look at the project you are expected to deliver and set the time within which you are meant to provide it.
- Breakdown this high-level view of the project into a to-do list.
- Estimate an amount of time for completion for each item on the to-do list.
- Set priorities for which deliverables needed to be completed most urgently.
- Begin completing the to-do list in order of priority.
- Receive feedback on each of the smaller deliverables you have defined on your to-do list
- Reflect how well your to-do list represents the needs of the whole project.
- Reflect if the time allocated is reasonable.
- Create a new to-do list and new time estimates based on feedback and reflections.
- Repeat until project completion.
In Agile Methodology terminology, the high-level view of the whole project is called the Master Story List. The to-do list you create – or the smaller deliverables that make up the whole – is called the user stories. Each turn around the cycle of executing the plan and reflecting on the plan is called an iteration.
When you return to the start of a new iteration you must discover if you are a) going fast enough and b) you have too much to deliver in too little time.
At this point, a PM decides if the scope has the be cut or whether they will need to return to stakeholders to determine if you can change the end deadline and/or ask for money to complete the project.
Agile Methodology Best Practice
Agile Methodology takes a lot from the general project management best practice for results, but here’s what sets it different:
Iterative Development
Agile best practice is focused on iterative development. Meaning the PM starts with simple goals, tests these and then adds to the complexity and the ambition of the project.
This means the project is designed to have an evolving architecture, where there is an acceptance of all that the plans will change as they are continuously refined and tweaked as the production period moves forward.
Here is a new term to describe this acceptance that plans are never a straight-line to an end goal – they call it a flex on a scope.
In other words, the scope of the project may need to flex – to bend and change – to the reflective lessons learnt as the project continues.
This means that Agile best practice includes exceptional negotiation skills with stakeholders and the project team. There is no set plan signed off at the start of the project that should be delivered by a set time.
There is an initial plan that is signed off, and then the stakeholders expect that there will be new versions of this vision throughout the project period.
Organising Team to Work Together
Another best practice feature of Agile Methodology is the ability to allow roles within teams to blur into each other.
Some equate an Agile team to be something like a start-up company, where all members of the team pitch in to support the others in the roles allocated.
The QA analyst may also work on business intelligence, who may even step into looking at user experience, etc.
In short, the name of the methodology is Agile. This means that best practice requires people to move quickly and with skill in whatever way the project demands.
The highly defined scope with highly fixed roles would be the opposite of agile – it would be slow moving and closed in its thinking.
In Agile Methodology, the acceptance is that the requirements will and do change, and you need to reflect and adapt to be successful.
Agile vs Prince
Prince Methodology works on the basis that tasks need to be completed in a set order. Dependencies are the name of the game here. For Y to happen, it is dependent on X being completed first.
Therefore, a Project Manager will define a workflow for a more extensive project that is broken down into a series of steps that are given deadlines so other parts of the workflow can begin.
Prince sees the delivery of project management as a marathon, mostly inflexible in its direction, but methodical in the delivery of outcomes. The project is front-ended by in-depth planning.
However, as the project progresses the manager brings the planning horizon into focus as each step is taken – but mostly the steps are left unaltered – it is just the fine detail of how they are delivered is given more depth.
For a successful Prince project, you build yourself a Gantt chart, and Kanban workflow cards and the Project Manager makes the assumption that the team can follow the direction expressed in these documents.
Prince is the most widely used project management methodology. This is likely because it is a methodology that allows executives to manage better and control projects.
Stakeholders have a clear handle on the business case for each project and the definable outcome and how it fits into the strategy of the whole company.
Rather than a marathon, Agile works in short sprints.
The high-level planning is still there, but there is a presumption from the start that this is likely to change as each iterative step is taken.
Each day in an Agile project team should start with a 5-minute meeting to review progress from the day before and to consider the best moves to be taken that day.
There is an enormous flexibility in an Agile project team but, and it is potentially significant, but the chance for scope drift is vast. Unless there is a strong visionary taking the lead, it is easy to lose sight of the overall goal if the team is not steered correctly.
Agile is a methodology preferred by the teams completing the project because it gives them the flexibility to define the project as they learn.
It dramatically reduces the frustration of inflexible workflows and deliverables.
Arguably the primary reason teams enjoy using Agile more than Prince is because the iterations rely on interaction with the user experience, so the sense of achieving something valuable is felt throughout the project, rather than the scary wait for outcome measures when delivering a complete project at the end.
Should You Use the Agile Methodology?
Neither Prince nor Agile Methodology provides the elixir of perfect project management strategy.
Both approaches require discipline by the Project Management and the team delivering the project.
Agile may give more freedom to the team to deliver a valuable product tested throughout by the user. However, accountability moves from the executive level to the team, as the reflection and iterative approach means that changes can be made without executive overview.
If a company is highly creative and with an environment that accepts the risk, then Agile Methodology offers a potential for flexibility and responsiveness.
Some theorists suggest there is a half-way point between the fixed Prince and the flexible Agile methodologies.
This is where there is the control and governance of Prince, where the front-end planning defines a scope within which an Agile team can work and adapt to what they learn.
For the most part, it would entirely depend on the organisation and its ethos as to whether Agile Methodology in project management would work for them or not.
And if you’re still not sure if your company needs a project manager, read why is it beneficial for businesses to hire a project manager and which type of PM to look for.