A little more than a month ago, at CodeMash, I had the pleasure of spending quite a bit of time with Mary & Tom Poppendieck discussing software development, agile methods, the business value of software, and the general state of the industry. I came away very impressed by the breadth and depth of their knowledge, and their willingness to share it. Our organization can learn a lot from their strategy of software development. Dianne and I were impressed enough that we got a copy of each of their books. I started with Lean Software Development: An Agile Approach.
This is a fantastic book if you are trying to convince a resistant organization to go agile. Mary and Tom discuss 22 tools centered around 7 themes of software development agility. They show the business value of each of these tools. Sometimes it is shorter schedules, sometimes it is higher quality, still other times it is more profit for your business.
In every case, these tools give you the vocabulary, themes, and arguments to make to the business people. For example, when they discuss the tradeoffs between features and time, they build a profit and loss (P & L) model for the project. (Chapter 4) While developers may feel that a new feature request is a bad idea, and marketing may demand it because a major customer wants it, the P & L model will move that discussion forward: The added development time will mean a delay in getting to the market. That delay will mean lost sales. The model even predicts (and yes, I know predictions aren't 100% accurate) how much money will be lost by the delay. Now, the feature vs. time discussion can proceed in a logical manner. And, note that it's not an either / or discussion, if you're doing agile right. If you have delayed decisions to the last responsible moment (Chapter 3) you may find any number of lower priority feature requests that have not been started. These can be dropped in favor of the new requirement.
As a small software consulting company, I found the last item on agile contracts most interesting. Poppendieck's discuss how to build a mutually beneficial contract around shared goals for the customer and the vendor. Whichever line you sign, that discussion is worth reading: They found that a more agile framework supported by an agile contract would enable a supplier to be more profitable while holding down the costs for the customers. Building a contract with some uncertainty is always a challenge, but it's worth that perceived risk.
Lean Software Development is not a cookbook. You won't find directives saying you must have pair programming, standup meetings, test driven development (although all those may be part of a winning agile strategy). Instead, you'll find recommendations on seeing and elminating waste, providing feedback loops throughout your value stream (customers, business managers, developers, testers), making decisions at the last responsible moment, yet delivering interim releases as early and often as possible, and many others. Most importantly, as you try and convince your organization to adopt these methods, you'll find examples, case studies, and other evidence you'll need to convince your stakeholders to adopt these methods.
In closing, to recommend this book, let me just say that Dianne and I are buying copies for all our consultants, and for customers struggling with adopting a winning agile strategy.
All of these projects are Open Source (using the Creative Commons license for content, and the MIT license for code). If you would like to contribute, visit our GitHub Repository. Or, if you have questions, comments, or ideas for improvement, please create an issue for us.