Last week I spent 2 days with Jens Østergaard getting up to speed with Scrum. Having been using Scrum for a while I thought it was about time to actually get certified in it and make sure those books I've read on the topic were leading me in the right direction.
Overall the course was excellent. The theory backed-up what I'd previously read on Scrum and the classroom exercises were insightful to say the least. The most disappointing thing was the number of the people in the class - not because the student:teacher ratio was poor (it was fine), but rather that so many folks were keen to learn Scrum. I was a bit surprised by that. Clearly it's way more popular than I imagined.
It's hard to understand why organizations still don't get it. Scrum is not perfect by any stretch of the imagination, and it's not easily to do, but it is eons better than waterfall. Why? Because:
- there will always be emerging requirements which need to be accommodated;
- written specifications are highly ineffective forms of capturing system details (verbal instructions and regular reviews of working software are far more productive);
- prioritisation of the features that offer the greatest immediate business value ensure the ROI of the system is maximized over the development life cycle;
- frequent, releasable deliverables means the customer can cut the project the minute they consider the system good enough - which can reduce the cost of the system;
- self-organizing, cross-functional, leaderless teams have proven to be effective in decision making;
- Project risk is lower because Scrum advocates visibility and honesty so last minute surprises and far less prevalent.
What appeals to me most is the fact that Scrum is based on empirical evidence more so than theories. Take for instance the task estimation process. Scrum advocates planning poker which is in effect an endorsement of the Wisdom of Crowds . By giving all the programmers who have knowledge of what's required an independent vote in the estimation phase, and reiterating this process until convergence, or agreement is reached ensures that task estimates include all collective input from the team and constitute a best-guess given that information.
With regard to written specifications Jens gave the class a series of insightful exercises where each team was divided into "programmers" and "spec-writers". The programmers then left the room whilst Jens presented the spec-writers with several diagrams that had numerous shapes on it - a few crosses, a series of congruent triangles, a rotated 5 point star, etc. You can see these diagrams here. The spec-writers had to write written specifications and pass them to the programmers who were waiting outside and who hadn't seen what the image was suppose to look like. All communication was written and the programmers had pen and paper to implement the specifications given. At the end of the alloted time, very few teams had a finished diagram from their programmers that looked particularly similar to the original. After a few attempts it became obvious to our team that detailed, unambiguous instructions were damn hard to do. Our team resorted to frequent short instructions based on what we had seen the programmers do on earlier instructions. If you were clinging to the belief that detailed written specifications were all that was required to successfully implement a system this exercise blew that notion out of the water in about 15 minutes!
All in all I have to say that the Certified Scrum Master course through the Agile Alliance is well worth it. And now....woohooo...I'm a Certified Scrum Master