Book Review: Lean Software Development
My Rating: 7 / 10
On the positive side, the book is a good discussion of how the principles of Lean Manufacturing apply to Software Development. The authors explain why the usual metaphor of software as manufacturing is not quite right and why the metaphor of Lean Manufacturing is something we can learn from and apply fairly easily to application development.
The authors demonstrate it has been a mistake to think of software development as being roughly analogous to manufacturing and that developing custom software is not like assembling cars. Along those lines software development is closer to product development and principles that work well in product design have a more straightforward application in software development.
The book presents 7 principles (Eliminate Waste, Amplify Learning, Decide as Late as Possible, Deliver as Fast as Possible, Empower the Team, Build Integrity In, See the Whole) and each chapter is devoted to one of the principles. I included a brief summary below.
On the flip side, this is not the first book you should read to learn about Agile software development as it assumes you clearly understand the underlying principles and the correlation to manufacturing can sometimes be difficult to relate to.
Example of elements that are considered waste:
- Anything that does not add value;
- Partially done work such as code that is not yet integrated;
- Extra processes such as unnecessary paperwork or documentation;
- Extra features that do not bring value;
- Task switching;
- Motion such as trying to find someone to get questions answered;
- Management related activities.
The authors demonstrate that design is a problem-solving process that requires discovering solutions through experimentation. A sequential development model does not usually provide for much feedback which is unfortunate because frequent feedback loops amplify learning.
Conventional wisdom in project management emphasizes compliance to cost estimate and defined schedule at the expense of achieving the overall business goals. Lean Software Development methods add much more control in between steps within the development process and increase feedback between activities as opposed to evaluating the output at the end of the process.
Decide as late as possible
Since people find it difficult to make irrevocable decisions when there is uncertainty present, a Lean Software Development approach recommends to decide on details as late as possible because doing otherwise would close opportunities that would be more suitable to the situation at hand. As such, an adaptive paradigm of delaying decision until uncertainty is reduced usually produces better results than a predictive approach.
Deliver as fast as possible
Deliver as fast as possible is a correlary to decide as late as possible since the faster you can deliver, the longer you can delay decisions. In addition, the authors suggest that the customers’ needs should pull the development efforts rather than have the schedule push the work. When put together, the whole system of software development short iterations is based on customers’ input at the beginning of each iteration.
With this approach, customers write-down description of the required features on index cards while developers estimate the efforts to deliver each feature. The developers then choose which cards they will develop.
Empower the team
The critical factor in motivation is by moving the decisions making power to the lowest possible level in an organization while developing the capacity of those people to make decisions wisely.
People suffer when they lack purpose. Intrinsic motivation comes from the work we do and for pride in workmanship and our ability to help customers. To help the team gain a sense of purpose, start with a clear and compelling purpose and be sure the purpose is achievable given the team access to customers then let the team make its own commitments. In this context, the management role is to run interference from skeptics away from the team.
Do not forget to deliver customer value while ensuring that systems components work together as a whole.
The proposed mechanisms documented in the book are:
- Running tests assume that the code is written;
- Don’t write more documentation, write more code;
- Don’t gather more requirements, show more progress by delivering components;
- Do work for an immediate real customer;
- Prototypes synchronize efforts towards a well understood short-term goal;
- Iteration results in a full working portion of the final product;
- Feature means to deliver meaningful business value;
- High priority features should be developed first to add value early;
- Development team only accept the amount of work for an iteration they can compete;
- Deliver on commitments;
- Teams need organizational support to achieve their objectives;
- Customers don’t know what they want at the beginning of the project;
- Deliver on top priorities to build credibility and trust;
- Develop the ability to respond to changing needs;
- Frequent builds to ensure components will integrate well and allow for testing.
In my opinion, the fundamental learning behind the book are:
- That it is critical to add value throughout the development process and not have to wait until the end of development;
- Empower your team members so they get the autonomy and authority to determine the right steps to deliver quality outputs;
- Ensure continuous learning in order to ensure innovation and improvement of the existing process.
As with other major changes, successfully implementing a lean software development approach requires change in the organizational habits and the underlying culture.