Scrum vs PRINCE2 – My thoughts

One thing I used to hate was working on Projects that had no “definition”.

They were usually just a case of stumbling along, hoping that everything was going according to plan (not that there ever was a “plan”). And then working madly at the end to get something that was close to what a sales person had promised a client.

Then I learnt about a more methodical way of carrying out a project. A way that ensured that the project was:

• well defined,
• had suitable requirements,
• and had appropriate milestones against which the progress of the project could be measured.

This methodical way ensured that the correct documentation was created at the correct time, and followed a suitable life-cycle. Very much based on the PRINCE2 methodology.

And I liked this way of doing a project. It had structure. And is still very relevant and appropriate to many situations.

 

Meeting Scrum

Recently I have become more aware of the SCRUM method.

Originally I thought it was to do with the sport Rugby, and since I was brought up to worship the All Blacks (part and parcel of the culture I grew up in) I was surprised that SCRUM, in this case, had nothing to do with men in rugby jerseys fighting over possession of an oval ball.

No – SCRUM, it seems, is a “different” way of doing a project. The more I read about it, the more I thought “hey – this makes sense!”

 

Similar Roles – Different Approach

Like PRINCE2, Scrum also has a set of practices and a set of predefined roles.

PRINCE2 has it’s Executive, Key Customer and Key IT board members.

SCRUM has its SCRUMMaster, Product Owner and Team.

Further to that, while PRINCE2 is a process-driven project management method^,
SCRUM is reactive/adaptive method.

This is highlighted by the fact that the SCRUM methodology involves several sprints – periods of two to four weeks – where the team work on  creating a potentially shippable product based on high-level requirements.

 

Not for everyone

This way of working is not suitable for everything.

Just imagine a company building a motorway, or a high-rise building, where every four weeks that make changes based on “high-level” requirements. In those situations, you do want your processes.

However for smaller projects, such as developing a corporate portal, or similar, the SCRUM methodology seems to really make sense. Especially when you are relying on requirements from users who don’t really understand, or know, what they want. In this case, the build it, and then “rebuild/modify” based on feedback is a faster way of working.

 

Recommended reading
(Important Disclosure)