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, over the last 5 years I have learnt a more methodical way of carrying out a project. A way that ensured that the project was well defined, had suitable requirements, 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 methodology. 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 transpired, is a “different” way of doing a project. The more I read about it, the more I thought “hey – this makes sense!” SCRUM also has a set of practices, and a set of predefined roles. Whereas PRINCE2 has it’s Executive, Key Customer & Key IT board members and a Project Manager, SCRUM has its SCRUMMaster, Product Owner and Team. However the difference is 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.
Obviously this way of working is not suitable for everything. I mean, 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.
I’ll be the first to admit that I am no expert when it comes to SCRUM. Heck – I’ve really only “discovered” it. There are some pretty good references on the internet. (See below).
See also: Quick and Angry – More on SCRUM