I am thrilled to present a wonderful interview with Mary and Tom Poppendieck.  They are true legends in the Agile and Lean Software Development movement.  Checkout today's episode where we discuss challenges facing many organizations such as: product vs. project mindset, globally distributed teams, and equipping teams for success. We also discuss their latest book, The Lean Mindset.  Please consider picking up the book to learn more about these topics in greater detail.

Please check out their website: poppendieck.com to learn more about Mary & Tom and their insightful work.  Many thanks to Mary and Tom for investing their time for this podcast and for their contribution to our industry.

All Things Agile - Episode 005 - Mary and Tom Poppendieck Interview

Transcript:

Welcome to the All Things Agile Podcast. Your destinationfor tips and interviews with the leaders in the world of Agile. Don’t forget tosubscribe to this podcast on iTunes, and please check out our sponsor:TeamXcelerator.com. And now, here’s your host: Ronnie Andrews Jr.

Ronnie: Helloeveryone and welcome to the All Things Agile Podcast, Episode 5. I’mvery excited to present to you a wonderful interview with lead software legendsMary and Tom Poppendieck. Before I begin, a quick reminder that this podcast isfor informational purposes only and accepts no legal liability. So let’s getstarted!

One of the goals for this podcast is to interview andfeature influential leaders in the Agile space. Today’s guests are just that –Mary and Tom pioneered the Lean Software development movement, with theirgroundbreaking book Lean Software Development and Agile Toolkit. It’s a classicamong Agile literature. In 2013 they also released ‘The Lean Mindset – Ask theRight Questions’. Mary and Tom travel the globe, speaking at conferences andconsulting with many of the world’s top companies. It’s an honor and a pleasureto have them on the All Things Agile Podcast. Without further ado, let’swelcome Mary and Tom!

Well, thank you for joining me today Mary and Tom, I reallyappreciate it. Why don’t we go ahead and get started with a few questions.During my own career, I have worked at several Fortune 500 companies. And I’veoften found that large organizations tend to be project-focused, rather thanproduct focused. For example, I have seen environments where softwaredevelopment is treated as a black box, and it can sometimes have athrow-it-over-the-fence mentality. I would love to hear your thoughts onintegrating software development as part as a holistic product chain.

Mary: If you lookback to the early 90’s, I was a manager in the early 90’s and there were veryfew of my colleagues that could even type. Typing wasn’t something that youlearned, unless you were going to be a secretary. The idea of doing email andstuff was so difficult that when the internet first came, many managers satdown their secretaries to do their email typing. Eventually that went away. Butif you look at industries that were formed before technology was widespread,like banks and insurance companies and those kinds of industries, you’ll findthat this technology area was separated out from the mainstream for tworeasons: one reason is because the managers of the line businesses simply werenot comfortable with technology; and another was that computer technology wasconsidered something that was expensive and should be centralized in order toreduce costs.

Well, today, computer technology is not the same. It is thefundamental basis for competition for almost every company that uses it. Thanksto the kinds of products that they offer, or the things that help them becompetitive – if you take a look at the new companies like Google and Facebookand Amazon and those companies, computer technology is a fundamentalcompetitive advantage. And if that’s true, then it needs to be manage, at leastwhat’s done, in the line organization, rather than in some side-organizationthat is in side to the line organization. So if you look at the companies I’vejust mentioned, they don’t have a central IT department. They have the lineorganizations responsible. That doesn’t mean that they don’t think about ITcosts, but they think about them as product development costs.

So now, the things that people develop that are helping thecompany become more competitive and distinguish it from other companies, arethings that need to happen with people who sit in the line organization andtruly understand customers and are close to them and secondly, softwaretechnology today is much more thought of not as a black box, but as a constantfeedback mechanism. So you do something, you see the results on customers andon the line business, you adapt to the results and you continue on.

With those two things said, first of all it provides thecompetitive or strategic advantage to be thinking in line organization abouttechnology. And secondly, technology is by and large best developed as a shortfeedback loop kind of a business; it makes very little sense to continue onwith this black box concept that used to be a sensible idea. Tom, you havesomething to say?

Tom: Yes,definitely. I’d like to address this from a little more abstract level and putprojects in their proper place. The motivating aspects as identified by SimonSinek is ‘always a purpose’, a reason for doing things, a difference that anorganization is attempting to make in the world. It’s the reason why peoplecome to work, why they think about a problem, why they devote a lot of energyto solving a problem. Now, ‘Why?’ is primary – nothing great happens without agreat ‘Why?’ ‘How?’ is where the project sits; it’s one of the techniques forcontaining risk, for containing how much resources you’re going to devote toachieving your ‘Why?’. Agile is another collection of techniques that are‘How?’s – ways of working strategies, tools.

