Image Source: Flickr by Enrique Fernández
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.
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.
Want to learn more?
Below is a selection of resources that I personally feel are relevant to this blog post, and will allow you to get more in-depth knowledge. I do earn a commission if you purchase any of these, and for that I am grateful. Thank you. (Important Disclosure)
Scrum is an excellent agile method and I am seeing the core concepts of agile development being applied more and more in ECM projects, often in terms of a Model Office approach to requirements capture, design, build and test.
Thanks for your comment. And also thank you for bring this “Model Office” concept to my attention. I’m going to go and find out more about this.
In fact, I see that there is some interesting material on your blog (mcgratha.wordpress.com)
Yes, different roles and approach plus also maybe different mindset. I think mindset is the key to success – too often agile is approached with an old (Prince2) mindset which only leads to confusion and mixed success!
You so right Tom.
They do require different mindsets. Sometimes it is necessary to tackle the new way (Agile) with a “blank mind”.That is, embrace what Agile proposes without behind tied to “how it was done originally’. Even better would be use Agile, and adopt a new way of thinking, while being able to draw upon gems from PRINCE2.