To pick a book for September, please list your three suggestions in order in the comments below. The winner will be chosen by single transferrable vote in the first week of August. We are due to discuss this one on 9 September. [UPDATE: So Release It! by Michael Nygard is the clear winner.]
Our next meeting will be at 8pm on Tuesday 12 August 2008 at The Lamb and Flag to discuss Behind Closed Doors by Johanna Rothman and Esther Derby. This book is about management rather than software development as such, so the discussions should be slightly different from usual.
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.
With the July meeting coming up, it’s time to vote for the book to discuss in August. The usual rules apply - list your 3 favourites in order in the comments. Once a few votes are in the winner will be chosen by a highly complicated and proprietary algorithm that I’m not at liberty to reveal…
We are due to discuss this on 12 August, but I am likely to be away on holiday for this one.
[UPDATE: The winner is Behind Closed Doors by Johanna Rothman and Esther Derby. Mostly a management book, but since Agile is about teams, entirely relevant.]
Our next meeting will be at 8pm on Tuesday 8 July 2008 at The Lamb and Flag to discuss Agile Software Development with Scrum by Ken Schwaber. I’m personally doing some Scrum training just beforehand with Mike Cohn, so hopefully I’ll pick up some pearls of wisdom from him that I can share. See you there!
There were just four of us at the Lamb and Flag to discuss Tom Gilb’s book Principles of Software Engineering Management. Steven and I were joined by John and Ursula. John said that he had read the book in question some years ago. He said that lots of people didn’t really get it when it came out and he included himself in that category. One of the themes of the book is the idea of inspections, but John suggested that Tom Gilb had been frustrated that no-one really picked up on that. So he ended up writing another book Software Inspection to try to hammer the point home. Apparently people still didn’t really get it. John said he realised this when he read James Womack’s book Lean Thinking where there was a discussion of how western companies could never truly understand the ideas of Lean. I admitted that I didn’t feel that I’d really got what Gilb was driving at with inspections.
Something I did like about the book was the discussion of what requirements are and how they differ from solutions. No-one else discusses this - in other development methods it is always assumed that the customer takes care of that part and has at least some idea of what they want. Chapter 4 of the book did a very good job of exploring what parts of ‘requirements’ are actually just solutions. I loved the story of the California teacher system. The customer specified that they wanted a computerised system and that’s just what they got. Unfortunately it cost 7 times as much to use the new system as the old paper-based one. What they really wanted was a cheaper and more efficient system. But they expressed this by giving a solution, not the actual requirement. As Steven pointed out, this mindset is much like the thinking in agile and lean methods, where you focus on the end goals and delivery of value at all times.
While the mindset concentrating on the delivery of value was very much like lean, I found the idea of have one hundred attributes to measure the success of a project rather different. It seemed to me that this was almost like not concentrating on your base goal. Would the project be a success if all those attributes went in the right direction but the company became less profitable and less popular with its customers?
Going back to inspection, I said that the very use of that word is almost an anathema to those who practice lean. The mantra is that you should try to ensure that there are no defects, not look for them later. Ursula thought I had the wrong end of the stick and that there would always be defects in a software product and that Gilb’s inspection is more like the lean idea of “Stopping the Line” when there is a problem.
Steven said that he thought the key message of the book was that evolutionary delivery is key to success. John agreed that you need to give the users something as early as possible. This idea is now widely accepted, even if other parts of this book are not.
Ursula talked about the idea of constantly recording task estimates as a way of improving the quality of them. She also talked about confidence measuring. This was a way to see if people on the team had doubts which they didn’t want to bring up. It would be easier for them to say they were not confident about hitting a deadline perhaps than bring up the reasons why. I said that I thought that the idea of project velocity was a good one as you don’t need to keep re-estimating all the time.
Finally, I asked if anyone understood what Tom Gilb meant by an Open-ended Architecture. Steven suggested that it meant that the design was not constrained unnecessarily. I’m afraid this is something else that I didn’t really get. Someone may have tried to explain it to me, but I’m afraid it was too late in the evening for my brain to take it in by this stage.
Ok, cast your votes for the book we will discuss in July. Leave a comment outlining your 3 choices of book in order. We are due to meet to discuss this one on Tuesday 8 July.
UPDATE: It seems like Agile Software Development with Scrum by Ken Schwaber has an unassailable lead, so I declare it the winner.
Our next meeting will be at 8pm on Tuesday 10 June 2008 at the Lamb and Flag to discuss Principles Of Software Engineering Management by Tom Gilb. This was Steven’s choice and he explains:
The reason I add the Tom Gilb book, is that I met him at ACCU and he says this book from 1988 is timeless (rather like Mythical Man Month) as it is based on principles rather than specific technologies. He also said that this is the book that inspired Kent Beck et al to develop Agile software, and much of the agile principles such as evolutionary development come from this book… but they got some it wrong. So you could argue this is the original book about agile software development.
Ok, time for another poll to choose the book for June (set to be discussed on 10 June). Vote below for your 3 choices and I’ll do the usual single transferrable vote calculation before declaring a winner. UPDATED: I duly announce that Principles of Software Engineering Management by Tom Gilb is the winner.
Our next meeting will be at 8pm on 13 May 2008 at the Lamb and Flag. This will be our final meeting to discuss Erlang.
We have been working through Joe Armstrong’s book “Programming Erlangâ€?, but it seems that people have found it hard to find the time to follow through with this. I think the difficulty is that with a book you can pick it up and quickly read a chapter or two, but with a new language you need to put in more time. So I suggest that we also discuss whether to revert to the original pattern of meetings and just do a book each month. Unless someone has a better idea…