book critique: lean software development an agile toolkit

I picked this one up coming out of the agile dev practices conference in Orlando. The speakers I meet, Jeff Patton, Rob Myers, Jean Tabaka, James Shore and some folks from Rally Dev were jazzed to hear the key note of the book’s author Mary Poppendieck. Mary’s keynote pitch, stuffed with an abundance of historical comparisons, focused on agile’s step onto the main stage. I’d have to agree, I met many people there from companies such as State Farm, Lockheed Martin, and UPS. Agile has now has the potential to fail just like any other management philosophy before it.

A relatively quick read, the book is divided into 8 chapters:

  1. Eliminate Waste
  2. Amplify Learning
  3. Decide as Late as Possible
  4. Deliver as Fast as Possible
  5. Empower the Team
  6. Build Integrity In
  7. See the Whole
  8. Instructions and Warranty

Overall I’d put the value of the book at a 9 out of 10. It highlights principles that manufacturing has honed but the young knowledge based software industry sometimes forgets. While some people might call these principles obvious the book has provided me with a richer vocabulary for describing some practices I have already been using. I’ll pontificate about just one and let you read the rest since the source can always explain it better.

In Jean Tabaka’s Collaboration Explained: Facilitation Skills for Software Project Leaders (The Agile Software Development Series) workshop we discussed how to facilitate from divergent viewpoints through to convergence. These skills are extremely important if you are going to attempt the practice of set-based design.

In set-based development, communication is about constraints, not choices. This turns out to be a very powerful form of communication, requiring significantly less data to convey far more information.

You probably use this technique already. If you have a tight calendar then you know how to setup meetings in this fashion. Rather than asking the other person when they would like to meet or giving them one option you let them know you can meet Friday between 1-2 or Monday between 3-4. Always give them a face-saving way out, like “if these times do not work please let me know a better time within the next week.” This decision making process is much more efficient than asking open ended questions like, when can we meet? It usually only requires 1-2 rounds of negotiation rather than 3-4.

You might be wondering, what does this have to do with my current project? Well if your team struggles to move to convergence, and/or your development lifecycle is too long, then your set-based process will be in jeopardy as the divergence begins to affect product integrity. Communication about which state you are in convergence or divergence on any particular aspect of your development must be clearly stated.

If your attempting to “go agile”, read this book and then pass it on to your boss. And don’t forget to buy it through the link above :)

No Comments yet »

RSS feed for comments on this post. TrackBack URI

Leave a comment

XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>

Powered by WordPress with GimpStyle Theme design by Horacio Bella.
Entries and comments feeds. Valid XHTML and CSS.