PRINCE2 is a formal, structured approach to project management. Agile methods are a family of developer-oriented software engineering approaches. They are very different animals. How can they possibly work together?

Well, wait a minute. There's a clue in there: they are different animals; they're about different things. Different, but exceedingly complementary. PRINCE2 is about project management. It provides a framework for project managers to track the construction and delivery of products against a plan. Agile methods are about constructing software in a more responsive, more customer-focused way, with an emphasis on built-in quality.

In actual fact, they're a perfect fit!  Let me try and convince you.

First off, PRINCE2 is as formal and structured as you need it to be. One criticism I've both read and heard first-hand is "all this formal process stuff just weighs us down and gets in the way". My response is always the same: "well, you're doing it wrong!" One the key principles of PRINCE2 is tailoring: take the framework and scale it down (or up!) to match the kind of project you're running. In fact, the 2009 revision to PRINCE2 reiterated its underlying simplicity by recognising explicitly seven principles:

• There is continued business justification for a project (or you should stop!).
• There are defined roles & responsibilities (everyone knows what they should - and should not - be doing).
• Manage projects by stages (bite-sized chunks are easier to track).
• Manage by exception (don't micromanage or meddle when things are going fine).
• Focus on products when you plan (think things you can measure and tick off a list, not open-ended tasks).
• Tailor the process to a project's size, complexity etc.
• Learn from experience! If that didn't work last time, change it!

Fundamentally, that's it!

Another criticism I've heard runs like this: "PRINCE2 was no use in helping us build this software, so we gave up and used Agile methods instead."

My response is "well, sure it wasn't! That's not what it's for." Let's back up and look at the list of principles a second. The only mention of building or making anything is "focus on products when you plan." It doesn't say anything about *how* you should build your products. In fact, you can drill as far as you like into PRINCE2 and find nothing about how you should write software, or make anything at all. The only things PRINCE2 says about making things is the following:

• focus on products when you plan;
• break down complicated products into smaller ones, until each unit needs around 5-10 days' effort to build;
• factor quality procedures into your building process;
• have a mechanism to hand a product-to-be-built over to the technical team - a spec of some kind (PRINCE2 calls this a "workpackage") - and a way to sign off built products that come back.

Now, change a few words and this looks very like the description of a classic Agile iteration. "5-10 days' effort" - that's the recommended length of a code sprint or a user story. "Factor quality procedures in" - developer unit-testing, anyone? A mechanism to describe products to be built - user stories again, or sprint backlogs fulfill exactly this role.

The beauty is, you can use PRINCE2 to manage the *project* and your favourite Agile methods to write the *software*. The two methods are entirely complementary; they touch only in the definition of what constitutes a "workpackage" - and they even agree on how big that should be!

None of this should be surprising. Both methodologies share the same fundamental tenet: they're not plucked from thin air, they're based on common sense and practical experience of how human beings organise to get stuff done, and how much detail anyone can reasonably be expected to keep in their head at any one time.

So, by addressing some thought to the best way to specify workpackages in the language of your chosen Agile method, you can leverage the power of responsive, quality-led software development within a structured, measurable well-managed project framework. What's not to like?!