About Mary Poppendieck:: Mary is a former programmer and IT manager turned Lean Software Development Evangelist, Author and Trainer. Mary, with her husband Tom, is the author of the award winning books Lean Software Development: An Agile Toolkit
Q. What does the term Lean software development mean to you?
Lean software development is applying lean principles to software development.
Q. What level of improvement have you seen from teams transitioning from traditional waterfall software development models to Lean software development models?
I never even heard of the word waterfall until 1998 when I retired from my job at 3M and got involved in my first government software project – which was “waterfall and proud of it”. It was also pretty much of a disaster. So it’s hard for me to think of “waterfall” as traditional. And in fact, I haven’t seen many waterfall models in action – except for that one I ran into in 1998. So I’m not quite sure how to answer your question. I can say that when organizations start using a disciplined test-driven development process combined with short iterations, they often report 30-50% defect reduction and dramatic productivity improvements. But productivity is tricky to measure – so I won’t put a number on that.
Q. To date within the IT community we have applied Lean to the software development process to gain efficiencies. Do you feel that there is an opportunity to use this knowledge to work with our business partners to apply Lean principles to improve the processes that our applications automate?
I find it often works the other way around. People with lean operational processes need software to support the process and urge the software development group to become lean so as to provide them with better support. In fact, I did a workshop at a bank which processed mortgage papers. The paper handling process was vastly improved through lean techniques, but the teams were unable to get software changes they needed – even though their process was driven by workflow software. In another case, an insurance company, the IT department was unable to support business teams. At both companies, I suggested that a couple of developers simply be assigned to each lean team to make the software changes the team needed in a Just-in-Time manner.
Q. Hand-offs are viewed as being wasteful. There is often a hand-off from business to IT but there is also a common hand-off from IT to operations and support. Do you have any suggestions on how this second hand-off can be handled?
Both handoffs are equally harmful. The very words “business” and “IT” indicate that people think of IT as somehow being separate from “the business”. This is wrong. IT should be a part of the business. There should be no such thing as an IT project – there should only be business initiatives which have IT aspects handled by the IT team member of the business team. Similarly, if operations and support people are not involved in the design and development of software, we are missing huge opportunities for learning and improvement. We can learn vast amounts about our ultimate customers from support people. Only when we work hand-in-hand with operations to find root causes of those tricky system hang-ups caused by our poor coding practices will we begin to build more robust system.
Note From Rich :: I recently had a conversation with Martin Fowler where he expressed a very similar sentiment regarding decentralizing IT. I’ve been an advocate of this for a while, in fact I recently beat up some of my colleagues for heavily using the terms ‘business’ and ‘IT’, something that I find really unproductive in encouraging the right thinking and team mentality. The big challenge I find here are the accountants that have made their way into IT who believe centralizing IT and reducing all variation to generate economies of scales is the only way forward. I often find that Enterprise Architects are also a real challenge in this space; pragmatic Enterprise Architects are worth their weight in gold.
Q. Traditional contracts often encourage the wrong behaviors. Fixed price contracts encourage the client to never let the vendor leave and time and materials contracts encourage the vendor to never finish. What innovations do you see taking place in this area to resolve this problem?
I often ask in my classes how many people have ever been in this situation: You are working for a company that is a customer of your employer. You know that if you do one thing, it will be good for your customer, but if you do the opposite it will be better for your own company. Invariably, many hands go up – this conflict of interest situation is amazingly common.
The thing to recognize that all contract structures must first and foremost deal with this conflict of interest by aligning the interests of both parties so that the good of each individual party is the same as the good of the joint venture. As you point out, neither fixed price nor time-and-materials contracts fit this standard. A better approach is target cost contracts, which establish a target that both companies commit to. Workers on both sides are expected to work together to meet the goal. If the goal is not met neither company benefits – instead, negotiations are re-opened or a change of pay level kicks in to be sure that no one wins in this situation.
Note From Rich :: I think that developing innovative contract models could be the single biggest area of opportunity in the IT industry today. If you’re doing interesting things in this area then please share!
Q. Where do you think Lean software development will go next?
Right now, even the best companies out there seem to be struggling with thrashing; they are overloaded with work and not able to arbitrate between multiple competing priorities. I think we have to re-think the way we schedule work in our organizations and move from what is very much a push system to a pull system. We have first of all to figure out what this means in various contexts and then experiment with new ways apply queuing theory to various development environments.
Note From Rich :: You can read more about push systems, pull systems and their relationship to the software delivery lifecycle in my previous posts here: Push Systems, Pull Systems and From Push to Pull. For some history take a look at my post on Lean Software Development.
