Yesterday I did a Scrum presentation for a group of Minions of The Dark Side: people from the Dutch PRINCE2 User Group. I had expected them to have horns, hooves and pointy teeth. But my perception turned out to be false. (Though it must be said that one guy wore large boots, so I'm not sure about the hooves.)
PRINCE2 can be described as some sort of a European interpretation of the PMBoK: a somewhat heavy collection of best practices for professional project managers. I'm quite certain that I am offending both PRINCE2 and PMBoK people with that description. It's like throwing Agile and Lean in the same corner. Neither the agilists nor the leanists would agree with that, though both camps would agree that PRINCE2 and PMBoK are in a corner at the other end of the world. It's like America and Canada versus China and Japan. They are all different, but some are neighbors and others are not.
I had invited the PRINCE2 people to talk about how SCRUM differs from PRINCE2, and what both frameworks could borrow from each other. I had at least six strong Scrum Masters and Product Owners as potential body guards with me, but that turned out to be unnecessary. In fact, we all had a very inspiring evening together with our guests! Let me summarize it for you:
These are often mentioned problems with PRINCE2/PMBoK in software development projects:
- Resistance to changes in scope
- Counterproductive devotion to a plan
- Overemphasis on task-based planning
- Imposing project manager
- Excessive documentation
In our discussions we agreed that these problems are symptoms of incorrectly applying the framework and its principles. Well, doesn't that sound familiar? Agile software development has the same problem with people incorrectly applying the principles (or not at all), and doing Agile In Name Only (AINO). So we found some common ground there, agreeing that our favorite frameworks both get a bad name because other people make a mess of things. (Not we ourselves of course.)
On the other hand, most of us could agree that Scrum does a better job at explaining itself to its users. If you open the official PRINCE2 documentation, the first thing you see is a huge diagram that rapidly robs you of your will to live. The Scrum documentation is smarter in the way it conveys its message of simplicity, and which practices are essential and which ones are not.
We saw opportunities where Scrum projects could benefit from some PRINCE2 areas and practices, like: Project Initiation and Project Closure, roles on the customer's side, managing portfolios and programs, and Cost Management and Risk Management. We also saw the need for adaptation of PRINCE2 to the complexity of software development: like continuous customer availability, continuous change, and continuous process adaptation.
One of the most interesting parts was how to combine Scrum and PRINCE2 so that a Scrum project can live in a PRINCE2 world. I had borrowed some information from Scotty Wakefield, who has described four possible scenarios on his own blog, in Scrum and Prince2: working together? Scotty's conclusion (and mine) is that you should always use Scrum (or some other agile framework) for software development, and then augment it and interface it for PRINCE2 (or some other formal framework) when the rest of the business requires it. (This is scenario 4 in Scotty's blog post.)
So, maybe PRINCE2 itself doesn't suck as much as I once claimed. There's certainly a place for it in our universe, and perhaps even in software development. However, I still think that PRINCE2 communication and documentation suck like a Dyson cleaner.
(pictures by annia316 and Hiddenloop)
Twitter -
Subscribe -
Newsletter -
Bookmarks
Latest, greatest and favoritest posts:
Checklist for an Agile Game
I Follow My Rules, You Follow Yours
Embrace Diversity, Erase Uniformity
