Last week, I invited the readers of shmula to pose questions to Mary 1 and , the authors of Lean Software Development: An Agile Toolkit for Software Development Managers (Paperback), which won the Software Development Productivity Award in 2004 and, the sequel Implementing Lean Software Development: From Concept to Cash (Paperback). Several questions were submitted and, over the next several weeks, I’ll be posting Mary (MBP) and Tom’s (TDP) responses.
Be sure to read our other interviews in our leadership series.
Here are Mary Poppendieck’s other responses to readers’ questions:
- Original Article to Ask Mary Poppendieck Anything
- Mary Poppendieck’s Answers to ALL Readers’ Questions
- Should Lean be Top-down or Bottom-up?
- An Interview with Mary Poppendieck with Pete Abilla
- Mary Poppendieck on the Handoff and Waste
Earlier, Mary and Tom responded to the question of Waste and the Handoff in software development. Today, they respond to two questions from Ursula Rutherford:
Ursula Rutherford said,
November 16, 2007 @ 3:55 am
The term Lean is very little known in the software development and system delivery industries. Do you expect there to be more explicit use of it in the future?
It seems IS people are treading their own path towards quality management and capability maturity without reference to other industries. Perhaps if Lean were a more well-known term in IS, we could benefit from several decades of experience and from training in lean principles.
MBP >>
I have to agree, there is a lot to be learned from good old low-tech industries. What will drive improvement into software development is competition – in highly competitive industries, there is no alternative but to find the approach that has the least waste, lowest cost, and highest quality. As software becomes more and more pervasive, those who develop systems wisely will end up at the top of the competitive hill.
TDP >>
Lean looks at the whole value stream from concept to cash or order to payment. It delivers more value by avoiding sub-optimizing choices and handoffs.
About 1/2 hour later, Ursula poses another question to Mary and Tom Poppendieck:
Ursula Rutherford said,
November 16, 2007 @ 4:22 am
Making a broad generalization, it seems lean initiatives in many industries need top-management support to have a chance of success. In contrast, there are many accounts of agile programming techniques being adopted at team level with good results.
At what level of organizations do you recommend lean software development be introduced?
Imagine an organization with high-level sponsorship and a generous budget to make software development lean¦ Should change begin with education or practice; in the development team or the boardroom; slow or fast; a pilot project or for real’; imposed by decree or encouraged by incentives?
MBP >>
Where to start is very dependent on the context and on the location of the biggest constraint. If the biggest constraint is a huge end-of-cycle test and merge bottleneck, then you can make huge strides by getting stop-the-line testing disciplines in place. This involves integration of testing with development, but that might be possible at a rather low level.
On the other hand, if the biggest constraint is caused by thrashing because more work is being dumped on the development organization than it can hope to handle, then higher level of management involvement is usually necessary to make a big difference. If the approval process is insisting that a host of low priority features be developed, you have yet another problem that needs to be addressed from the perspective of a broader organization.
I generally recommend that you do a rough value stream map in order to find the biggest constraint in your system. Actually, people probably already know what the biggest constraint is, but are reluctant to confront it, and a value stream map might just help to put difficult issues on the table for discussion. Once you have found and are ready to confront the biggest constraint in your development process, then you don’t need a value stream map for a while, instead you need a top notch, team-based process improvement process that addresses and gradually removes the key constraint. Since the constraint generally occurs at organizational boundaries, it usually helps to have senior management involvement at this point.
TDP >>
At its heart, Lean is a management philosophy based on deep respect for people and relentless elimination of waste from the delivery of value to customers to return sustainable prosperity for the organization. Sustainable deployment of Lean (or Agile) must reach high enough in an organization to control the entire value stream and to control how people are treated. In some cases, this may only extend to departmental or divisional level management, in other cases, it may need to extend beyond organizational boundaries to an entire supply chain. How people are measured and rewarded determines how they will behave in the long run.
Related Posts:
Become a Lean Six Sigma professional today!
Start your learning journey with Lean Six Sigma White Belt at NO COST
Karen Wilhelm says
This discussion is right on when it comes to what’s wrong with the IT part of the business and how to improve on it. A lot of really good people are involved in a dysfunctional system that nobody can agree on how to change.
I have to comment on learning from “low-tech” industries. Technology means ‘a method or tool for doing something” and “studying and understanding the method.” In other words, know-how. Too often the press, government officials, business experts, etc., want to apply “high-tech” to the information technology, biological or electronics industries.
Lean is a technology itself, thus, any company that understands how to use it, no matter what they produce, it high-tech. In manufacturing, computer-numerical-control machining centers, robotic systems, transfer and progressive die stamping operations, continuous casting steel systems and so on are as advanced technologically as wireless communication systems. When IT people see themselves as part of a production system, and actually visit the places where work is done (Toyota’s assembly line and dealerships, for example), the software they produce will be much better aligned with the company’s needs and they will be better able to distinguish between unnecessary features and critical requirements. The business customer can’t always do that. That’s why kaizens or other improvement events ask for “outside eyes” to participate. If a company is implementing lean in any serious way, the improvement team leaders ought to be delighted to have somebody from IT get in on a project. Then learning becomes person-to-person, relationships are formed, and some of the constraints imposed by bureaucratic development processes can start to be attacked.
It’s good to hear the idea of lean emerge in the software area. The move to implement lean accounting is gathering amazing momentum. Maybe software will be next.