Jun 242009
 

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.

Jun 032009
 

Many people outside the knitting world probably don’t think about the fact that knitters have conferences too, where they register for classes taught by famous people at some venue. Recently a famous knitter (Stephanie Pearl-McPhee, aka Yarnharlot) organised such an event. I think she got some bad advice from her IT people, whoever they were, about what would be required to run the online registration system.

To be fair, the IT people thought the organisers were being optimistic about how many people would show up. I’m going to summarise the salient numbers; if you want more details, read the blog post. With 12000 on the mailing list, they figured 5000 people was the number to expect, competing for about 4000 spots. The organisers “built a huge server and a pretty good system” for those expected 5000 people. In the event, they had over 30,000 simultaneous connections, and the server couldn’t handle it.

It seems to me that these requirements are precisely what cloud computing should be able to handle. For this particular event, it was possible that only 1000 people would try to register at once, or that lots more would. The load could have been spread over a couple of months if the conference seats sold slowly, or over an hour if they sold fast. Buying a server big enough to handle the maximum expected in this actual case resulted in a server and system that were too small; it could have also happened that money was wasted on something that was far too powerful for what was needed.

What I’d like to know is how, in general terms, should such a system be architected? If you were using this as a case study on how to do cloud computing, what would you propose? Some more requirements: People can register for more than one class. Class sizes are limited, and the size depends on the class. The system has to include an online payment system.

I’m not looking for lots of details, just a broad-brush outline of a paragraph or two, like “put X on one virtual server that can scale up, and Y on another”. My personal experience so far of “the cloud” has been for storage rather than these sorts of systems, and this use case has intrigued me.

/* ]]> */