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

Agile Instructor - Coaching for Agile Methodologies such as Scrum and Kanban

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 destination for tips and interviews with the leaders in the world of Agile. Don’t forget to subscribe to this podcast on iTunes, and please check out our sponsor: TeamXcelerator.com. And now, here’s your host: Ronnie Andrews Jr.

Ronnie: Hello everyone and welcome to the All Things Agile Podcast, Episode 5. I’m very excited to present to you a wonderful interview with lead software legends Mary and Tom Poppendieck. Before I begin, a quick reminder that this podcast is for informational purposes only and accepts no legal liability. So let’s get started!

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

Well, thank you for joining me today Mary and Tom, I really appreciate 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’ve often found that large organizations tend to be project-focused, rather than product focused. For example, I have seen environments where software development is treated as a black box, and it can sometimes have a throw-it-over-the-fence mentality. I would love to hear your thoughts on integrating software development as part as a holistic product chain.

Mary: If you look back to the early 90’s, I was a manager in the early 90’s and there were very few of my colleagues that could even type. Typing wasn’t something that you learned, unless you were going to be a secretary. The idea of doing email and stuff was so difficult that when the internet first came, many managers sat down their secretaries to do their email typing. Eventually that went away. But if you look at industries that were formed before technology was widespread, like banks and insurance companies and those kinds of industries, you’ll find that this technology area was separated out from the mainstream for two reasons: one reason is because the managers of the line businesses simply were not comfortable with technology; and another was that computer technology was considered something that was expensive and should be centralized in order to reduce costs.

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

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

With those two things said, first of all it provides the competitive or strategic advantage to be thinking in line organization about technology. And secondly, technology is by and large best developed as a short feedback loop kind of a business; it makes very little sense to continue on with this black box concept that used to be a sensible idea. Tom, you have something to say?

Tom: Yes, definitely. I’d like to address this from a little more abstract level and put projects in their proper place. The motivating aspects as identified by Simon Sinek is ‘always a purpose’, a reason for doing things, a difference that an organization is attempting to make in the world. It’s the reason why people come to work, why they think about a problem, why they devote a lot of energy to solving a problem. Now, ‘Why?’ is primary – nothing great happens without a great ‘Why?’ ‘How?’ is where the project sits; it’s one of the techniques for containing risk, for containing how much resources you’re going to devote to achieving 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 of thinking to achieve a purpose. And neither of those are your product. Your product is ‘What?’ that’s Simon’s third level. Why, How and What? Now, whether you are successful is not so much a matter of did you sail this in the constraints, that your project imposes? It is ‘did you do the very best that you could in terms of achieving your purpose within the constraints of your available tools and skills, and risk management strategies?’

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

If you try and do a ‘What?’ that doesn’t really contribute to achieving the purpose and find out about it until very much after it has been done, and after many things have been built on top of it, you have wasted all of the good skills, all of the good techniques and you have triggered away your ‘Why?’ But if you find out about it very quickly, and you haven’t placed practices and approaches that you can recover very quickly, then you have the very best that you can; you’ve delivered the best ‘What?’ that you can using your constraints to achieve your purpose. And I think that’s the framework for thinking about projects – it’s just a tool; they’re not the ‘What?’, they are not 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 for the customers, I agree. Excellent answers. The next question I was wanting to ask, kind in a similar note, I also worked on projects where everything was kind of guided by arbitrary dates if you will. And sometimes, the end customer and the product features were really not in focus. Have you seen this behavior before and if so, what advice do you have for our listeners on how to tackle this issue?

Mary: Well, it’s interesting where the arbitrary dates come from, because I think that a business organization wants them to help them move forward with customers. They have some frame in mind about how much it’s worth to them to do that, how much money they can spend and what kind of deadlines are important, and those deadlines and those budget constraints should be honored as far as what are our constraints for meeting our overall objective? But then those get translated into somebody’s version of minor objectives and minor deadlines and if we don’t do this by this time, we can’t get to there by that time. Then those become completely arbitrary and basically unattached to the overall purpose. And those kinds of deadlines that are fake, are pretty easy to detect and what is the reason for them? That’s what you got to ask. Why do we have these strange deadlines? Why don’t we have, instead, a very tight feedback loop and a visibility of the progress we’re making towards the overall objective of what we’re trying to do and understand what part of the progress needs to happen at different times.

