Lean-agile and PRINCE2

I have been involved in recent discussions on structured project management methodologies. In particular PRINCE2 (which I’ll focus on here but the discussion could apply to any traditional project management approach). Are traditional methodologies like PRINCE2 compatible with a lean or agile way of working?

There are plenty of blogs discuss the experience of making PRINCE2 and lean-agile ways of working fit together and it’s certainly possible. My issue is not that PRINCE2 is wrong. It’s more that, for a IT development project, it encourages us to put our focus in the wrong place.

Discovery

Lean-agile ways of working emphasis the discovery nature of IT development. The tricky thing about projects involving IT development is that they are characterised by large uncertainties in both what is needed and how to build it. In this way, it’s more like other creative disciplines like marketing, R&D etc. where progress cannot be pictured as a linear function of the resources applied over time. We could call this the discovery mindset:

the customer doesn’t know what they want,

the developer doesn’t know how to build it,

things change.

IT development projects do have one redeeming feature – they can normally be delivered in small pieces which enables discovery to be done collaboratively in short learning cycles whereby we find out what is needed and how to build it by trying a bit in a short cycle.

Risk and Learning

PRINCE2 implies that the risks that need most of our attention are cost, time and scope overruns. Not really. The biggest risk in IT development is building something which isn’t used (ref. Mary Poppendieck) What needs our attention most is answers to the question of how we can learn faster about whether our solution will be used. Thick contractual requirements documents which are produced upfront, beloved of so many PRINCE2 practitioners, actually increase the risk that we build something that isn’t used since they increase the amount of work done before we find out.

Making learning our primary focus has all sorts of implications. PRINCE2 implies that change happens rarely and need to be strictly controlled. Yet if we are learning all the time, change will happen, well, all the time. Lean-agile practices embraces change and treats it as “business and usual”. Take retrospectives – these happen often, unlike the PRINCE2 lessons learnt report which happens only at the end. Or planning. This is a core activity in the PRINCE2 world, yet planning is merely helpful in the lean-agile. Planning is of limited value because there is always so much we don’t know yet – we typically can plan quite well the next couple of weeks but beyond that it gets vague. We need to iterate on our plan as we learn more.

Flow

PRINCE2 typically has no real concept of flow beyond the level of the GANT chart. Usually, each step of the GANT chart is executed only once. Lean-agile practitioners frame a project more in terms of setting up a production pipeline and then flowing small work items smoothly through it. This allows for adjustment and learning – it becomes a repeat game and we don’t have to get it right first time. Lean-agile thinking acknowledges that output actually goes up if a team is not working on too much at any one time. As such, lean-agile teams tend to pull work into the pipeline when there is capacity (and not when the GANT chart says they should. As Scott Ambler says “friends don’t let friends use Microsoft Project”).

Managing smooth flow (i.e. not having work piling up someplace; in testing, for example) also has implication for recruitment. Lean-agile teams tend to value people who are multi-skilled since they can move to where the bottleneck is building up in the pipeline – the location of which is impossible to predict in advance. PRINCE2 practitioners tend to prefer engaging specialists as these are the most effective at particular tasks that have been planned for them to do.

Value

If we are good at prioritisation, we might learn at some point that we have implemented 80% of the value for 20% of the cost and want to stop the project now. Scope is typically variable in a lean-agile project. PRINCE2 tries to nail down scope, cost, quality up front since it assumes these can be understood well enough before work starts – a questionable assumption for IT development.

Quality

PRINCE2 has a very contractual definition of quality. If we could usefully specify quality contractually in IT development e.g. “1 bug per 1000 lines of code”, we would. Alas not! Lean-agile thinking addresses this in a more practical way – quality is in a lean-agile context is about getting quick and complete feedback on our activities which then allow us to adjust and improve – quality is built into the process itself.

Collaboration

Stakeholder management in PRINCE2 is “contractual” with clearly defined roles etc. Lean-agile thinking focuses more on collaboration, face-2-face communication, joint problem solving etc. which is some way from the formal mindset of PRINCE2. It also typically emphasises self-organising teams since the team is closest to the work and hence are the ones who are learning the most about who is best to do what.

Recommendations

So here’s my top five points for a PRINCE2 project manager who wants to maximises his/her chances that an IT development project will deliver value:

Make your primary focus to enable fast learning everywhere in your project (particular about whether the solution is actually used. Get started on this immediately by getting the smallest chunk of value possible in front of them straight away). Learn both about the customer needs and how to build the solution. Be fanatical about this.

Frame the project as quickly setting up a “production pipeline” through which there is a smooth, fast flow of small requirements.

Be OK with not pretending you know too much about the future. Educate your stakeholders as to why this makes sense.

Charter your team to deliver as much value as possible with a given timeframe/cost and the let them work out how to do this.