Engineering disciplines are another set of ‘How?’s.Automated testing and many others. But they’re all ways of working, ways ofthinking to achieve a purpose. And neither of those are your product. Yourproduct is ‘What?’ that’s Simon’s third level. Why, How and What? Now, whetheryou are successful is not so much a matter of did you sail this in theconstraints, that your project imposes? It is ‘did you do the very best thatyou could in terms of achieving your purpose within the constraints of youravailable tools and skills, and risk management strategies?’

I read a fascinating article in Harvard’s Business Reviewyesterday. And it was saying that the most important, the most powerful way ofmanaging risk is to measure and analyze time to recover the something goingwrong in any individual component of what you’re doing. This translates easilyat least in my initial impression, into how fast is your feedback loop?

If you try and do a ‘What?’ that doesn’t really contributeto achieving the purpose and find out about it until very much after it hasbeen done, and after many things have been built on top of it, you have wastedall of the good skills, all of the good techniques and you have triggered awayyour ‘Why?’ But if you find out about it very quickly, and you haven’t placedpractices and approaches that you can recover very quickly, then you have thevery best that you can; you’ve delivered the best ‘What?’ that you can usingyour constraints to achieve your purpose. And I think that’s the framework forthinking about projects – it’s just a tool; they’re not the ‘What?’, they arenot the ‘Why?’ – they’re just a way of containing risk.

Ronnie: Right,that makes sense. I agree. Sometimes, people place more emphasis, if you will,on the success of the project rather than the success of the product. And forthe customers, I agree. Excellent answers. The next question I was wanting toask, kind in a similar note, I also worked on projects where everything waskind of guided by arbitrary dates if you will. And sometimes, the end customerand the product features were really not in focus. Have you seen this behaviorbefore and if so, what advice do you have for our listeners on how to tacklethis issue?

Mary: Well, it’sinteresting where the arbitrary dates come from, because I think that abusiness organization wants them to help them move forward with customers. Theyhave some frame in mind about how much it’s worth to them to do that, how muchmoney they can spend and what kind of deadlines are important, and thosedeadlines and those budget constraints should be honored as far as what are ourconstraints for meeting our overall objective? But then those get translatedinto somebody’s version of minor objectives and minor deadlines and if we don’tdo this by this time, we can’t get to there by that time. Then those becomecompletely arbitrary and basically unattached to the overall purpose. And thosekinds of deadlines that are fake, are pretty easy to detect and what is thereason for them? That’s what you got to ask. Why do we have these strangedeadlines? Why don’t we have, instead, a very tight feedback loop and avisibility of the progress we’re making towards the overall objective of whatwe’re trying to do and understand what part of the progress needs to happen atdifferent times.

Now, if the way that you do a project is you first do all ofthe design and then you do all of the next step and it isn’t until the end thatyou actually do the work, write the code, write the test, integrate thesoftware, then those days are truly artificial. But if you strategy is to say‘I am going to have a complete system in two months – it’s going to be aminimal system, but it will be workable and we can get feedback on it – andthat two months is going to give us another 8 months to finish the whole thingand the feedback necessary to do that’ – that’s a much more viable deadline. Soyou have to say are the high level constraints appropriately applied aslow-level constraints to get stuff done or are they artificial? Because ifthey’re artificial, smart people can figure that out and they will ignore them.Tom?

Tom: Not alldeadlines are arbitrary. Some are legal, some are annual rhythms of shows.There are some very legitimate deadlines. And a competent team with a competentmanager that understands what it takes to do work will be able to achieve areal deadline. However, if a deadline is used as motivation, as a goad, as away of avoiding waste, then it can be very ineffective and very destructive. Itcan lead to bad behavior. The use of a deadline that is not legitimate, that isnot related to the ‘Why?’, to the work being done, is probably a symptom oflack of competence to measure what really matters about the progress of thework.

Mary: I want tothrow in one last little thing here, and that is that projects should havethings called: cost, schedule and scope. And the thing that really should beflexible is neither, in most business’ cases cost, nor schedule. The thing thatshould be flexible is scope, because cost and schedule deadlines are typicallydriven by business constraints. But the scope should be the thing that isnegotiable almost always and the reason for that is that, especially in asoftware environment, the thing that we’re putting together is a complexsystem. The more junk, features, capabilities or whatever that we throw intothat massive software, the more complex it is, the more difficult it is and byand large, over time, the more stuff you have in software, the more crud you getin there, the more complexity you get in there, the harder it is to change, tomanage and so on.

