Principles, prince2ples, everywhere… Part II

In the first part of this blogpost I have elaborated on the Prince2 principles from the viewpoint of the Agile mindset. Today we are going to turn the tables. We could consider the four Agile values defined in the Agile Manifesto as our primary subject; however, with a full set of twelve available Agile core principles that would be a shame. It is possible to recognize benefits for projects from all of the twelve Agile principles [3]. This is an interesting exercise, but it is not the same however, as judging these principles from another viewpoint.

A small side note: in order to keep this blogpost from becoming an unwelcoming long read, I will be short on those principles that are not part of Prince2 at all and rank these as neutral votes.

1. Customer satisfaction
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Being on time and within budget are still often the classic elements on which a project is rewarded, with quality often as the lesser third.Although Prince2 values finished work packages, these are often part of progress reports; early and continuous delivery of software is not required. Working software is just not the highest priority. As the iterative flow of Prince2 does encourage smaller delivery moments, a neutral vote fits best for this principle.

2. Embrase change
Welcome changing requirements, even late indevelopment. Agile processes harness change for the customer’s competitive advantage.

Welcoming change is a different approach compared to a strict defined change process to cope with adjustments. A little exaggeration to indicate the contrast: Prince2 follows the paradigm “Stick to the plan” whereas Agile is designed on the paradigm “Change the plan”. Changes in Prince2 follow a formalized process. Due to their nature of being a change to the current project plan, they often require an official approval from the project board. The principle is therefore not shared and placed in the conflicting corner.

3. Frequent delivery
Deliver working software frequently, from acouple of weeks to a couple of months, with apreference to the shorter timescale.

As discussed in the first part of this blog, Prince2 uses stages or iterations to create a smaller scope. We linked this principle to principle 5 “Manage by stages” and concluded these were shared.

4. Ongoing collaboration
Business people and developers must worktogether daily throughout the project.

This principle is not part of any official Prince2 description. While there is nothing against it as well, we consider it as neutral.

5. Support self organization
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

This principle has one interesting aspect that stands out for me. It is the last phrase, “trust them to get the job done”. In the very acronym of Prince2 the term “Controlled” is present, which makes me refer to a quotation attributed to Lenin: “trust is good, control is better”. I have a hard time convincing myself the principle is shared.

6. Face-to face communication
The most efficient and effective method ofconveying information to and within a development team is face-to-face conversation.

In the discussion of the second Prince2 principle “2. Manage by exception principle” we already concluded the two methods have an opposite approach. The conflicting votes have gained another member.

7. Progress measurement
Working software is the primary measure of progress.

While monitoring progress and clear reporting is an important aspect of Prince2, there is no defined measurement of progress itself. The project manager is responsible for setting up fitting measurements and reporting to the project board. Given  the fact that working software is in practice an important part of the progress report, I lean towards a neutral vote.

8. Sustainable development
Agile processes promote sustainable development. The sponsors, developers, and users should be ableto maintain a constant pace indefinitely.

One of my favorite Agile principles shows the difference in approach from the classic project methods. From a Prince2 perspective, with a temporary organization and fixed time frame, it seems there is no direct need to keep a sustainable pace. Projects with fixed dates even find themselves falling back to proven anti-patterns such as dead marches or scaling up teams to mythical proportions [2] when the end of the project comes into view. On the other side, I have seen this happening in Agile projects as well. Leaving the real life experiences behind, Prince2 does not have anything against a sustainable pace, so this principle finds itself on neutral ground.

9. Invest in Technical skills and design
Continuous attention to technical excellence and good design enhances agility.

This principle is not known or rewarded in Prince2; even more, enhancing agility is not a useful project goal to have at all as itcan lead to gold plating and over engineering. Good design in itself is valuable indeed. You can raise the argument that actual continuous attention to good design for agility is only a project goal if Changeability (as a dimension of Maintainability in ISO 1926) is in the official requirements. The omission of a Prince2 view on this principle puts it in the neutral camp.

