Lean Software Development: An Agile Toolkit
by Mary Poppendieck and Tom Poppendieck
with Forewords by Jim Highsmith and Ken Schwaber
A review of sorts
The book defines a number of tools to assist you in implementing an agile approach to software development and uses a number of studies from both software development and manufacturing to get the points across.
On the whole the book is fairly easy to read and presents the ideas clearly with examples. However, in some areas I felt that the examples were too geared towards the manufacturing industry and not towards software development. This is, in itself, somewhat surprising as the authors have pointed out that you shouldn’t try and directly take a idea from one industry and apply it to software development without some element of thought. From the final page of the book comes a warranty that contains: “This warranty is invalid if practices are transferred directly from other discipline or domains without thinking, or if the principles of empower the team and build integrity in are ignored.” (p186)
The warranty quote above highlights two of the three areas that I feel are the most important. The other area was the “Contracts” tool. The remainder of this text are the things that I found most interesting, or provided one of those “a-ha!” moments as a realisation of how a new idea might make things work better occurred. Some of the things may seem obvious, but a gentle reminder of them is never bad.
Empowering the team means that everyone has a clearer idea of what is going on and, most importantly, why. It means that the team have access to the information to do their job rather than be hidden away from the client and given a point-by-point specification to work through. While it is easy to work through a point-by-point specification it does not allow the developer to highlight potential errors or conflicts if they don’t understand why the specification says what it does. There may be some missing information or an assumption may be wrong, or common sense doesn’t turn out to be as common as once thought.
Another point raised by the chapter on empowering the team was that “software development cannot be successful without disciplined, motivated people”. Motivation is not only the key to keeping good employees, but also for keeping them energised. The authors give the example of 3M who, for over 75 years, have allowed the “entrepreneurial spirit to flourish” by permitting “small, self-organising groups that become passionate about a possibility and are allowed to make it a reality… Scientists are expected to spend 15% of their time on projects of their own choosing” (p104). Many of 3M’s new product lines comes from this. In the software development world the equivalent is Google, who permit their developers to experiment with new ideas which Google then bring to the market place. This is very successful. A current example is Google Suggestion.
Going hand-in-hand with motivation is purpose. People need to have a purpose, a set of goals to work towards. This manifests itself in understanding why the software is needed. If this sense of purpose is to prevail then beware of the sceptics. “Nothing kills a purpose faster than someone who knows it can’t be done and has plenty of good reasons why” (p106)
Building integrity in ensures that the customer stays happy (perceived integrity) because the software appears to work as expected without errors or problems and it also ensures that the developers stay happy (conceptual integrity) that the code base stays well ordered and easy to maintain.
For a software application to have perceived integrity (p127-134) it needs to be usable, reliable, economical, and it must function as expected. In terms of developing an application in this way domain models are built, which are models of the software that the customer understands. The authors go on to say that eventually the models created will fall into disuse, and that they should not be maintained just because it “seems like a good idea”
In terms of conceptual integrity (p135-149), the “system’s central concepts work together as a smooth, cohesive whole.” Specifically “particular attention should be paid to the presentation layer, since conceptual integrity in the interface design is a primary driver of perceived integrity”. In order to maintain the conceptual integrity the system must be simple (many software patterns aim to bring simplicity to complex designs), clear (so that everyone in the software development team can understand), suitable (so that it fits its purpose), D.R.Y (Don’t Repeat Yourself – removing duplication means that if something has to be changed it only needs changed in one place), with no extra features (“Anticipating the future is usually futile and consumes resources”)
Finally there is the Contracts section (p161-177). For me, this was the key to the whole book. For many areas in the book I was left wondering how this would ever work in an organisation that exists to service clients. For many of the concepts I could see how they could gain a hold inside a software product company, but not a software services company. They gave examples of the traditional time-and-materials and fixed-price contracts and how they don’t really work well. Then they presented three examples of contracts that would fit into the Agile development process.
NOTE: This was rescued from the Googe Cache. The original date was Saturday, 11th December, 2004.
lean
The Blog of Colin Mackay 