Learning Lean, Part IV

Here are some of the items I enjoyed most from the most recent installment of Alan Shalloway's online course on Lean: An Introduction to Lean Software Development. See this link for notes from previous sessions.

• Focus first on the time between efforts, not the effort of actually doing things. This is often the easiest place to remove waste.
• Instead of the often heard "Do more with less", it should perhaps be "Do less with more". In other words, focus the organization on building the most important things (and only those).
• Defer commitment. We often arbitrarily constrain the solution by committing too early. Only constrain when necessary. Make decisions as late as reasonable to do so. Over analyzing too early is an example of prematurely committing your time.
• Decide up front when to decide. This helps to mitigate the risk of making the decision too early or too late.
• When dealing with complexity, use Scott Bain's Magic Card: Encapsulate it. Hide complexity so that the rest of the code is unaware and changes can be done in one place. This is an example of deferring commitment.
• The purpose of architecture is to minimize the effect of changes. Creating an architecture too soon risks over-building the architecture (leading to complexity) and trusting the architecture over the code (which is the thing that actually gets maintained / costs you down the road).
• GM and Ford adopted most of the lean practices, but neglected to respect people. Don't waste people's work or ask them to do useless things, instead train them, treasure their input and help them to do the best job that they can. Pride is the most important compensation you can give - Tom Poppendieck at Agile 2006.
• The process is what the team uses to achieve its goals, not vice versa. This allows them to identify and use what works best in their context. In other words, process is not about governance, but about facilitating the team. There is not one best way.
• Kaizen: Bring people together, give them a challenge, brainstorm solutions, present recommendations, make an on the spot yes/no decision, and immediately implement. Kaizen events should be focused on the big picture and should be acted upon. Make sure that the right people are involved to make it happen.
• Software development is mostly about discovering what the customer needs. Don't build what you don't need. Determine this by getting feedback early and often.
• Some common myths / false paths: optimize by optimizing the parts, early specification reduces waste, get it right the first time, haste makes waste, decisiveness is a virtue, there is one best way, and predictions create predictability.
• Instead follow the lean principles: Optimize the whole, eliminate waste, build quality in, deliver fast, defer commitment, respect people and create knowledge.
• Difficult budget processes encourage people to ask for more than they need.
• Some other anti patterns (abbreviated from Alan's original list): too many projects, not relating the project back to business value, stove piping the organization, big budgets resulting in big projects, making decisions too early, unavailable customer, encouraging customers to specify what they might need, too much analysis up front, committing to functionality over code quality, no unit tests, not refactoring, looking for bugs instead of improving the process, batching to "optimize", and not automating all tests.
• Optimize the output of the organization, not the output of the team.

Note: for others attending the course, this is from Alan's fifth session.