All about agile

These days, agile project management is often practiced as a standalone methodology.

As the name suggests, agile is a flexible response to delivery for those projects that cannot be perfectly mapped out in the planning stage. 

Born from software projects where the end-state is known, but the process for getting there cannot be understood until the outputs of earlier tasks are realized, it is now widely applied in many industries (including sometimes, it should be said, inappropriately).

Indeed, the default for projects should be to complete planning before starting delivery; unless the specific circumstances of your project make this impossible – we’ll explain why in a minute.

Critically, agile does not excuse you from properly initiating a project. If anything, it is more important than ever to complete a comprehensive and robust business case because overall delivery is focused more on outcomes than outputs, as we shall see.

What agile does particularly well is stakeholder communication through regular, programmed meetings.

---

The agile process

Vision

As with any project, an agile one starts with an idea.

When documented, this is sometimes called the ‘vision’ for the project.

User stories

User stories are then gathered from stakeholders and used to define the features of the project solution.

Each feature can be defined using the following user story structure:

• As a… (type of user)
• …I want… (a specific product / service / result)
• …so that… (outcome / benefit / value)

For example, as a coffee connoisseur, I want Google Maps to show me nearby coffee shops with community reviews so that I can find the best coffee near me.

Product backlog

The user stories/features are then collated in a product backlog. 

This is an unordered task list that looks exactly like a work breakdown, without the structure. 

As it is a WBS, acceptance criteria, and estimates of resource requirements and delivery times, should be applied to each task.

Sprints

Every two weeks, the project team delivers an iteration of the project. 

Each iteration (or sprint) is essentially a mini-project.

It begins with a sprint planning meeting, where it is decided what tasks to bring forward from the product backlog into a new, sprint backlog. 

These tasks are then planned for in a 2-4 week sprint time-box, meaning they are properly scheduled and budgeted for and risks considered.

Tasks are then assigned owners, and delivery begins.

Daily stand-up

The most visible element of agile is the daily stand-up, or scrum. 

This is a 15-minute meeting held at the start of every day where each project team member answers the three questions shown.

The sprint backlog is then updated, with committed items being flagged as either not started, in progress, or completed.

Lessons learned

At the end of each sprint, incomplete tasks are returned to the product backlog, and a two-hour sprint review is conducted. 

This is intended to remaster the product backlog and ensure that outputs are still aligned with the intended project outcomes.

A sprint retrospective should also be conducted at this time to identify and incorporate any process lessons learned.

---

Pros and cons

Buzzwords aside, smaller release cycles and regular – daily – feedback means that there is a high level of quality assurance built into both the project outputs and processes.

I personally think the tight, time-bound meeting methodology is a perfect fit for standard projects as well.

Nevertheless, there is a huge risk in agile projects that the schedules and budgets agreed to in the business case will overrun, as uncertainty levels are much higher. 

We also know that the cost of change increases the further you get into any project; these costs can significantly blow out if we are unable to comprehensively benchmark them before we start.

Agile project management also depends on a high degree of team, management, and stakeholder collaboration. 

If this is not forthcoming, or even if a key stakeholder (such as a team member) changes mid-delivery, there can be serious consequences for the schedule as new members are brought up to speed.

That said, there is definitely a place for agile delivery methods, even within what we call the waterfall approach – that is, the standard lifecycle process. 

Despite what some evangelists might say, the best-practice principles of project management are actually undisturbed by agile; if anything, they are more rigorously enforced during delivery!

I like to call it project management on steroids.

Therefore, on smaller projects with clear objectives, tight, expert teams, and uncertain outputs, agile project management is strongly recommended.