I recently finished up reading another book about agile. This time it was Scrum and XP from the trenches.
It was a pretty good book. Well written, an easy read. I liked it because it described real world experience using scrum over several years at a software company in Sweden. It's good because it shows that in practice there were some deviations from agile doctrine that worked for them.
For example he suggests a three week sprint length. This makes sense because then the team can get some momentum. Plus the overhead of setting up and tearing down a sprint is very non trivial; so extending the actual clean development time is a good thing. He also recognizes that within a project the team and team members are constantly bombarded with issues that are not part of the sprint planning. In general only 40-60% of the team members time will be available for the actual new feature work in a sprint. The rest may be addressing new bugs, distractions with customer requests, network being down, helping out people who are looking at code you know about, general delays and distractions that happen almost every day. Unlike the unrealistic viewpoint of "sprint safety"; in the real world there is distraction and the wise developer accounts and allows for it.
Another thing I really liked is his honest talk about personnel. In one passage he suggests the ideal sprint team size is no more than eight. If you find there are 10 people assigned to the sprint he suggests to eject the two weakest team members. Excellent practical advice. In another passage about difficult to manage team members he says in some cases to consider if you even want this person on your team.
Some valuable common sense advice there. Far and away the real key to a successful software team is having predominantly strong developers on the team. That's more important than religious adherence to the development methodology fad of the quarter. The author recognizes scrum will not transform weak developers into average developers; or average developers into good developers. After the stand up meeting everyone just goes back to their cubicle to write good software; mediocre software; or bad software.
The author talks about the problems there were at the company before he joined. I know he credits scrum with a lot of improvements. Still I wonder how much improvement was the undertone of the book which was that after he arrived he was allowed to get rid of low performing developers; I suspect previous management was unwilling or unable to do this.
I liked what I would call real world scrum like this book and the works of Scott Ambler. Hearing some of the dogmatic scrum theory; it's hard to grasp some of it. So it's good to hear of bridging the gap between the real world software development and the strange world of the agile theory.
