INTERVIEW – Tom and Mary Poppendieck sit down with Roberto Priolo and discuss what makes product organizations successful today and where lean software development is headed.
Interviewees: Mary and Tom Poppendieck; authors, lecturers, experts in lean software development
Roberto Priolo: During your talk at the Lean IT Summit in Paris, you used the word mindfulness to describe successful businesses. What does a mindful organization look like?
Mary Poppendieck: A mindful organization is one that experiences very few failures. Airlines are a great example of it, and so is pretty much any Toyota plant.
Specifically, there are five characteristics that tell us that a company is mindful, or highly reliable.
The first one is preoccupation of failure. Let us stick to the aviation example for a moment: every plane crash or near miss is thoroughly investigated to find the root cause of the problem, which then goes on a pilot checklist. Within a couple of weeks from an accident an updated checklist is often in place, its purpose being to ensure a particular problem does not reoccur.
The second characteristic is reluctance to simplify. Standards help us to prevent mistakes, but thinking that life will be fine so long as we tick every box in a checklist is a mistake. That’s too simple. Mindful organizations don’t believe in simplistic explanations for failures and in silver bullet solutions.
Next, we have sensitivity to operations, which means that high reliability organizations have really good standard processes in place to help employees to deal with the routine activities efficiently and quickly so that they can focus more on solving the complex situations.
Still, sometimes things do go wrong and when this happens a mindful organization focuses on recovering and learning, which is what we call commitment to resilience. Mistakes are (or at least should be) seen as learning opportunities.
Finally, the fifth characteristic: deference to expertise. Highly reliable organizations always know where the best decisions can be made – often, it is the front line.
RP: In the presentation, you also used the military as an example for companies to look at. But isn’t an Army normally seen as a very hierarchical, command-and-control environment?
MP: It isn’t, not when you are in training or at war. Imagine two armies meeting on the battlefield. One of them does exactly what the general tells them to do, while the other reacts to the unfolding situation to meet the general’s goal. The reactive army will win, no doubt.
Every military organization in the world knows this, and trains its people to be flexible and responsive on the ground. You would be amazed to know how much responsibility front line people have in combat (something we can hardly say about the corporate world). It may appear to the outside that people are told what to do, but if you take an insider’s point of view things change quite a lot.
Tom Poppendieck: Former US Army officer and now agile coach Dan Rawsthorne says that the whole purpose of command and control is to separate command and control, not to unify them. While intent is expressed through the command, control is devolved to the lowest level of the military units.
RP: In your opinion, what is lean IT movement not getting right?
MP: For starters, I think that IT is the wrong word. It’s an obsolete concept, referring to delivery organizations, whereas companies today tend to be product organizations that don’t have IT, but software engineers who do product development.
What’s also missing is a true perception of value. In a product organization, value is easy to see: either your customer likes your product or they don’t. But if you are in the IT business, real value is more difficult to identify because you are too far from the customer.
Trying to use lean, which is all about value, in an environment that is really all about reducing costs (in fact, most IT organizations are cost centers) does not work.
In delivery companies we tell people what is important but not why, while in product companies people understand the impact they are creating.
TP: Software product companies should have, and often do have, a direct understanding of how valuable they are to the people who use their software – as a result, they can make informed decisions on how to improve and grow.
In IT you don’t know what difference your choices make. It is not uncommon that the design calls you make are fanciful, meant to satisfy your curiosity and develop your resume, and not really linked to organizational value.
RP: You have seen lean software development in action around the world. Are there specific areas in which these principles take root more easily?
MP: Yes. Certain countries catch on these concepts a year or two before others. The first group to pick them up is normally Scandinavia – the management culture there is very much based on the idea of helping people as opposed to telling them what to do.
Typically, once the first hurdle (which, more often than not, is management staying in the way and preventing teams to take ownership) is gone, successive developments in the methodologies take root more quickly. Agile itself took a while to spread.
TP: At the same time, delays are getting shorter and shorter: thanks to global travel and communications, leading thinkers in different countries are pretty much in sync.
RP: What do you make of the lessons coming from the lean startup?
MP: Startups are product companies that use continuous delivery, and that is what allows validated learning to happen. It would be silly not to run experiments and find out for yourself what works and what doesn’t, especially if you can do it cheaply!
RP: What do you think the future of software development holds?
MP: Software plays an ever-growing role in our lives. Having good software in many of our products is going to become even more important and, therefore, the need for competent software engineers will become even more critical.
Companies that will figure out how to best leverage technology to solve our problems will be the winners. Google has been around too long, solving too many of our problems, to say that the way these innovative organizations do things is crazy. It is crazy smart! The real question is ‘why isn’t the rest of the world doing it?’
TP: We should never forget that there are very few people (who are not software developers) who want software! People need solutions to their problems that improve the quality of their lives, and software is only the tool those solutions will use to deliver.
Mary Poppendieck started her career as a process control programmer, moved on to manage the IT department of a manufacturing plant, and then ended up in product development. She considered retirement 1998, but instead found herself managing a government software project where she first encountered the word “waterfall.” When Mary compared her experience in successful software and product development to the prevailing opinions about how to manage software projects, she decided the time had come for a new paradigm. She wrote the award-winning book Lean Software Development: An Agile Toolkit in 2003.
Tom Poppendieck has 25 years of experience in computing including eight years of work with object technology. His modelling and mentoring skills are rooted in his experience as a physics professor. His early work was in IT infrastructure, product development, and manufacturing support, and evolved to consulting project assignments in healthcare, logistics, mortgage banking, and travel services. He is an enterprise analyst and architect, and an agile process mentor.
Based on their on-going learning, they wrote a second book, Implementing Lean Software Development: From Concept to Cash in 2006, a third, Leading Lean Software Development: Results are Not the Point in 2009, and a fourth book, The Lean Mindset: Ask the Right Questions in 2013.