Here's the interview Pete Abilla did with Lean/Agile software leader Mary Poppendieck. There are 12 questions in the link above, here is one focused on lean tools we all know (reposted with Pete's permission):
shmula: I'd love to see examples (and/or) suggestions of how to implement the following to software organizations:
1) Kanban, 2) 5S, 3) Visual Workplace, 4) The Big Room (Product Management, Development, QA, etc…) — how to best plan and coordinate between all stakeholders, 5) SMED, 6) 5 Why's, 7) TPM. This is an Epic-sized question, I know, but I think sharing your knowledge will help all of us tremendously. Thanks so much!
Mary Poppendieck: An epic-sized question indeed! I'll do just a brief comment on each one, and then refer you to my most recent book, Implementing Lean Software Development: From Concept to Cash, for more on some of them.
1. Kanban. The Kanban of Software development is the index card. Stories are written on cards, estimated and selected at the iteration planning meeting, posted in the team room, updated when the story is being worked on and when it is done.
2. 5S's. Apply the 5s's to the server which stores the code and associated documentation, to desktop environments used by more than one person, and to the code base. We have examples in our new book.
3. Visual Workspace. There are three aspects to a visual workspace – the Kanban card (index card) which tells people what needs to be done, the Andon, or signal that something is wrong (eg. lighting up a red light when the build breaks), and big visible charts which tell everyone how things are going. We also have a section on this in our book.
4. The Big Room, or Obeya. Take a look at the video “21st Century Jet” (KTCS, Seattle) and you will see good examples of the Big Room in action during the development of the Boeing 777 in the 1990's. This isn't a new idea, but it certainly is a good one.
5. SMED, or Single Minute Set-up. The time it takes to test and deploy a release is the set-up time of software development. Many companies take so long to test software that releases are very far apart, and every effort is made to stuff as much as possible into each big-batch release. Some companies release to production several times a day (anti-virus software comes to mind) – they have SMED figured out.
6. 5 Why's. Root Cause Analysis for any problem is a fundamental skill that all teams need to learn. First we have to implement a Stop-the-Line mentality with test-driven development and continuous integration, so that we find and fix most defects instead of putting them on a rework list. Only then can we start using the 5 Why's to discover the root cause of the remaining problems that occur.
7. TPM or Total Preventative Maintenance. In software development, we call this refactoring. We keep on improving the design of the code base to keep it healthy and prevent it from calcifying and becoming a jungle that can no longer be maintained. Legacy code is code that has not had regular TPM.
Mark's comments: I'm sure there are great applications of lean methods and lean management to software development efforts, but I think we should be careful about looking to force fit specific lean tools. I think Mary's book title gets it right: From Concept to Cash. That's always the goal of lean and TPS, reducing time to cash. I wouldn't force fit kanban, for example, because Mary's rationale for using kanban doesn't really resonate with me, or it doesn't sound like true kanban. But, I can absolutely see applications of 5S, visual management, etc.
But, the real key, I think is the problem solving methodologies (such as the 5 Why's) and “respect for people”, getting the most out of the smart programmers that you've hired. I used to work in a software company and, it was sad, that the coders were the “operators” of the company. They weren't necessarily listened to or respected (outwardly, at least) any more than the operators I worked with back at General Motors. The company I worked for created software for lean manufacturing environments and, ironically enough, we didn't use any lean methods internally in the design or development of our software. Wasted opportunity there.
To be fair to Mary, she does say, in answering another question, that her most recent book does focus on the lean/TPS concept of “respect for people.” My criticism above is more toward the question that focused on tools. Mary talked quite a bit, in other answers, that lean software is about:
1. Is the team focused on delivering increments of real value to end customers – and does everyone understand what that really means?
2. Is the team a Whole Team – composed of everyone necessary to deliver value to the ultimate customer?
3. Does the team reliably and repeatedly delivers on its promises?
What do you think? Please scroll down (or click) to post a comment. Or please share the post with your thoughts on LinkedIn – and follow me or connect with me there.
Did you like this post? Make sure you don't miss a post or podcast — Subscribe to get notified about posts via email daily or weekly.
Check out my latest book, The Mistakes That Make Us: Cultivating a Culture of Learning and Innovation:
Mary, although I have not read your book, but I get a fair amount of Idea what you mean. Could you please give something more on SMED part in Sofware Industry.Your explanation clarifies a lot , but I will be grate ful if you could throw some more light on this
Hi Biklu – I think you should post your question on the shmula website, you’re more likely to get an answer from Mary there.
LINK
nice article..