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

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!