Agile for PMs – where are the projects?

The “Agile for PMs” articles are written for experienced project managers who are interested in exploring how Agile development differs from classical project management.
In these articles, “Agile” is generally capitalised (and sometimes used as shorthand for “Agile development). The Agile Manifesto is described in more detail in other Plays on this site.

Projects are central to project management but are not a concept used in Agile development. In this article, I look at the concept of a “project” and why this is approached differently.

What are projects?

Most people with a project management background are familiar with the PMI definition of a “project”.

The existence of a project suggests a specific direction of working.

Let’s look at that project management classic, building the Sydney Opera House. For anyone who isn’t familiar with the project, there are many articles written on the subject (example).

1. A goal is set (“create a new Opera House”) to represent the change to be achieved.
2. A team and budget (AUS $7 million) are brought together to support the work.
3. Designs are created (a location on Bennelong Point in Sydney and Jørn Utzon’s architecture design chosed in an architectural competition).
4. A work breakdown is created to represent the work needed to achieve the goal.
5. Given the constraints of goal, budget and initial design, a plan is created.
6. Work is scheduled based on the plan and an idea of end date assessed (four years).
7. Work begins and is tracked against the plan, with change management as needed.
8. We achieve the outcome, controlling schedule and cost.

To simplify, projects follow this flow:

1. Start with a desire to create something (“a unique product, service, or result”).
2. Agree the goal – what we are trying to achieve.
3. Initiate and agree what we need to get there (scope, team and budget)
4. Plan how to get there (work breakdown and plan)
5. Monitor and control the work against the plan
6. Close and verify the final creation against the original scope

It’s tempting to see Agile development as just part of step 5 – “monitor and control the work”.

Why Agile development doesn’t have projects

While projects are described as “create a unique product, service, or result“, the Agile Manifesto refers to “Agile processes promote sustainable development“. Rather than a single end point, the target is a continuous sustainable pace over a long timeperiod.

This is a more applicable model in software development, the main area where Agile development is applied. For example, consider Microsoft Office 365. Office 365 has no “end point” when it is complete. Formal releases are made monthly and each one adds incremental value to customers.

This may sound a relatively minor difference in wording (the similar words “project” and “product”), but it changes the basic flow which we described in the previous section.

The big change is actually step 2 above “We agree the goal“. If there is no final end, there is no single goal. And with no fixed scope, steps 3 and 4 also need to be different. There is still planning, but it needs to be different if we cannot set a goal or how to get there.

In a project the key central point is the fixed goal, around which we create a team. In Agile development the starting point is typically a cross-functional team.

Projects bring the team to the work.
Agile brings the work to the team.

Navigating or exploring?

Project management is like navigating a well known part of the ocean. The first step is to arm yourself with a good set of maps and charts that tell you the best route to your destination.

Agile development is more like exploring a new continent. You still invest in the best gear, but it’s more likely to be an experience crew, a good compass and sounding gear to make your own charts and find the best route.

It’s a big mindshift. But is it madness? Is Agile development throwing away too much control by not having an end goal specified at the start? There is an equivalent in traditional project management.

A project management equivalent

The Sydney Opera House was initially estimated as AUS $7 million and four years of work. It took AUS $102 million and 14 years to complete, or an overrun of 15x cost and 3.5x in schedule. I’m not saying that to suggest “project management doesn’t work”. However, in the subsequent years, people have realised that you need to adapt approaches in the case of:

• high change (the government frequently changing the design)
• learning (not knowing at the start how to construct the sails)
• lack of information (ground surveys not done at the start)

Agile development and programmes

In project management, learnings from large, uncertain developments such as the Sydney Opera House led to the discipline of “programme management”. Programmes exist to deal with high change, learning and lack of initial information. In project environments, the complexity which programmes address typically comes with scale. That’s why the Sydney Opera House proved so hard to deliver.

In Agile development, complexity appears at a smaller scale. As a result, it can be helpful to think of Agile development mapping more to a programme than to a project. Applying programme ideas at project scale. Different articles will look at how these components of a programme are addressed.

A programme is described as below. This is based on the UK “programme” concept, while a US “program” is defined differently by the PMI.