Now, if the way that you do a project is you first do all of the design and then you do all of the next step and it isn’t until the end that you actually do the work, write the code, write the test, integrate the software, 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 a minimal system, but it will be workable and we can get feedback on it – and that two months is going to give us another 8 months to finish the whole thing and the feedback necessary to do that’ – that’s a much more viable deadline. So you have to say are the high level constraints appropriately applied as low-level constraints to get stuff done or are they artificial? Because if they’re artificial, smart people can figure that out and they will ignore them. Tom?

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

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

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

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

Ronnie: I definitely 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 my experience, I’ve seen senior exectutives get very excited about Agile and they decide to roll it out across the organization. However, sometimes the teams can be lacking in technical skills or tools to ensure success. For example, great Agile teams place a high value on quality and that usually will translate in frequent and rigorous testing. And if a team has, for example, automated tests in place that will result in the product being in good shape. However, there may be teams which have never worked, for example, with test automation and it can then be a real challenge. What are your thoughts regarding skills and technical preparation in relation to methodology adoption?

Mary: Methodology is 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 that you can do a better job of satisfying customers. And you should not be measuring ‘did I do this or that Agile practice’? You should be measuring ‘do I have greater impact in delivering what my customers really want?’ And that’s where you get to the quality, the test automation and that sort of thing.

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

Let me give you an example in Alcoa – once upon a time when he became CEO, decided that he wanted to focus on one single thing and it was going to be safety. And every single issue around any kind of safety incident was what the entire company focused on. And that became a lever to cause all kinds of additional good behavior and the company really took off, because you can’t have safety without quality, alert workers, really good, well-run equipment, all of that sorts of things. And similarly in Lean, the concept of flow 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 and so on. Similarly in software. Let’s not focus on process; let’s focus on continuous 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 is a driving principle that will drive all the rest of the good behavior and certainly, all of the technical behavior.

Ronnie: Excellent answer. A final question, if you will. There are many great sources of information on implementing Agile, but most are geared towards smaller organizations often. And for larger companies, it can be a hurdle if you will to implement new methodologies in a global workforce. For example, I’ve recently worked with teams that are split across India, Brazil, China, Mexico and of course here in the US. What insight can you provide on how to tackle teams that are globally distributed?

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

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

But if the teams are geographically distributed, you have to think hard about how can they all share a common purpose that they understand and believe in and commit to, and if they do that the communication issues will be solved. And if you can’t imagine teams across countries dedicated to a common purpose, then you should say: Why are our teams structured this way? So every 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 of things. But they do have a few things in common. One is, they think for themselves. They don’t take rule books. They try to make sure they honor the intelligence of every person on the team and make sure that they can participate fully their thoughts in thinking about it, and they don’t have these wall handover mechanisms because that’s not the right way to deal with this.

Tom: All the teams we have seen around the world, and we’ve seen many, have one shared characteristic. And it’s not tools or techniques or methodologies – it’s they think for themselves. There are many examples, case studies about groups that have thought about their problem and their context and their challenges and they think for themselves and come up with a unique combination of tools and techniques and disciplines that make them highly effective in achieving their purpose. A team which is distributed and is simply doing what it’s told to do is not going to be very effective. A team which is distributed for a good reason who all believe in a purpose that they are trying to achieve and have adequate tools, handles and the like, that make it possible to communicate effectively, will figure out how to do it. They will think for themselves, if they have sufficient feedback about how they are doing, how things are working for them; they will figure out how to do it. And there are many, many ways that different teams figure out how to do this. But it’s not a recipe. It’s not a product 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: I definitely agree. I definitely agree with you that having those teams be able to really understand it and what they’re trying to achieve and have those goals and have that thought in control is very key – it’s as you mentioned, if you kind of have a class A, class B type situation, then it can often result in micromanaging and diminish morale and sometimes poor quality – I’ve seen in the past the results in code. Great points, great points! And a lot of them are actually referencing some of your more recent work – if you don’t mind, I’d love 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 was just reading in an article that it used to be ‘share all their value’ was the thing that businesses thought they were in business for. But today, in today’s economy and today’s high-tech environment, what you really want to do in order to have a successful business is you need to have great people that use their minds for accomplishing the common purpose. And that purpose has to be something that these people believe in and you need to have an intense focus on delighting customers. And those three things: customers that you’re trying to delight, employees that are deeply engaged at trying to make something happen for those customers and an overriding purpose are the three sort of company drivers of the future.

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

Ronnie: Excellent! I definitely encourage our listeners to pick up a copy of your latest book. Once again, it’s ‘The Lean Mindset’ and it’s available at book stores everywhere. I picked up my copy on Amazon, and I really just want to thank 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. I really 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 you subscribing to the podcast on iTunes and leaving a kind review. Thanks and God bless!