So in software, you want to think of ‘stuff’ as bad. Youdon’t want to measure a team on how much junk can I put in, in a window oftime? You want to say: How much business purpose can I achieve within as littlecode as possible? So you are looking for reduced feature set, reducedcapabilities that get the job done. And so the thing you really want to reduceis not the budget or the schedule; it’s the amount of stuff that you try tosqueeze into a business-driven budget and schedule. So typically in allprojects – and this is not the way most project managers look at it – but asoftware project almost always bend on scope, rather than bend on deadline oron cost.

Tom: It isimpact. Did you achieve the impact that your work aimed to achieve? Did itachieve its purpose? If the impact can’t be measured, you have no guidanceabout what to include and what to leave out. You have no measure about whenyou’re done. If you have as much impact as your tools and skills and techniquespermit, as the team was capable of and the project was a success…

Ronnie: Idefinitely like that impact thing – that kind of really sums it up really well,thank you. If you don’t mind, I’ll ask the next questions which is: in myexperience, I’ve seen senior exectutives get very excited about Agile and theydecide to roll it out across the organization. However, sometimes the teams canbe lacking in technical skills or tools to ensure success. For example, greatAgile teams place a high value on quality and that usually will translate infrequent and rigorous testing. And if a team has, for example, automated testsin place that will result in the product being in good shape. However, there maybe teams which have never worked, for example, with test automation and it canthen be a real challenge. What are your thoughts regarding skills and technicalpreparation in relation to methodology adoption?

Mary: Methodologyis the result – it’s not the driving factor in a good Agile implementation.What you’re trying to do is create an environment with rapid feedback, so thatyou can do a better job of satisfying customers. And you should not bemeasuring ‘did I do this or that Agile practice’? You should be measuring ‘do Ihave greater impact in delivering what my customers really want?’ And that’swhere you get to the quality, the test automation and that sort of thing.

So let’s talk about a different objective for thatexecutive, so that the executive have stuff that they can measure and put handsaround. And that is, instead of working about a methodology called Agile, whynot worry about what I’m going to call ‘The Software Development Process of theFuture’ which is continuous delivery. So instead of saying that we have thesemeetings and we have these things, you should be saying ‘How fast, from thetime I decide to do something, until the time I get it in production – how longdoes that take?’ And when you start looking at how far along am I on the pathto continuous delivery - that is my executive goal. Those companies that dothat have far more effective Agile implementations because it’s that one thingthat you’re focusing on that continues delivery, that drives all the goodtechnical behavior by the way of good practice behavior.

Let me give you an example in Alcoa – once upon a time whenhe became CEO, decided that he wanted to focus on one single thing and it wasgoing to be safety. And every single issue around any kind of safety incidentwas what the entire company focused on. And that became a lever to cause allkinds of additional good behavior and the company really took off, because youcan’t have safety without quality, alert workers, really good, well-runequipment, all of that sorts of things. And similarly in Lean, the concept offlow is sort of that driving principle. So you try and just focus on flow,everything falls in place. All the technical things, all the quality things andso on. Similarly in software. Let’s not focus on process; let’s focus oncontinuous delivery. How far are we towards being able to deploy immediately?And if we make that the one principle of how we perceive, then what we have isa driving principle that will drive all the rest of the good behavior andcertainly, all of the technical behavior.

Ronnie: Excellentanswer. A final question, if you will. There are many great sources ofinformation on implementing Agile, but most are geared towards smallerorganizations often. And for larger companies, it can be a hurdle if you willto implement new methodologies in a global workforce. For example, I’verecently worked with teams that are split across India, Brazil, China, Mexicoand of course here in the US. What insight can you provide on how to tackleteams that are globally distributed?

Mary: Therecertainly are many big companies – we wrote in our new book about Ericson as anexample – very large companies that are very effective in implementing Lean andAgile concepts. But they don’t hold a lot of stake in having ‘teams’ that aregeographically distributed. Yes, organizations are geographically distributed –but why do teams need to be? So what I see large, effective organizations dowhen they think about distribution is to say what are the things that need tobe communicated? And how can we effectively, at a single site, havecommunication among colleagues and think about communication across teams on adifferent scale? So the effective ones don’t try too hard to make individualshave to communicate across large distances. And if they do, they have peopletravel.

