Image taken from: http://www.leansoftwareinstitute.com/images/img_bigpicture.jpgIf you read the Poppendieck's book called, "Lean Software Development : An Agile Toolkit", you probably liked it because it managed to get the essence out of agile practices. So, what are these core principles? Well, most of you already know the phrase, "Inspect and Adapt". Now, you also know a bunch of specifications that facilitate this, for an instance, Scrum, XP etc.
Reading the book, I had a realization that, its good to talk using concrete facts as much as possible. So, doing a value stream mapping practice is worth than spending hours in discussing the process optimization. The same holds true with the Profit and Loss statement when figuring out which option to take - quality compromise, deadline shifting or feature squeezing. Being able to answer why questions, at least 5 in a succession, is something very critical - then you know the hidden junk thats causing the bad smell. I highly recommend reading this book, especially to people who are doing agile for a year or so and thinking about getting better at it.
I also had the opportunity to attend a speech by the authors on this Monday. The speech was a great one. But for my readers, I will write about an example from the speech.
Once Mary and Tom visited a company that creates hardware and software tools for real time video conferencing. They met the Boss there and asked what they were doing. The answer was, "We are working to improve the system so that our customers get better video conferencing solution for their businesses." They went to a section where people were working on hardware and asked one what he was doing. The person replied, "I am creating a component for the system, so that our customers can do better video conferencing". Then they went to a software developer and asked what she was doing. She replied, "I am working to improve a part of the software so that our customers can do better video conferencing".... (I am sure Mary used better words than mine and it was really interesting to hear the story in her voice :-))
So, the fact that she wanted to capture using this example is, although each individual is involved in a specific task, they envision the bigger picture from the customers' standpoint. This is really important. Because as soon as you start seeing the views from the customers' perspective, you will produce less bugs. In the book they mentioned, most software bugs are not results of coding/design errors, rather they arise from the difference in views among customers and developers.
Overall, it was a pleasure to read the book, although this blog post may not reflect all of my respect and take home from the book :-(
