The Poppendiecks Speak: Two-Pizza Teams and the Software Development Experience
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The authors of Implementing Lean Software Development and the forthcoming Leading Lean Software Development, Mary Poppendieck and Tom Poppendieck will be speaking at Agile 2009. Matt Heusser took the opportunity to sit down with Mary and Tom before their conference presentation to discuss some of the issues in software development today – and what we can do about them.
Matt Heusser: Can you explain the Lean software philosophy while standing on one foot?
Tom: Do nothing that doesn't add value and respect people. I heard a great quote from John Shook: “GM is in business to make money; Toyota makes money to stay in business.” Organizations make different decisions when they give as much weight to long-term survival as to short term profit.
Mary: Stop the line culture, aggressive focus on improvement. If you want to survive in an environment with discontinuous events that you cannot forecast, then you need to be able to respond to those events. Get all workers deeply involved in analyzing feedback from the market and rapidly figuring out how to act on that feedback.
Tom: Build a learning organization in which everyone uses systematic elimination of waste and systematic problem solving in continuous cycles of experiments and reflection to deeply understand their work through direct observation of the process and testing of hypotheses to build a high level of agreement on what your organization needs to deliver and how it can most effectively do its work.
Matt: You are best known for Lean Software Development, which came out of manufacturing. How were you initially exposed to Lean?
Mary: I started out as a programmer. In the early 1980s, I became a systems manager in a manufacturing plant. We were experiencing serious competition from Japan, and we discovered that they were doing something different. They called it “Just-in-Time,” which later came to be called “Lean.” We got a book about how the Toyota Production System worked, and tried it in our plant. Over time, we cut our costs in half.
Tom: I was in an engineering computing support organization for an avionics manufacturer when it moved toward Lean in the factory. I led an effort to speed up the flow of design information to the factory by a factor of four by bridging the whitespace between organizational units.
Matt: What did you actually do to cut costs in half?
Mary: We did three things. First, 3M used the Crosby quality program, which was a program that started at the top of the company and moved downward. The management team at the plant had a three-day course led by our plant manager, who had taken the same class with his colleagues at corporate headquarters. The class gave us a common language and attitude about rework, the cost of quality, not tolerating defects. The second thing that cut costs was an aggressive program to understand how to improve our process control using statistical analysis.
Third, we decided to try pull scheduling. This meant that we would no longer use computers to schedule each workstation; we would only schedule the pack-out station. We would keep a small shelf of in-process inventory between each workstation. Then when pack-out took some inventory off of its shelf to package and ship, the next workstation downstream would replenish the shelf. This workstation, in turn, used inventory from its small supply shelf, and the next workstation downstream would replenish this supply shelf. This would work backward throughput the the plant.
Well, that was the theory. But would it work in practice? We didn’t know, and there were no consultants at the time, so we had to figure it out for ourselves. We created a simulation of the plant. We drew the workstations on a big sheet of brown paper and used coffee cups to represent in-process inventory. Everyone in the plant – from managers to production workers – worked through the simulation and figured out how to make things work. Then the production workers designed how things would work in their area.
When we finally switched over to the new pull system, it worked very well. Since the production workers designed it, they knew exactly how it was supposed to work, and could deal with all the problems that cropped up.
Tom: Every organization worked closely with its immediate customers to understand exactly what the customers needed to do their job as well as possible with as little waste as possible and worked out ways to deliver drawings and other design information at the right time and in the right format so it could be used immediately without further transformation or reworking, often via fully automated processes.
Matt: How did that lead to Lean Software Development?
Mary: I never heard the term “waterfall” while I was working at 3M. We always had developers understand their customers and test every bit of code as they wrote it. The first time I heard about this thing called “waterfall,” it was prescribed by a contract for the State of Minnesota, and I couldn’t figure out how it could possibly work. Actually, it didn’t work very well at all, and I decided it was a rather strange way to develop software. So I decided to write a book, taking ideas from Lean Manufacturing and applying them to software development.
Matt: How do you respond to someone who wants to eliminate waste by cutting out team discussions or coffee breaks?
Mary: That’s taking the word “lean” and using in exactly the opposite way from its meaning in the Lean Manufacturing and Lean Product Development world. One of the big principles of Lean is to “optimize the whole.” Making shortsighted cuts and calling it “lean” is not Lean at all.
Tom: Product development is fundamentally about learning, about deeply understanding a problem and collaboratively creating an effective solution, not about producing drawings, documents, or cutting code. Discussion is one of the stronger techniques to pursue and share learning. The view that team discussion or coffee breaks are waste sees development as a manufacturing process with code as the primary output rather than as a learning process in which the code is simply the repository of part of what the team has learned.
Matt: How does that impact the way we develop software? What should we do differently?
Mary: How are you doing it today? What you do differently depends on how you do things today and how that’s working for you. Lean is a philosophy that helps you figure out how to solve your specific problems: how to deliver more value.
Tom: The first thing to do is to realize that we are not developing software. We are doing something larger and software is just part of the solution. Optimizing software damages the overall return. Development work requires truly cross-functional teams with end-to-end capability and responsibility.
Mary: We often lack feedback loops from the people who will benefit from the solution. We need to figure out how to get feedback all the way from customers to developers – how to make that feedback loop work.
Matt: How is Lean different than Agile?
Mary: Lean provides the theory behind Agile practices. Lean is a set of principles, ways of thinking, from which Agile practices are derived.
There are some differences. One of them is the lean focus on the whole product versus the Agile focus on software development. Too often, developers are separated from their customers in a way that cuts off feedback; for example, a Product Owner might tell the team what to do. We would like to see the development team involved in helping to figure that what adds real value for customers.
Another difference is the Lean focus on the importance of good leaders as opposed to the Agile focus on self-organizing teams. Respect for people means providing people with the leadership to be successful.
Matt: So we understand lean a little bit now. Can you tell me about the books you've written on the subject - what makes them different?
Mary: The first book we wrote in 2003 was “Lean Software Development.” It explains why lean thinking makes sense in software development. The second book, written in 2006, was Implementing Lean Software Development. It contains what we learned in three years about how to go about implementing Lean principles. The third book, which we just completed, is “Leading Lean Software Development.” It’s about the way leaders frame the way they look at system development, and about leadership roles. We wrote it because many leaders were looking for some guidance on Lean and Agile implementations. We don’t provide answers in this book, but we do talk about how leaders might think about the system development process.
Matt: How would you respond to someone who claims that Lean is from manufacturing, and thus inappropriate for software development, which is knowledge work?
Mary: Well, Lean works for banking, which is a service business. Svenska Handelsbanken is a bank in Sweden that has been using Lean principles for 25 years. It puts the bank in a position to deal with discontinuous change in the financial markets by expecting local teams to make independent decisions. By having many individual teams seeing what opportunities are out there and responding, the bank stays ahead of changes in the markets.
Jeff Bezos, CEO of Amazon.com, also believes in small, independent teams; he calls them two-pizza teams. A two-pizza team is the number of people that can be fed with two pizzas. Amazon’s cloud is a service-oriented architecture in which each service is owned by a two-pizza team. The team is responsible for the service from cradle to grave: determining what is needed, development, operations, support – everything.
Toyota is the same; teams of six to eight people, with good mentoring from their manager, get work done better and faster.
An underlying concept of Lean is that if you can't create small independent-thinking teams, you can't respond rapidly in the face of continuous change. So you need to create a governance structure that allows the teams to make the right decisions and makes it possible for them to focus on the outcomes of the ultimate customer. Our book is for leaders trying to figure out how to get there.
Matt: Is this sort of team-derived work able to pass audits and standards (such as Sarbanes Oxley)?
Mary: Absolutely. We have had Sarbanes Oxley compliance experts attend our courses and they always come to the conclusion that when done well, Lean processes will be compliant. Here’s why: When you automate requirements and make them testable, then automate those tests, you have the tractability and accountability demanded by regulators.
Matt: Six Sigma is a measurement and process improvement standard for manufacturing related to Lean. Do you think it has a place in software development?
Mary: I suppose it depends on what you mean. To me, Six Sigma is a bunch of tools. They are good tools. Theoretically, they are implementation agnostic. They are not a whole program of how you should do things.
When thought of as a set of tools, Six Sigma has a tendency of not getting at the underlying strategy of how things ought to happen. There's nothing inherently wrong with Six Sigma, it's just that people think it's the answers to the world’s problems. It isn't. It's a set of interesting tools that anyone doing continuous improvement would do well to use.
Tom: The typical implementation of a Six Sigma program vests responsibility for improvements in black-belts who are not part of the organization’s leadership structure. Toyota and other Lean organizations vest this responsibility in every level of its leadership team and mentor every level of leader in the appropriate tools from the Six Sigma and Lean toolboxes.
Matt: What are you going to be speaking about at Agile 2009?
Mary: I have two talks. One is “Deliberate Practice in Software Development,” which is about how important it is to constantly develop skill in software development, and what kinds of things have to be in place for that to happen. The other, “Workflow is Orthogonal to Schedule,” is about various kinds of workflow – iterations and kanban systems in particular – and how they are not the same thing as scheduling.
Tom: Gabrielle Benefield, Henrik Kniberg, and I are presenting “Seeing and Solving Problems” on the main stage, about the theory and practice of disciplined problem solving. We will illustrate and guide attendees through the PDCA (Plan-Do-Check-Act) approach to learning.
Matt: A lot of teams struggle with adopting Agile concepts; I believe the statistic is that 75% of teams fail to achieve what they had hoped. Do you agree? If so, what is the single largest barrier, and what should we be doing about it?
Mary: I don’t think the issue of success or failure lies with the Agile practice being used. I think the real issue is whether or not people are looking at a fundamental change in the way they think about delivering value. In many cases, they are simply changing software processes but keeping the same underlying philosophy. The most effective companies are often not adopting labels like Scrum or XP [Extreme Programming] or Lean, but instead figuring out for themselves what the best way is to improve the value delivered to customers over time.
Trying to save money or get efficient will have limited effectiveness. Changing the way we work, and our end goals, will have a larger impact. In order to survive constant change in the market, we have to create small, well-led teams that are able to rapidly adapt to reality and continue to deliver the best customer outcomes.
Matt: Imagine you are approached by a traditional team that has never heard of Lean or Agile or scrum. They ask for one technique to start on Monday - just one - to improve velocity or code quality. What do you recommend as a quick win?
Tom: Short, stable iterations with customer feedback every iteration.
Matt: Similar question: You are approached by a well-functioning Agile team doing book XP that has never heard of Lean. What should they try first?
Mary: Try to put in constant improvement. Try to get closer to the customers. Look at the big picture, not just software.
Tom: Stop depending only on your product owners/on-site customer. Go and see the customers problems yourself and participate in the decisions about the overall solution customers will value.
Matt: What kind of consulting do you do?
Mary: We don't think about what we do as consulting. We teach people a way of thinking. We work with management teams - who might call it consulting - to get them to think differently about how they view work. We typically create tailored courses for individual companies.