ardonio.com

Lately I’ve been thinking a lot about traditional project management methods. In part to understand why/where they fell short for software and what their use might be. Some elements in the agile community seem to feel very strongly that all classic methods are evil and agile is the one true way. What I tried below is to go back to the principles behind a classic method, in this case Prince2, and see how that is different from Agile principles. Below I’ll be drawing primarily on Scrum as the example for Agile methods, even though I will refer to Agile in general on occasion. For those of you unfamiliar with Prince2 having a read through the wiki entry might be good because some of the terms might have a slightly different twist to what you’re used to in corporate. Similarly for those not familiar with Scrum a quick read on wiki should help you through.

1. Continued Business Justification

• A Prince2 project must at any time have continued business justification. This is done by actively maintaining and regularly reviewing (and explicitly approving) the business case.
• At the end of each iteration a potentially releasable and done increment is produced. Which means that after each iteration the project could be halted.
• The difference: Agile does not have the explicit business case but puts a hard focus on making sure that the project leaves value behind, even if killed early on. Prince2 on the other hand is typically reviewing the business case at the end of a stage which tends to run a lot longer than an iteration in Agile.

2. Learn From Experience

• Prince 2 has this as a very explicit element in the methodology that runs somewhat throughout all activities
• One of the core principles of Agile methodologies is “inspect and adapt”, this goes for artifacts like the backlog just as much as it goes for the how the team works.
• The difference: Prince2 simply states that throughout the project (i.e. in all reports and reviews) and during start-up and closing stage lessons should be sought, recorded and acted upon. Agile/Scrum is a lot more explicit in doing this by nature of having to continually refine the requirements. One of the big differentiators for me is that Agile also invites to challenge the methodology implementation itself during a retrospective at the end of each iteration, which is fairly unheard of in Prince2 as far as I know.

3. Roles and Responsibilities

• Prince2 defines explicitly the roles and responsibilities through the executive sponsor, senior user(s) and supplier(s), a project manager at a minimum.
• Scrum defines Product Owner, Scrum Master and Development team, with very clear responsibilities
• The difference: Prince2 puts a lot of focus on the management side of things and how those parties interact with little focus for the hands actually doing the work. Scrum takes a more inward looking approach and defines the interactions so that the work done can be optimized but by and large ignores everything that is outside the team (that all falls under the “the product owner represents the business” line…)

4. Manage by stages

• Prince2 defines stages to ensure that senior management has control points at major intervals throughout the project. At the end of a stage the project status is reviewed (including the business case, see above) to assess viability of the project
• The concept of breaking the work in blocks is inherent in the iterative nature on Agile and leaves us with a natural control point. Where Prince2 really goes to senior management Scrum tends to stop at the Product Owner who is empowered to take these kind of decisions.
• The difference is mostly in the length and intention of those blocks. Prince2 has those blocks as major points in time (typically these would be releases implemented over several sprints in Scrum) to provide a big set of functionality and provide a point of evaluation for the project at large. Besides providing a point for evaluation and reflection, the idea behind an iteration is equally to be able to quickly react to changes and discover obstacles quickly.

5. Manage by exception

• Prince2 has defined tolerances for each project objective to establish ground rules and limits of delegated authority.
• Agile defines decision authority at the lowest reasonable level (e.g. the team is said to be self organizing so it has full authority to decide how a feature will be implemented, the PO decides what features will be implemented in what priority, … ).
• The difference: Prince2 assumes that end responsibility is at the top of the organization and is delegated downstream (within well defined constraints). When exceptions occur the level that granted the authority is alerted. Agile does not take this top down model but defines authority at the place where the work is done. When something prevents that work to be done (i.e. the team needs more info from the PO) there is a trigger to look for help outside but since there is no explicit delegation of authority there is no “up” level to inform.

6. Focus on Products

• A Prince2 project focuses on the definition and delivery of products, in particular on their quality requirements.
• Obviously in Scrum there is the fact that the end of each iteration should produce a releasable and done product. The word “done” in that sentence is of utmost importance. It is that definition of done that ensures (amongst others) that quality is not dropped, documentation is present, … .
• The difference: Prince2 is very clear on defining the product up front at adequate detail. However the purpose of this product definition is to define the product’s purpose, composition, derivation, format and quality criteria and quality method. Satisfying that does not necessarily mean waterfall, however it is often interpreted like that. Agile does aim to define all those things too, however the point at which they are defined is different. Agile will define this at the latest possible moment (i.e. right before the iteration starts) and will plan the iteration accordingly.

7, Tailor to suit the environment

• Prince2 should be tailored to suit the project size, environment, complexity, importance, capability and risks. When tailoring it is important to remember that Prince2 requires information (not necessarily documents) and decisions (not necessarily meetings)
• Scrum does not leave much room for tailoring but is rather strict on a very limited set of elements. Tailoring Scrum isn’t so much removing things from the methodology but rather extending it with good/best practices.
• The difference: Prince2 was set out to be a very generalist method which means that a lot of things in the framework might be less relevant for your particular situation. Scrum aims to be very good at managing software development projects which means the methodology could be reduced to only contain things relevant for the projects it aims to be good

The last paragraph
The reality is that project management methodologies, classical or otherwise are not that different in what they try to achieve. Ultimately all aim to deliver projects within the business constraints in such a way that said projects can be done in an orderly fashion.
The biggest difference I think, and the reason why some classics got a bad rep, is because they have often been abused to enforce behavior that was counter intuitive for the type of project that is software development (i.e. a very R&D like activity which is hard to plan and predict compared to for instance building a house). Ultimately the classical methods are rooted in practices and experience learned before software was something that needed to be managed. When that became the case it was logical to draw on what was available and the methodologies grew and tried to (over)stretch and were somewhat blindly applied to software.
That is also the reason for one of my fears for the future of Agile. The very nature of Scrum (and Agile) was to do software in a very good way, when people will start to dogmatically take this approach and/or transport it to other types of work I’m afraid Agile might be the evil empire of the next decade.