10. Simplicity
Simplicity – the art of maximizing the amount of work not done – is essential.

Focus on concrete products, doing what is in the plan and not losing valuable resources on non-attributing work, these ideas are all perfect from a Prince2 viewpoint. In an actual project there will be discussions as to whether something is in- or out of the scope of the project. This is especially true in fixed priced projects. In Agile projects we have similar discussions in deciding when a story is Done (an interesting approach is Just Barely Good Enough [5]).  There is a mutual appreciation of this principle.

11. Self organization for the best results
The best architectures, requirements, and designs emerge from self-organizing teams.

Prince2 does not acknowledge self-organizing teams; on the contrary, team managers and project managers are responsible to guide the project and teams. The usual organizational approach is by Product Breakdown Structures (PBS) and distributing work packages to teams and individuals. Team involvement is then accomplished through team plans and team sessions. Although this means the teams are involved, they are not self-organizing. This raises the number of conflicting votes by one.

12. Inspect and adapt
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Learning is a defined part of Prince2: this corresponds directly with principle 3 “Learn from experience” and avoids reinventing the wheel. So this principle is shared.

Conclusion

The votes of the Agile principles perceived by Prince2 are in: there are 5 neutral votes, 3 shared ones and the remaining 4 present us with conflicting ones. The contrast to the outcome of the first part is big, where 6 out of 7 of the Prince2 principles are rewarded in Agile as well. How can this difference be explained?

First of all Prince2 is a general project management method, this means it can be used for any types of projects. Furthermore, it is stated the specialist contributions (in software engineering all team members) are not part of it. Agile is founded on software engineering best practices and describes a way how teams and specialist should interact. This explains why 5 out of 12 of the Agile principles are not present from Prince2 perspective: they are just too specific. The fact that the majority of Prince2 principles are rewarded by the Agile mindset can be attributed to this difference in granularity as well. And they are still good principles, in the previous blog we concluded that did not come as a surprise.

The next interesting observation is about the four conflicting Agile principles. Three out of four of these principles (5, 6 & 11) are tightly coupled to self-organizing teams and communication. Besides the previous point about being too specific, the Agile mindset is based on a very different starting point. This is best illustrated by the Agile Manifesto itself: “Individuals and interactions over process and tools”; it contrasts to the defined process that Prince2 is about. The remaining conflict, principle 2, can also be explained using the Manifesto: “Responding to change over following a plan”. Again, these plans are at the core of Prince2.

What can we learn from this exercise in principles? The most important aspect is that the views and actions of project management should be fundamentally changed when they combine Prince2 and Agile. The two methods can be set up as complimentary, but the shift in paradigm for project managers is bigger than for their practicing Agilists specialist (teams). That shift is not easy. In fact it is really hard to change attitude and behavior, particularly when the pressure is high in a project. Sadly, that is why so many ‘Agile’ projects or organizations [9] slip and fall back to the same mistakes made by old school project management – years and years ago.

Cheers,
– Sjors Meekels

Contributions & References

[1] Prince2: http://prince2.wiki
[2] Mythical Man Month, F.P. Brooks: www.amazon.com/The-Mythical-Man-Month-Engineering-Anniversary
[3] Agile Project Mngmnt for Dummies, M.C. Layton: Agile-Project-Management-For-Dummies
[4] Simplicity: agile-principle-simplicity-the-art-of-maximising-the-work-not-done
[5] JBGE Just Barely Good Enough, Scot Ambler: agilemodeling.com/essays/barelyGoodEnough.html
[6] Changeability: en.wikipedia.org/wiki/ISO/IEC_9126
[7] Agile Manifesto: www.agilemanifesto.org
[8] ScrumGuides: scrumguides.org
[9] Failing Agile- InfoQ: www.infoq.com/articles/agile-fails-enterprise

Filled Under: agile,agile projectmanagement,prince2,scrum,software development Posted on: 3 June 2016