However, there can definitely be reasons why people should –and really valid purpose-drive, business-driven reasons why people need tocommunicate across geographic boundaries. And there certainly are plenty ofexamples on how this is done effectively. If you look at the open sourcemovement, none of the open source projects have people co-located. These oneswork very well with the communications issues across countries and if you lookat them for models on how to do it. So if teams do need to be distributed, thenyou want to think ‘Why?’ Okay? You do not want to have class A people figureout what to do and class B people are in another continent that actually implementit, because that gets us back to the first question. The people that are doingthe implementation are divorced from the purpose.

But if the teams are geographically distributed, you have tothink hard about how can they all share a common purpose that they understandand believe in and commit to, and if they do that the communication issues willbe solved. And if you can’t imagine teams across countries dedicated to acommon purpose, then you should say: Why are our teams structured this way? Soevery company that has solved this problem, has solved it in a different way,depending upon their market and their structure and all of that sorts ofthings. But they do have a few things in common. One is, they think forthemselves. They don’t take rule books. They try to make sure they honor theintelligence of every person on the team and make sure that they canparticipate fully their thoughts in thinking about it, and they don’t havethese wall handover mechanisms because that’s not the right way to deal withthis.

Tom: All theteams we have seen around the world, and we’ve seen many, have one sharedcharacteristic. And it’s not tools or techniques or methodologies – it’s theythink for themselves. There are many examples, case studies about groups thathave thought about their problem and their context and their challenges andthey think for themselves and come up with a unique combination of tools andtechniques and disciplines that make them highly effective in achieving theirpurpose. A team which is distributed and is simply doing what it’s told to dois not going to be very effective. A team which is distributed for a goodreason who all believe in a purpose that they are trying to achieve and haveadequate tools, handles and the like, that make it possible to communicateeffectively, will figure out how to do it. They will think for themselves, ifthey have sufficient feedback about how they are doing, how things are workingfor them; they will figure out how to do it. And there are many, many ways thatdifferent teams figure out how to do this. But it’s not a recipe. It’s not aproduct that you buy; it’s how people think about what they are doing together.If they can’t think together, they can’t be very effective at working together.They can’t learn together. The product will reflect that lack of learning.

Ronnie: Idefinitely agree. I definitely agree with you that having those teams be ableto really understand it and what they’re trying to achieve and have those goalsand have that thought in control is very key – it’s as you mentioned, if youkind of have a class A, class B type situation, then it can often result inmicromanaging and diminish morale and sometimes poor quality – I’ve seen in thepast the results in code. Great points, great points! And a lot of them areactually referencing some of your more recent work – if you don’t mind, I’dlove to mention that briefly. You guys have put together a great book last year‘The Lean Mindset’. Would you like to maybe highlight that a little bit more?

Mary: Sure! I wasjust reading in an article that it used to be ‘share all their value’ was thething that businesses thought they were in business for. But today, in today’seconomy and today’s high-tech environment, what you really want to do in orderto have a successful business is you need to have great people that use theirminds for accomplishing the common purpose. And that purpose has to besomething that these people believe in and you need to have an intense focus ondelighting customers. And those three things: customers that you’re trying todelight, employees that are deeply engaged at trying to make something happenfor those customers and an overriding purpose are the three sort of companydrivers of the future.

Our book has 5 chapters. One is on purpose and then the nextone is on engaged workers and energized workers; the third one is aboutdelighted customers. And then we talk about efficiency and what efficiencymeans in this context. Efficiency means, in the Lean context, flow efficiencyrather than resource efficiency. Which is a whole other topic that we can talkabout sometime. And lastly, we talked about innovation because today’s economy,today’s technology moves too fast to be comfortable that what worked 3 yearsago is going to work 3 years from now, so constant innovation is another thingthat companies need to have. That’s sort of, in a nutshell, what the book isabout, those 5 chapters. And to sum it all up we have lots of case studies inthere, as Tom said, and each case study shows how thinking for yourself in yourcontext is important; which means it’s important to have people who care tothink for themselves and who are allowed to think for themselves and who areinspired to help make the company successful.

Ronnie:Excellent! I definitely encourage our listeners to pick up a copy of yourlatest book. Once again, it’s ‘The Lean Mindset’ and it’s available at bookstores everywhere. I picked up my copy on Amazon, and I really just want tothank you both Mary and Tom for joining me today for this podcast episode.It’s been tremendous help to myself and I’m sure, to all of our listeners. Ireally thank you so much for your time Mary and Tom, you’ve been great!

Thank you listening to All Things Agile. We look forward to yousubscribing to the podcast on iTunes and leaving a kind review. Thanks and Godbless!