I was joined by Tom, Steven, Ursula, John and first timer Ed at the Lamb and Flag to discuss Ken Schwaber’s book on Scrum. I’d recently completed some ScrumMaster training with Mike Cohn, so I had one or two extra insights into Scrum over and above what’s in the book.

Steven began by saying that he’d begun by thinking that the book was very short, so would be easy to read. However, he found it quite dense and slightly repetitive. Ed said that while he liked the book, he didn’t really like the style very much. Tom felt that there wasn’t much to it and that he’d picked up most of the ideas in it from conferences and so on. Perhaps this is because what was fairly radical at the time it was written is no longer so? I also pointed out that there were parts of the book I just plain didn’t follow. Section 1.3.1 contains paragraphs discussing Sychsteps and Punctuated Equilibrium. This went straight over my head.

John admitted that he hadn’t read the book, but had picked up things on the web about Scrum. He questioned how the whole team pulls together in the right direction. Ed replied that using this methodology, there is nowhere to hide because the team needs to deliver working code every few weeks. If someone is doing the wrong thing or just plain lazy, this will soon be obvious.

John was pleased that Scrum seemed to embody some of Tom Gilb’s principles (as discussed in our previous meeting). But he seemed concerned over the lack of metrics to show that it works.

We then digressed into a discussion of software metrics. I questioned what metrics John would like to see. He suggested metrics around function point analysis and project predictability. I suggested that Scrum doesn’t concern itself with function points and the like because it is concerned with delivering value to the customer. In fact, if you can deliver more value (however measured) to the product owner with less function points then that would be good all round. I couldn’t help mentioning Martin Fowler’s essay on why he believes you cannot measure developer productivity. On predictability I pointed to the section of the book where Ken Schwaber talks about the difference between “defined” and “empirical” methods of process control (Section 2.1 in my copy of the book). His thesis is that software development is too noisy a process to try to control with the “defined” method, so Scrum goes for the “empirical” method instead.

Tom said he’d read the book and the thing he liked best was the way the team was protected from change during a sprint. He has seen first hand the problems that can occur when a team works on one thing, then switches to another and so on. In Scrum no changes are allowed during the sprint unless the whole sprint is terminated and the work thrown away. This sets a high enough bar that all but the most important changes are deflected until the next sprint.

Steven questioned if the sprint length of 30 days was set in stone as the book seemed to imply. In fact, on my course Mike Cohn suggested that 2 and 4 weeks were the most common sprint lengths. The main point is that you need to choose a length and stick to it so that the team gets into a rythmn.

Ursula asked about the difficulties of interacting with other teams who are not using Scrum or other iterative approach. This was not mentioned in the book, but at my course Mike Cohn talked about the idea of a “release sprint”. This is a sprint you do before each release to do things like awkward manual testing against legacy systems which it is not practical to do every iteration, but which must be done before a release.

I also pointed out the section on reuse (Section 7.1.2), as Ursula had asked about this at the previous meeting. She seemed to think that it seemed sensible, as it said that the code being reused must be stable before reuse can be considered.