While I’m at the XP2010 in Trondheim, I try to update my blog with some of the interesting sessions I attend. This is a write-up from Mary Poppendieck’s Lean in a Nutshell tutorial.

Mary Poppendieck gave a very brief introduction in 90 minutes to Lean. I took a bunch of notes during her session. Mary started to explain what Lean is. Lean Software Development is about delivering more and more value for less and less effort in the shortest practical timeframe with the highest possible quality. (Please notice the use of the words practical as opposed to possible.)

Mary presented five principles of Lean Software Development.

1. Customer Focus

If it doesn’t add value, it’s waste.

1. Technical Excellence

Don’t test quality in; build it in.

1. Level Workflow

Manage workflow instead of schedules.

1. Relentless Improvements
2. Respect for people

Mary explained that it’s crucial for teams to build the right thing. The team needs to be engaged in getting to know the business. She explained that technical success is a business failure. In order to achieve customer focus, the team needs Ethnography (go and see), Inspiraiton (Uncover Causes of Stress (for the user)), Ideation (Model and Discuss), and Build to Think (Minimum Viable Products). Mary explains that too much gets lost in the translation on more traditional teams. The same holds if you don’t get real customer involvement. Therefore feedback loops from the customer are essential. Mary sees waste happening for time, effort, space (uncommon for software), and money. Instead the team should focus on the value provided to the customer – that is anyone who pays for the software, uses the software, supports the software, or derives further value from the product. Poppendieck pleads to stop making customers unhappy. Essentially there are two demands from customers. They are demanding value, and they are demanding proper failure handling. In the rare cases that the software does not work, the customer wants to get further problems by non-working software, i.e. crashes and data-loss.

Handovers as seen on most traditional teams are waste. A handover happens whenever we separate responsibility (what to do?), knowledge (How to do it?), Action (Do it!), and Feedback (Learn from results). Poppendieck raises the claim for truly cross-functional teams. In order to avoid handovers from the building part of the software development to the using part that provides feedback, the customer needs to be somehow part of the team. Of course, this is not always possible, but by having the customer or operations department separated from the team does not mean that they can’t talk to each other. The same holds of course even for traditional teams, where programmers and testers get separated. Just by having each other working separately does not mean that they are not allowed to talk to each other.

Work in process is waste. Work in process is essentially hiding risk and opportunity. Poppendieck claims that a to do list such as a product backlog is essentially waste. Poppendieck explains this fact by taking a closer look on the flow of. The development project develops software at a capacity, which we often call th velocity. Now, when the input flow in terms of user stories and product backlog items gets larger, then there is a need for a work-in-process limit on the input to the development process. The output capacity determines the amount of input into the project. Everything that exceeds the output capacity on the input flow, is essentially wishful thinking, and never implemented. Since I recently read about the Yes/No-Medallion in Jerry Weinberg’s More Secrets of Consulting I directly drew the connection to learning how to say no to a new aspiring backlog item. In Poppendieck’s words, “… in practice you actually do” say no when you drop the scope after maybe nine months of product development.

Task Switching is waste. (I won’t elaborate this. There are great visual examples showing this on the web and in the books.)

Failure to Learn is waste. Poppendieck denoted some points that conclude from failure. Governance by Variance from Plan is one example. Making Decisions apart from the work, another. Reshuffling teams in order to optimize utilization in the company is another. The goal should be throughput, rather than utilization.

This leads to the second principle in Lean Software Development, Technical Excellence. Personally, I was referring to the history from the Software Craftsmanship movement here. Poppendieck explained how the initial ideas around Waterfall were to no longer find problems in later stages of the process. Rather than “hardening” the product in the denoted testing phases, the original work did not expect to find problems through the work that had been put into the software until then. In practice, though, we find between 10% and 50% of the overall development effort is put into finding problems in some downstream activity.

Poppendieck explains further which parts of the Agile methodologies help to prevent problems. Code reveals its intent. Design and Code are reviewed. Code is immediately tested with automated tests. The development line is stopped if one of these tests fails. Continuous, nested integration is done, and escaped defects are analyzed and the feedback is provided into the process. Poppendieck explains a defect injection process. Instead of building the specification and expecting the test and the code to derive from it, she raises the claim to build the specification alongside with the tests. Whenever this is done, the code is ready to be written. In her slides she refers to the term “ready, ready” in opposition to the wide-used “done, done” term.

With reference to Lisa Crispin & Janet Gregory’s Agile Testing book, she explains the Agile Testing quadrants from Brian Marick with reference to the value and failure demands from the customer. Technical Design is specified by xUnit tests, Product Design is specified by Acceptance Tests, and Interaction Design is specified by User Interface tests. On the failure demand side she lists Stress Tests for Design failures, Exploratory Testing fro Product Design failures, and Usability tests for Interaction Design failures.

Poppendieck continues to explain where expertise comes from. Roughly 10 years (that is 10.000 hours) of deliberate practice is the answer to that question. She explains how to push the limits. In order to get the full potential, the team needs a teacher or a coach, feedback, challenges and perseverance. My notes and memories are a bit weak on this one.

Poppendieck elaborates level workflow on the example of the construction of the Empire State building. It was build as a fixed-price project, right in the middle of a recession within roughly a single year. The architects focussed on the flow of the stories piling up, and the construction material flowing into the construction system, rather than on the task of putting a brick onto another.

The overall architecture was decoupled to the degree of construction items. Building the Empire State was therefore decoupled in its pieces to have no dependencies during construction. the project was finished actually before schedule. Poppendieck continues to explain that a cash flow thinking needs to be applied. Rather than derive the schedule from the design, the design should be aligned to the schedule. Design the system to meet the systemic constraints, rather than derive the constraints form the design. In the latter case the schedule will be slipped, rather than the scope of the system to be build. By decoupling workflows, and breaking dependencies, the system gets optimized in regards to the cycle time. The velocity of an Agile is essentially the capacity of the team.

Finally, Poppendieck explains how to reach improvements. First, you visualize perfection. Then you check your current situation in order to get a firsthand grasp of the situation. By comparing the two you derive what step to reach next towards your perfect goal (from the first step). That’s the next target to meet. now, all you need to do is to understand which obstacles lay in your way to that target – if there were not obstacles you would already be there – and seek ways to overcome these obstacles.

Good people and good systems lead to good software. Poppendieck finishes her session off with reference to a process. Supplies from upstream activities are defined by the supplying group as done, done, but still need to verified fro being ready, ready before feeding them into the process. After the process, the team defines the work items as done, done. On the feedback level, the team asks downstream activities for feedback, and provides their own feedback – in regard to whether the pieces supplied were ready, ready – to the upstream team. Development on a new item should just be started when it is ready to start with it.

Overall, Mary’s tutorial was very great, but filled with lots of information. She will be giving the fifth and final part on respecting people in her keynote tomorrow, so she left that part out by intention.