I thought it was very interesting that Alistair Cockburn came across the agile principles through the need for efficiency rather than the need to handle rapidly changing requirements. It is also interesting that his project background is of the fixed price, fixed scope variety. This is generally considered an area where it is difficult to achieve success with an agile approach although I have worked on projects like this which have successfully delivered as well. From my experience the key benefit of the agile approach touted is the ability to rapidly respond to changes in requirements but I also believe that the gains in efficiency we gain from the quick feedback cycles is certainly equally important in my book. Tim Bray has an interesting article talking about the potential for agile to thrive in this current financial climate due to the efficiency gains it can provide.

I found the idea of software projects being a cooperative game to be a very good metaphor for understanding the trade offs that we make on projects. We need to consider the current game and future games that we will need to play. We can make decisions which benefit us in the current game (e.g. taking shortcuts on design) but we must remember that these decisions will have an impact on games that occur in the future (e.g. increased technical debt to pay off).

The approach I have seen on previous projects has always advocated achieving business value as the number one priority for story selection. The author advocates a slightly different approach whereby we first tackle the highest risk or highest learning tasks first so that the team can gain this knowledge early while also being sure that it is technically possible to do the things they are being asked to do. This is linked to the idea of the walking skeleton - whereby we create an implementation of the system that performs a small end to end function. Clearly when using this approach it is important to still try and show that we are achieving some business value otherwise the project sponsor may become very nervous.

The book has some interesting suggestions around retrospectives or reflection workshops. One which we are currently trying on my project is the idea of wrapping up the retrospective with two lists - 'Keep These' and 'Try These', which contain the ideas suggested in the retrospective. We can then prioritise the items on the 'Try These' list and go through the most important ones before the next retrospective.

Another idea which was quite different from what I’ve come across was the idea of systems personalities. The idea here is that the system displays a different 'personality' to different end users. For example it might be fast and efficient or warm, friendly and informative. This seems like a good approach to allow us to drive out exactly how important different aspects of the system are and makes the trades off we inevitably have to make more related to our overall goal.

The idea of having an expert user as well as a business expert working with the team was another interesting idea. From my experience it is very difficult to get a business expert to come and work with the team full time so I’m not sure how we would be able to get another person to come and work with our team, but several colleagues suggested to me that they do have an expert user working on their team so it is possible. I can see this being a useful role though because we often come across situations where there are two ways to do things and it’s not obvious which way the user would prefer. To have someone who actually uses the system available to answer that question would be quite valuable.

There is an interesting discussion about the documentation that a project should look to supply - this is often something that we neglect so it was interesting to see explicit ideas on what should be provided being stated. It described the normal ideas such as the source code, architecture diagrams and so on, but one thing which I hadn’t considered as documentation was design diagrams showing the way the system has evolved. We often sketch out designs on whiteboards but rarely capture the evolution of them. It’s certainly an idea to keep in mind.

I liked the case studies at the end of the book which detailed some experiences teams have had using the Crystal Clear approach. The most interesting part for me was looking at the individual experiences that each person on the team had. The ideas expressed weren’t new to me but it was interesting that they were so similar despite the project being described being so different to the ones I have worked on.