So now I’m a Certified Scrum Master, or at least I will be once the paperwork is submitted and checked. Right now it’s a fairly painless process, you show up to a seminar, take part in an active way, and emerge at the end certified by the instructor. In a few months people will have to do an exam as well, which may or may not be an improvement in practical terms.
The two-day course was intense and I was glad I’d read up on Scrum first. The book I read was Ken Schwaber’s Agile Project Management with Scrum; the one recommended in class (run by Danube’s Jimi Fosdick) was his Agile Software Development with Scrum. After a brief introduction to the principles of scrum, we went to work on an immersion assignment using those principles. The energy level was high given the compressed time frames, all the teams came up with something worthwhile, and I for one left with a reasonable understanding of how scrum works when it’s in an ideal setting.
Which, of course, is the issue. Scrum is not a silver bullet, and won’t make up for problems in the organisation. Mr Fosdick was careful to point out that implementing scrum is risky, it tends to uncover problems in the organisation, and it often fails to give the results companies want for those reasons.
On the positive side, the Scrum Master role is very similar to what I’ve always understood the role of the project manager to be — keep the team moving, get rid of obstacles for them, keep meddling managers or sales people out of the way. It formalises those aspects of the role, and I like the idea of the sprint being a defined length of time, so you can always say to a manager or sales person that their important item will be taken into account at the next priority-setting meeting on a defined date. One issue that came up in the discussions was whether the Scrum Master should also be a programmer. Mr Fosdick’s opinion was that no, in practice a team with a dedicated Scrum Master is, as a whole, much more effective than a team with a Scrum Master who also codes. The main reasoning was that the Scrum Master who doesn’t code concentrates on getting impediments out of the way of the team, keeping track of progress, and thinking of ways in which the team performance can be improved while the Scrum Master who codes is also thinking about the code to be written, how much s/he can commit to doing on any given day, etc. This makes sense to me, though I know a lot of companies who insist on the project manager also being one of (perhaps the lead) developer on the team. If that conflation of roles works, there’s no reason to change it. If it doesn’t, it’s something to think about. I know in my work as a project manager, I’ve always found there is lots to do without also being responsible for delivering quality code as well.