Mary Poppendieck has been in the Information Technology industry for over thirty years. She has managed solutions for companies in several disciplines, including supply chain management, manufacturing systems, and digital media. Tom Poppendieck is an enterprise analyst and architect, and an agile process mentor. He focuses on identifying real business value and enabling product teams to realize that value. Tom specializes in understanding customer processes and in effective collaboration of customer, development and support specialists to maximize development efficiency, system flexibility, and business value
Download PDF Transcript of Podcast
Note: This is a transcription of a podcast. It has not gone through a professional editing process and may contain grammatical errors or incorrect formatting.
Related Podcast: Process Control Thoughts from the Poppendiecks
Transcription of the Podcast
Joe Dager: Welcome everyone! This is Joe Dager, the host of the Business901 podcast.
With me today is Mary and Tom Poppendieck. They have been in the IT industry for over 30 years. They have managed solutions for companies in many disciplines, including supply-chain management, manufacturing systems, and digital media.
Seasoned leaders in both operations and new-product development, they bring a practical customer focus approach to software-development problems. Popular writers, authors of several books, and speaking at many different conferences, they continue to offer a fresh perspective on project management.
They were one of the first to attach Lean thinking to software. For a history lesson, can you tell me how that came about?
Mary Poppendieck: I was working in a manufacturing plant doing video tapes. I worked for 3M for about 20 years and somewhere along the line, I became IT Manager in a manufacturing plant.
We had very serious competition from Japan. We had to do something different. So, we looked at what was going on in Japan ?? this was the early ’80s ?? and discovered that they were doing this crazy thing called Just-In-Time. Now, everybody knew that wasn’t a very good way to do anything, but that’s what they were doing, and they were really beating us on price, on quality.
So we thought, we really needed to try something and, for lack of better ideas, we tried to do Just In Time in our plants. It worked spectacularly. Because of that, I came to appreciate the concepts of Lean, spending a large amount of my time in both product and software development. I took the concepts that I learned in manufacturing and applied them into, first of all, software development, and then product development, in general.
Joe: I recently attended the Lean Software and System Conference where I heard you speak. Your topic was, “Feedback Control to Improve the Process of Developing Software Systems. The words “feedback” and “continuous” seemed to be a very dominant part of the conversation. Can you expand on that and how the two interrelated?
Mary: Feedback systems in general, because as I said I was a process control engineer before I went into the manufacturing plant as IT Manager.
Feedback loops, for example, the feedback looped the controls, cruise control on a car that is a constant monitoring of the speed, compared against the speed that you’re at, and adjust.
Now if you don’t do that every second or two, your car is going to be able to get out of control really fast. The only way to keep the controls going in a nice; even speed is to have a continuous feedback loop.
In software development as it turns out, if you really want to understand how your software is doing, in what customers want, and how what you’re doing is being received, especially in the rapid business climate of these days, the thing to do is to figure out if you can deploy your software continuously or very rapidly, get feedback, determine how to modify whatever it is you are doing so that you constantly are adjusting your software to meet the things that customers are looking for, and the changes in your domain.
Joe: I find it quite interesting that you look at the delivery by a team as no longer an iterative cycle, but one based on flow. Is that the influence of Kanban over Scrum or maybe you better tell me what the influence is, OK?
Mary: Even iterations are a flow when it comes right down to it. If you develop software in two-week iterations and actually deliver it every two weeks to customers, that’s as much a flow… that’s almost continuous.
In fact, when I think of continuous delivery, I think of daily or possible twice a week, or weekly. If you look at the kind of delivery that Facebook does, it’s once a week with small chunks in the middle of the week.
Gmail, for example is delivered twice a week. Chrome is deployed every day. Those kinds of very rapid deployments, you find inside of software as a service, where they’re websites, or you find them sometimes inside of the enterprises.
The idea of iteration has been, how about; we develop software and get it ready to deploy every couple weeks. Well, if you just stop thinking about being ready to deploy and say what would it take to actually deploy it. Just get it out there and start getting the value from it and getting the feedback from it now, you can do that in two-week iterations. You can do that with a Kanban system; it doesn’t matter.
The optimum thing is how rapidly do we deploy our software rather than how rapidly do we get little chunks of it done.
Tom Poppendieck: The primary thing that we are advocating is not to think of software development as coding and testing. Rather to think of it as figuring out what is worth doing, what’s going to delight the customer, doing it, making sure it’s working well, getting it in service to the customer, and getting feedback from the customer.
The really important metric is how fast you can get feedback from a customer about the actual, deliverable application that you are creating. That is beyond the realm of most people who are thinking about software all by itself. It gets toward the devops on one end, and it gets toward the design thinking on the front end.
When we’re thinking about flow, we’re thinking about rapidly getting feedback from your best design ideas all the way from production.
So, either a two-week iteration or a continuous flow like Kanban can be rapid, say a couple of weeks to a couple of hours, compared to the very common approach of having dozens of two-week iterations before you get any feedback from actual production.
Mary: I’ve actually seen Kanban be used just to develop the software. Still they don’t deploy it until, I don’t know, a couple of months apart, or four months apart, or six months apart, or even a year. So it doesn’t matter what process you’re using, if you’re not deploying and getting feedback. You’re not getting the information you need to know how the software is doing.
Joe: I think both answers are great because that really was my next question, is who will give you that continuous feedback. What you’re saying is you should deploy as often as you can add value for that feedback from the customer.
Mary: Yes.
Joe: If you can do that, you will be gaining continuous feedback. Continuous may mean for one life cycle, two months. Another one may be every day.
Mary: Indeed, I don’t know about the few months’ part. When I think of continuous, I actually describe it as a week or less.
Joe: Data is still king though, isn’t it? I mean, we have to deploy something. We have to be able to measure it though. Do you agree with that or can we wing it?
Mary: Let’s pretend you’re Amazon. You’re deploying a new service, just a small part of your system, and you deploy it when you are ready. That small thing is meant to do something to attract a few more customers, run a test to see if you supply extra information, on checkouts you might make customers happier, or add a few more options to the review, or something like that.
There’s no sense in waiting. Why not try that and see how it goes? In fact, you could be running good old marketing style AB experiments all the time if you can deploy frequently. If you don’t deploy except for every month or two, there’s no way to be running experiments to see whether this various, this approach or that approach, is, in fact, a better one.
Tom: You have to think that your goal is learning. L what the best solution for one aspect or another of delighting the customer will require. If you learn that your hypothesis is wrong, why take that code out. If you learn your hypothesis is correct, you continue along that direction or go onto your next understanding of what will delight your customer.
Learning is the key thing, not generating code. Generating code is merely a means. It’s not the purpose.
Joe: This also means with the user or with the customer. It’s not an “internal customer” that we’re deploying this too.
Mary: We tend to see software as a product and in fact, a large amount of the companies we work with are companies that actually make software-intensive products. You can think of anything from a medical device with a lot of software in it, to a website which allows people to buy stuff, to something like social media website, or Twitter, or anything like that.
Those are all software products which people use all the time. It’s the customers who are using that software? intensive product that are bringing revenue to the company, and those are the ones that you want to figure out how to make their lives easier.
Tom: Even for internal software, the product is not software. The product is an improved business process that either goes faster, generates more revenue, reduces errors, saves time, improves sales or whatever.
The business process is what matters. That’s where the return comes from. Your success of your product, of your software development, is not measured by cost, schedule, scope, or guesses of what it should take. It is measured by did you have an impact on the way the business process works that the organization was hoping for. That’s what success means.
Even internally, you have to look at the real product and not measure your success based on the software metrics.
Joe: A better explanation may be then, and rather than internal and external customer would be the user would be a real customer.
Mary: Well, there is more than one. There’s always more than one customer, usually anyway.
Some people might be considered customers if they pay for your software, if they use it, if they derive value from it, or even the people who have to support it in the operation’s environment are the customers of the software. If you don’t do your job right, they can have a lot of headaches. You always think of multiple customers.
Tom: Actually, I think the developers themselves are also customers, because they’re going to have to come back and maintain it. It’s not maintainable; they suffer.
Joe: You mentioned at the beginning of this that you really don’t look at project management. You look more at it in the scope of product management. Can you explain that to me more?
Mary: If you think of what we just said, your customers are people who buy products from your company, or possibly people who are engaged in the process of and help people buy product from your company. Really, you’re trying to create a feedback loop that understands how what your software is doing to make that product better, more attractive, more useful.
When people do software, they’re changing something. They’re changing a business process. They’re changing the way a medical device will be used. They’re changing the way the people will interact with the website.
That kind of thing to concentrate on is; are those people receiving the value or not? Now projects are generally according to the way projects are thought of, something that has a start and an end, then it’s over. That’s measured by whether or not you delivered what whoever asked you to do the project said they wanted, whether or not you did it within the time and budget that you said, and they’re typically funded at the beginning of the project.
If you look at software development as something incremental and always changing, and always being modified based on how the customers respond, then you are totally outside of that project metrics, and you’re looking much more at have I created something useful for the business that I’m in or for the customers, I’m serving in this small amount of time.
If you go to a company like, well, let’s just arbitrarily say Google. Have you ever heard of Google doing projects? No, they deliver software sites. They, first of all, put them into their development labs, and they put them into beta, and they check all the things, and they rapidly iterate on whether or not the features that they have are the right ones, and they improve it all the time.
They don’t have this concept of a project. They have this concept of let’s do something that our customers will love.
Joe: When we start involving customers in the design of our products, and we’re taking it out there for them to participate in this beta, and receiving this continuous feedback in this maturity, they’re, in essence, helping us co-create or co-produce our product. Are we involving the customer more in earlier stages, and is that the direction it’s going?
Mary: So, why do we produce products anyway except to solve customer problems? Who are we to think we have a deep understanding of what the customer problem is that we’re trying to solve, unless we get involved with them and understand what it is that they want, and what kinds of things will delight them?
I have a hard time imagining creating any product of any type without a lot of deep customer involvement. In fact, when I was at 3M, I did products that were lighting products. Those were products that also dealt with computer interfaces.
Those products, we always spent time making sure we truly understood what the customers wanted. We talked with them; we made sure that we had a very good understanding of their problem as we were developing things. We brought them possible things that they might comment on, or we asked those questions.
I don’t see where this is any different because products aren’t going to be successful if they aren’t solving customer problems. The customers are the ones that have the problem, and they understand it better.
Tom: The idea that the team involves only the software people is far too limiting. It’s not just software and test. It needs to be a whole team, and that includes many more people. Of course, it includes operations. It includes the developers. I also include perhaps finance, perhaps marketing, perhaps customer support. It includes everybody who needs to contribute to making a product successful.
So that’s the whole team. The software people are only a sub-team.
Joe: One of the latest crazes is the Lean StartupTM, and I say that in all respect. Lean Startup, to me, is all about customer development, so it kind of fits in right here. But you added something to the build-measure-learn cycle in your talk at Lean Software and Systems conference. Could you mention that and expand on that a little for me?
Mary: Before you build, you want some idea of why you’re doing something. So you create a model of how you think things will work, or a hypothesis. If you look at the standard problem solving method or scientific method – Tom’s got a Ph.D., he’s a physicist ?? and you learn the scientific method.
The first thing you do in the scientific method is create a hypothesis about how the world behaves that is based on your current knowledge of the area, which is an informed hypothesis. Then you run some experiments to test it.
So you build something, and you measure the results, and you learn about it, and then you create a new hypothesis.
So in the same way, you create a model of what you think the customers will like. You don’t do just blindly anything. Based on that model and your understanding of them and the environment, you build something; you measure the results; you learn, and then you create a new model. This will be an improvement on the old one, or a change if your hypothesis proved not to be true.
Joe: Is the build/measure/learn then, you’re expanding it really to be scientific thinking, and more resembling the PDCA model, that you got to have a plan going forward before the build?
Mary: Correct. Oftentimes in the Lean Startup, they say actually you have to learn before you build. So it’s not different, we just sort of called out that extra step in there.
Joe: To me, the Lean startup, if the risks are low of putting a product out there with a minimum viable product, you can do that. But when the risks are high, can you really do that? I mean, can you put that product out there for people to test and stuff, or is there a fine line there that you can kind of clarify?
Mary: Well, no, it’s not fine. It’s dependent upon the context. So let’s just say you’re doing a game. Now, you would be crazy to put out a partially done game, and test it with feedback. You still have to test it. It’s just that you don’t want to make it public. Because games have this nature that if you put it out early, and it isn’t quite done, you can get some really bad reviews, and that’s the end of the game.
There are other things like that; if you look at Dropbox, an extremely popular concept. In fact, when we ask people, we find 70 or so percent of everybody in every audience is using Dropbox.
They had an idea. They tested it with a video ?? this is what we’re thinking of. But then they took 18 months to make sure that they had a product which could handle every single operating system and every device out there, so that when people started using it, they would find it immediately useful for all of their devices, and they would not be discouraged by a partially done product.
If you look at the success of Dropbox’s spread rapidly by word of mouth, they were very wise to wait 18 months before they put out something, because they felt like they had to have a complete thing. N that it’s there they still constantly change and improve and add-on to it. And similarly, you’ll find there are games out there that have been improved every year, once they’re first released.
So you have to use your head, you have to understand the market. You have to understand when something is correctly correct, and that’s why the Lean Startup says you have to have a minimum viable product. It has to be viable; it has to be something that is proper for whatever it is that you are doing in your market, and what makes sense in your context. Just to take a simple rule that works on the website and trying to apply it to a medical device is crazy. It doesn’t make any sense at all.
So you’re not going to be releasing a partially done medical device or programmer for a heartbeat pacemaker, you’re going to have a complete product. You’re going to have a different way of thinking about feedback.
That doesn’t mean that you don’t try to get it. It just means that when you release software, it has an awful lot to do with the world that you’re living in, and what your customers are expecting.
Joe: When I think about some of this, I think about clicking into empty 404s, and questions that always frustrate me on the web. Do you really think that is testing that should be done? To see which they’re going to choose from in that, so you can gather data? Or do you feel like that you should develop a product farther than that?
Mary: I think it depends. It depends on what your objective is, where you’re at, what kind of user base, you have, what makes sense in your context.
I know in his book Eric Ries said he spent two years developing something in a company he worked in ?? a company that failed, by the way. After it was completely perfect, they put in a button to click on and go see this brand new wonderful thing, and nobody clicked on it. If they’d have just put that button in a lot earlier, they would have known.
And it’s not going to a crash site; it’s bringing somebody to a partially done site that is not necessarily in all cases a bad idea, sometimes it might make a lot of sense.
Again, it’s going to depend on what world you’re in and what kind of thing you’re trying to accomplish.
Tom: A 404 is not very considerate; I agree with that. A message that says, “Under construction. If you would like to be notified when this feature is available please leave your email address” can be much better.
Joe: I like that better, yeah Tom I have to agree with that. You talked about knowledge workers, and the most effective motivator being making progress in meaningful work. It sounds good, but can you really do that? Isn’t there a certain amount of work that is just drudgery that you got to do?
Mary: Like for example?
Joe: Oh, I don’t know, taking the garbage out? Someone’s got to do it, right?
Mary: Once you get it out you feel really good about having it done. I mean, I don’t see why any kind of work can’t be created in such a way people make regular progress in these things that they are trying to accomplish, and you make sure the people know that.
If you read the book “The Progress Principle” it says that at least for the knowledge workers ?? and I’m not talking about taking out garbage; I’m talking about designing a new way of merchandising or something like that ?? you can really create an environment in which people make steady progress, understand that they make steady progress, have small accomplishments, have small times when they have a little setback, and then recovered from that.
I don’t understand why at least knowledge work can’t be made something where you have continuous small progress steps. I think it’s mostly a matter of work design, not the work itself.
Tom: It’s a matter of communicating why, not just what. A knowledge worker will apply their intelligence to achieve a lie, but if they’re simply told what to do without any idea of the purpose of it, they have no basis for applying any of their knowledge and experience and intelligence. So it becomes quite dull work.
So just doing what you’re told rather than helping people solve a problem is what the difference is between meaningful and not meaningful work.
Mary: We had a sunroom built on the front of our house, and I was watching the carpenters, and there were some really tricky measurements and window sizing that had to be made. T always paired up when they had a tricky thing to do. T would do some measurements and scratch their heads and discuss things. W the pair of them came up with the right answer; they would be, “got that one.”
I remember the group was focusing on making sure that when they cut lumber, they got the most out of every single board and had the least amount of scrap. Making progress towards getting our thing done, when they found just the right size board, so they wouldn’t have to waste any, “Hey, that was a win.” That was progress.
It doesn’t take much to have progress. It just says, our objective is to have the least amount of work, and I found the right size board for this piece of the window frame.
So it doesn’t take a lot to have progress, but you have to say, “I know why I’m supposed to have the least amount of lumber used. It’s so that we don’t waste it. So that we can make more money for our salaries, rather than pay for the materials.” Or whatever it is.
I don’t really think it’s hard to structure jobs around meaningful progress. It just takes thinking.
Joe: I think that’s a great analogy, and I have to add that “The Progress Principle” is one of the better books I’ve read recently. I think I actually listened to it first, and then went out and bought the book also.
So do you have a new book on the horizon? Or what’s on the horizon for the both of you?
Mary: Yes, we do. We are taking the next five or six months off and writing a new book. Currently, it has a working title of “The Lean Mindset” and it’s about how thinking in a Lean manner would apply to all aspects of developing software-intensive products.
Joe: How can someone contact you if they’re interested in learning more?
Mary: My email is mary@poppendieck.com, Tom’s is tom@poppendieck.com. So if you can spell Poppendieck, you can contact us. But I’ll spell it. P?O?P?P?E?N?D?I?E?C?K, and the rest is easy.
Joe: I would like to thank the both of you very much. I appreciate the conversation, and I look forward to hearing from you again sometime, and reading your book. You’ll have to put me on the list and come back on the podcast to explain the book a bit.
Mary: OK, sounds great. Thanks a lot.
Lean Sales and Marketing: Learn about using CAP-Do
Special Marketing with Lean Book and Program offers on Facebook
Joe: Thank you. This podcast will be available in the Business901 iTunes store and the Business901 blog site.