5 Things I Learned from Lean

On April 7th, Scott Bellware gave a presentation at Agile Austin entitled "5 Things I Learned from Lean". Scott had worked on a rewrite project that failed. He looked to lean to identify the issues that led to the failure / how he could prevent similar failures in the future. This presentation was focused on those lessons learned.

Scott started by going into an overview on agile vs. lean. Scott's view on the key principles of agile: coordination and collaboration, customer engagement, delivering early and often, iterative development, quality and craftmanship. The last two have really become in focus recently thanks to the efforts of Uncle Bob Martin and others. For lean, Scott's view of the principles: add nothing but value (eliminate waste), center on people who add value, flow value from demand (delay commitment) and optimize across the organization.

Scott views the most important thing from lean is its focus on productivity (i.e., producing). Everything is a productivity problem. The seven wastes (over production (extra features), inventory (requirements), extra processing, motion (finding info), defects, waiting and transportation (hand offs)) are key areas that detract from productivity.

Lesson 1 was that iterations cause waste. In Scott's view, they cause slacking and cramming. Instead, you should pull things from the step in front of you and help if those on either side of you get overloaded. Rhythm and flow are key. The quest for flow uncovers constraints. Slack is necessary (and good) since it provides time to adjust. My point of view on this is that iterations are a great starting point. They force you to put a cap on how big things can be. They help to establish the rhythm. As you become better and better at agile, story size decreases and you focus more on flow.

Lesson 2 was rework: you can't afford it. Both BDUF (Big Design Up Front) and emergant design can cause rework issues. You need a compromise: just enough design. You can do some of this before the iteration to make sure you have enough runway. Everything in development is a form of design (not just diagramming). Even writing a single line of code. The key to sustainable development is to focus on sound design. Design flaws spread like viruses (and only your most experienced folks will be able to see them). Design flaws kill your productivity. The best way to prevent them is to focus on quality from the start. Testing has to be done as development is done (with people able to move between the two). Quick feedback is key.

Lesson 3 was that your organization should be hierarchical and flat. Scott views self organization as the Achille's heel of agile. Self organization (in terms of deciding how to best accomplish the work) is good. But you have to be careful that it doesn't lead to self direction (i.e., management / leadership serves a purpose). "Sometimes you just have to tell people what to do." Leadership needs to be able to get their hands dirty. You shouldn't lose your technical skills as you move up. Toyota's chief engineer model has a lot to offer. One person who pulls it all together who could do everything (i.e., understands the process end to end). In the US, we tend to have specialists so we compromise by separating out this role. This is a deficiency and should be corrected over time.

Lesson 4 was continuous improvement. Retrospectives can be harmful in that they batch up improvement. If the opportunity arises, you should address an issue when you see it.

Lesson 5 was holistic (i.e,. systemic) thinking. Changing one lever affects many other things. Lean has brought this front and center. It is more implicit in agile. Organizational knowledge is very valuable. The goal should be to retain people so that this isn't lost.

Scott's bottom line was to listen to your instincts. As always, Scott tried to make people think about things in a different way. I think he succeeded.