Por: Mary Poppendieck     1380 visualizações     Tempo leitura: 46 min

Interview with Mary and Tom Poppendieck
Ask the right questions and be prepared for unexpected and intelligent answers

The Poppendieck surname gained notoriety in 2003 with the release of the award-winning book Lean Software Development: An Agile Toolkit, in which Mary and Tom discussed how lean principles, applicable in manufacturing, could be helpful in the software development environment.

The relentless success of this book has shed light on many issues that plagued managers and development teams over the past decade: outdated requirements, inconsistent systems, dissatisfied customers, lost business, and wasted money are just a few examples of this “wasted era.”

After the first best-seller, the successful trajectory of the couple Mary and Tom Poppendieck was consolidated with the publication of three more impressive works: Implementing Lean Software Development: From Concept to Cash, 2006; Leading Lean Software Development: Results are Not the Point, 2009; and Ask the Right Questions, 2013.

However, throughout this period, the term lean has been used indiscriminately. While some see in its principles a (non-exclusive) condition for organizations to thrive in business dynamics, based on an unprecedented technological advance, which had established itself in the new century, so many others distort its precepts and use the lean philosophy as a smokescreen for old practices upon a new terminology.

In an interview conceived to Rodrigo Aquino, director of Lean IT and one of the most considerable Brazilian references in Lean IT, Mary and Tom Poppendieck exude sympathy and vast knowledge when approaching sensitive topics for developers, managers, innovators, lovers of lean, but especially to the agilists on duty.

The effort to ask the right questions (even not sure about it) was rewarded by the best answers from these two world-renowned giants in the software and business industry.

Enjoy! Márcio Gandara.

 

Rodrigo Aquino: In the book, The Lean Mindset: Ask The Right Questions, you and Tom discuss the importance of a Lean Mindset so that organizations can be efficient but at the same time sustainable, which has nothing to do with cutting costs, reducing salaries, or outsource services. Can you tell us what it means to have a Lean Mindset?

 

Mary Poppendieck: I want to be a little careful with Lean because it's been in manufacturing, and then, in the early 2000s, it was adapted to the software world, when Agile was also adopted and used to solve the problems of the ’90s.

So it's come to mean sometimes high efficiency, laying people off practices that are specifically aimed at kind of various processes, like, say, Kanban cards or things like that. Sometimes, Lean is not thought of as a way of looking at the world as a set of principles for thinking.

I think it's important to think about Lean as a set of principles for thinking about how you attack the issues in your products in the job that you're trying to do, rather than a set of things that you do.

Even in manufacturing, Lean was misinterpreted as “Let's do what we see those other people do, instead of as interpreted as “I wonder how those people solve their problems, maybe we could solve ours the same way.”

If you think about Lean as a way to think about solving your problems, then you're not going to copy how other people solve their problems; you're going to look at how they think about improvement. Part of it is the focus on teaching people to solve the issues they have at hand.

And the second part about a Lean Mindset is having respect for people. One of the interesting things is that in Toyota, when they developed many of the Lean manufacturing processes, they were telling people who were working on the floor to figure out how to do things better. We're not going to give you a way to do it. We're not going to tell you the process. We're going to teach you how to solve problems, teach you how to run experiments.

And what we need to make sure of in Lean is we don't waste people's time, but we think of them as competent, grown-up Adults that we don't tell what to do. Instead, we teach them how to do problem-solving to solve their own problems.

The last part about Lean is how do you look at metrics. So, what do you measure? And Lean always focuses on customer-orientated metrics. Do we worry about when we talk about efficiency? Do we worry about how many of our resources we use up? Customers don't care about that. Customers care about how rapidly do we solve their problems. Can we do it at a price that they feel is adequate?

Our metrics are not resource efficiency, but how fast we respond to customer problems, how well do we respond to their price expectations? You have to think about Lean in terms of customer-orientated metrics.

So the concept of lean is not a set of things that you do. It's a set of ways to focus on customers. You make it an attractive place for people to work, challenging and engaging, and that you basically adopt and constantly improve, problem-solving attitude.

And you can get a lot of different things out of that. Many different practices come out of that. But as far as I look at Lean, that turns out to be pretty much the essential way of doing things and problem-solving. I mean, allowing the people who do the job to solve their own problems.

Tom Poppendieck: One of the purposes of metrics is to identified problems, identify opportunities, rather than create them. In many cases, metrics, if they are primarily based on financial returns, cause problems, drive bad decisions that discourage people, damaged people, and don't end up helping anybody but short-term owners and shareholders.

 

Rodrigo Aquino: When you talk about respect, Mary and Tom, it comes to my mind the five whys. When we ask the five whys, for example: Why? Why? Why?... Sometimes we may not demonstrate respect. We need to imagine another way to ask the five whys, but not precisely as prescribed.

 

Mary Poppendieck: Why Five? I mean, where did that come from? Maybe that's the correct number for the world that I live in! Perhaps I can figure it out just by looking at the situation.

Tom Poppendieck: Children are very good at asking why, why, why. What they're not very good at is trying to respond to the first why to shape the second why.

They're not very good at listening and trying to explain. And as people grow, as they become more mature, they get better at adapting or at complying. And complying is not the route to getting better.

 

Mary Poppendieck: The idea is to understand what's really causing something to take a systems view. And that is one tool or technique that has helped some teams. Actually, in our workshops, we found that when we tried to do the "five whys" exercises, they didn't work many times. They weren't helpful. We would find a problem: people don't want to do software testing, and then we would say, well, let's get to the root cause. They would try to march through five whys and wouldn't get close to the root cause.

But if you said, why really do you think people don't want "testing"? What's actually causing it? They knew. But the exercise kept them away from coming to that resolution.

Techniques like that might help, or they might not. But what you're trying to do is say, look at the whole system, don't just look at the tiny piece. Don't just take the first thing that you see and think about. The systems perspective may or may not use a tool such as five whys, but it won't avoid that we need to understand the cause if we are going to do something about it.

If we just look at symptoms, it doesn't help. Everybody knows that, but it's easier to look at symptoms than try to find the real problem.

Good problem-solving skills teach people, first of all, to understand and ask the fundamental question: What's really the problem? And not go on before they really understand the answer to that question.

 

Rodrigo Aquino: The current business world is highly dependent on technology, which naturally involves developing software and systems for the most diverse purposes. So, how critical do you consider the lean philosophy for organizations to be more competitive in this increasingly dynamic landscape driven by unprecedented technological advances?

 

Mary Poppendieck: A caution. I have found that some of the agile techniques (not lean, but agile), has completely avoided even talking about the fact that we are working in a deeply technical area. If you don't have technical skills, you actually can't start to address some of the issues.

You might have those things that I set up above: respect for people, very good problem-solving skills, and a good approach to metrics, which takes a systems view. But you also have to understand that when we're in a technology area like software, we are in a deeply technical area where technical skills are fundamental.

You can't forget about the architecture. One of the things we've learned over the last 20 years is that the architecture in the software of the 1990s is pretty much not relevant In 2020.

There used to be a metaphor called the Cathedral & the Bazaar. So the Cathedral (Notredame or something like that) is very structured and carefully architected. That's how our monoliths look. And that's how we used to build software, with a great big one description of what we wanted, with everything contained there. Figure it all out, write it all down, and make it happen. That was orchestrated by a small team of architects.

But when open source came in the ’90s, there was a book called The Cathedral & the Bazaar. The Bazaar is like a marketplace where you can think of little stands where people sell vegetables, clothing, and all sorts of things. And it can expand as big as you want. Just have some more space. There are some rules: that has to be on Tuesday, or maybe it's on Saturday, but that's when everybody comes, and the meats over here and the vegetables are there, or whatever.

But basically, every shop is its own shop. The shop owner makes their own decisions. They decide what to bring; they decide whether or not to go; they decide what to charge. All of the decisions are taken locally by the shop owner.

Now, today's architecture in software has moved from the Cathedral to the Bazaar. If you have a Cloud infrastructure, your software architecture needs to be bizarre style. And if your software architecture is bizarre style, market-style, then your organizational structure needs to be "bizarre style", because the software follows the communication path of the organization.

So, an organizational structure to allow small independent teams to make decisions is very important, and we cannot ignore it if we take a look at the system.

Another area that we need to think about is deep technical skills are necessary. Early in Agile, there was this idea that all you needed were generalists. And then they could figure things out. Well, let me ask you, Tom just had cataract surgery on his eyes, right? Would he have allowed a generalist surgeon to operate on his eyes? No.

When you have cataract surgery or any other kind, I want a specialist because you can't get really good at something very hard unless you have an awful lot of experience. And that's true in many, many areas of software.

It's true in areas of security and almost every area of software. Deep technical expertise is fundamental.

The idea that generalists can do everything is nonsense. We have this concept of a T-shaped person, which means they're very expert in some deep area but also able to understand a broader perspective.

And that's important. But we want to be sure that people really appreciate the deep technical skills that a very sophisticated, complex technical environment requires. You need some really good (technical) skills, not just superficial ones.

The other third thing that I would like to say in a deep technical area is that you have to be aware of proxies. You need to be careful about proxies. It's much better to have the team directly interact with the customer than have an intermediary. That goes in many areas of what we do. The more deeply technical you get, the more critical it is not to have proxies.

If we look at projects, they had things called cost, schedule, scope; and those were the important things. Why are they important? I mean, they're proxies for what you're trying to do.

They are maybe bad proxies. Who knows? Instead of having proxies in between a team and what it's trying to do, we need to connect teams directly with the people they're solving a problem for or the areas that they're solving a problem.

We need to stop having intermediaries. We have smart software engineers, smart designers, smart people that can form a team and directly get involved with the problem without intermediaries.

Unfortunately, Agile has traditionally introduced too many intermediaries. That's a hangover from the nineties and before. Another thing that a complex technical environment can't tolerate.

Tom Poppendieck: We've always been dealing with complex technical environments. In the ’80s and ’90s, the technical environments were more often mechanical. They were more often from the supply chain, were just as hard, and required just as deep an expertise, but a different kind of expertise.

The problems we face today are less often deeply mechanical or less often deeply supply chain related. They are still technical but require a different context today, different kinds of expertise, and different practices to deal with them effectively. So, it's more a matter of changing the focus than the complexity we have to deal with.

Back in the '60s, when I first started studying physics as a high school student, the complexity was to put a man on the moon.

Later, I worked with some of the people that worked on that project. And believe me, the complexity they dealt with, the competence that they displayed, matches anything that we have today. But it was a very different set of tools, very different context they had to work with. But as always, people work at the limits of the human mind's ability or groups of human minds.

What's changed is that the tools we have to think with are evolving, and we have to keep our practices to get the best results we can from the tools we currently have to think with. Today, as Mary mentioned, that tends to be cloud, artificial intelligence, perhaps.

Although I'll have more faith in artificial intelligence when I start seeing more of the real intelligence displayed. But we're still at the limits of what groups of people can accomplish with their human minds. And I don't think that's going to change.

 

Rodrigo Arquino: What do you think about the role of a flow manager? Does it make sense?

 

Mary Poppendieck: I have a different proposal than a flow manager. I believe that in most endeavors, what you want to do is run constant experiments to move things forward. I'm going to give you an example. The flow manager, in this case, is not a person, It's a set of integrating events. So, Let's look at SpaceX, alright! When SpaceX started, they decided to have space travel way less expensive. Therefore, they had to quit throwing everything away in every launch. They had to take their launch vehicles, bring them back down, land them, use them again, or never meet their costs.

Nobody had any idea how to land those rockets or what they should look like. They spent probably two years, in every maybe three or four months, doing a test launch, and you can see a video online. Have you ever seen it? All of those test launches? And they crashed! And then another one, and then it crashes. For many launches, they were not successful. But every three or four months, there was a launch.

There were lots of teams working on that launch. They all knew the date and the objective.  If it crashed, and the piece that you are responsible for had anything to do with that crash, you'd have 24 hours before calling Ellon Musk and say: "This is what happened, and this is how come it's never going to happen again". And it was those constant test launches that made them find the problems way faster than if they tried to think them all through or draw them out on paper. They test-launched, and they test-launched. And they got better and better and better.

So when you have a very large, complicated thing in a very sophisticated technology, maybe the best way to do it is to do it. This is really a standard engineering approach. You do it through three or four months interval integrating events, even if it's a five-year program. You know what you're going to do three months from now, and you test it. And those tests become your flow management. "This is what we're doing in January; this is our objective in June; this is what we could believe we can do in September. And then we'll figure out from there where to go based on how far we've come."

Management there is the integrating event that makes things synchronize. Now, if you have an Orchestra, and you want 50 people to play instruments together, you need a maestro. The Maestro is not an intermediary person but the one who keeps everybody together. If that's what the flow manager does, we know we need a maestro. And if the flow manager works like a maestro, this is okay.

But if the flow manager tells: "this is what you're supposed to be doing and tries to organize between everybody, that's not okay". So, when you have many people, you need a coordinating mechanism, but not an intermediary. The intermediary should be the actual experiment that people do, not the person.

Tom Poppendieck: Experiment only fails if nothing has been learned. The whole purpose of the experiment is to learn from it. The brilliance of good experiments is that they can be done quickly, cheaply and deliver as much learning as possible. Now, in the case of SpaceX, the size of the experiment is necessarily fairly large.

You can't learn from tiny little Rockets that you can build in an afternoon. In software, on the other hand, it's possible to conduct much faster experiments, small experiments very rapidly. That became obvious ten years ago when continuous integration became very viable.

Today, you can barely claim to be a software person if you're not using continuous integration.

 

 

Mary Poppendieck: Agile and Lean started 20 years ago in software. The idea that you could deploy stuff automatically with automatic testing down the pipeline didn't exist. It took ten years of thinking about solving this rapid deployment problem before the book Continuous Delivery came out. If you read the Continuous Delivery book's introduction, it was based on a question I asked in my first book: If you want to change one line of code in your software according to your normal process, how long does it take?

And back then, you couldn't do it for months. You had this big build process and all of that. I had coded in big process machines with software, 10, 20, and 30 years even before that.

If I needed to make a change, I could turn off that piece, make the change, test it, turn it back in, and I could do it in five minutes if I wanted to. And we had lost that, and we had these big build processes instead. And so in the '2000s, the concept of Lean means, Let's get back to the fact that if the customer has a problem and it's a one-line piece of code, we can solve it in five minutes.

And that took ten years to get our technology together even to consider continuous delivery in enterprises. Today, it's pretty common. The customer has a problem that anybody should be able to solve in five minutes. Why does it take five months?

Tom Poppendieck: Today's problem is not the flow of code requirements from some source to a team charged with implementing solving those requirements.

The problem today is discovering the problems, and no one person can do that. There's not even one technical specialty that can do that. Now that we can do the continuous integration and learn very fast, we need to put together groups of people who can jointly discover the real issues.

And the flow has to be done by groups of people that include not only technologically sophisticated people but also people that are subject matter. People responsible for an organization's operations, for making sure it's financially sustainable, that are well aware of the legal constraints the organization operates in, and many other areas.

The thing that's happening today sometimes is called digitization of organizations, which means that the silo of technical expertise does not require anything like somebody managing the flow of things into it or out of it.

It requires an interface between all of the capabilities that an organization can master and the marketplace they are addressing to be done as effectively as possible.

 

Rodrigo Aquino: You and Tom have traveled all over the world. What was the biggest gain have you seen in companies that used Lean?

 

Mary Poppendieck: We never acted as consultants, only teachers. We never stayed with a company very long. So, It's kind of hard to know any company that started with something called Lean, and then where they went. It's a hard question to answer, but I will talk about a couple of companies we did see.

Interestingly enough, the first one is called Tandberg. At the time, it was a small company in Norway that did video conferencing. We're on Zoom now, and the roots of Zoom lie in that company, but in their process, they've never heard of Agile, they've never heard of LEAN, and their process was amazing.

It was rapid and flexible. They could do a card with an ISIS chip, which is something that typically takes (just a chip) 12 months to design. And they were able to put a brand new product on with this very sophisticated chip on the market in nine months because they stopped sort halfway through an upgrade and said; Let's add that chip. They were very, very flexible, very customer orientated. And never heard of Lean and never heard of agile. They just were doing it.

Another company that I would say has one of the most lean software environments I know is AWS (Amazon Web Services).

Amazon Web Services never uses the term lean. Their processes are of all kinds that allow the team to determine and improve their own processes. Every one of their teams is formed by a small group of twelve, ten, six people, or something like that, with a customer focus metric that they're supposed to work together to improve it.

They have a team leader, sort of like a mini CEO or maybe the maestro. And they have whatever operational and technical and skills that they need to do their service, working with customer objectives and SLAs (Service Level Agreements).

Those are the things that they're expected to keep with their upstream customer and then supply the specs for their downstream customers. I have not seen a software company grow so big, so fast, and yet so flexible as Amazon Web Services.

If you think about it, there is a company that knows how to scale. We talk about scaling being a fantasy process. Well, that's wrong. Scaling is, actually, a lot of semi-autonomous teams that can make their own decisions and make stuff happen very rapidly. That is a much better concept of scaling than having a big, coordinated, orchestrated process. In the software world, that's the one that I see.

If you look at the roots of Amazon, it's in fulfillment. If you look at the things that have influenced fulfillment, it is basically a logistics concept.

All of the early stuff that Amazon did was based on Lean principles. Jeff Bezos even spent a week working in a factory, and he was working for a lean sensei. At one point, he went to sweep the warehouse floor. The Lean Sensei came up to him and said:  "Why are you sweeping the floor?" And he responded: "Because it needs cleaning". And he (the Lean Sensei) said: "Fine, but if you really wanted to do something useful, you would figure out why it gets dirty and keep that from happening."

So, he (Jeff Bezos), in the whole fulfillment area, use many Lean principles to figure out how to speed up and reduce lean cost, and you can tell they had no standard way to ship.

Every time I got a box, you can tell it came from a different team experimenting with a different way of driving down the cost of shipping. And to this day, I keep marveling at: "Oh, that's a new concept". How can you have a new concept in shipping? But every individual team has the authority and the expectation that they will constantly figure out how to make their area better.

I think that there are, definitely, lean principles that also influenced how AWS comes together. Aws is a lot of independent teams with no standard process, with customer focus metrics, and a lot of problem-solving, coaching, and help. Even though they don't use the term lean, I think that they're lean.

I already talked about SpaceX, another company that I think really knows how to put hardware and software together on a massively complex scale. And they drove down the cost of launching a rocket, in a factor of seven.

The cost of launching one kilo into space stayed at 18,000 US dollars per kilo for 30 years. Now it's seven times cheaper, and they did that in five years. Now anybody can launch anything into space because it is so inexpensive. They figured out how to drive down that. That was the objective. And they figured out that to be a space company, their customers couldn't tolerate the current costs. They to figured out how to do it cheaper.

That was their mantra, not because cheap was good, but because customers couldn't afford the current rates. They are now seven times cheaper and getting less expensive. All kinds of different companies can now launch a satellite up into space wherever they are. It's much more accessible because they focused a lot on the reusable stuff. That's a lean concept. Let's take a look at the whole system.

What are the limiting constraints that keep customers from being able to use what we have? How can we, even if it takes us ten years, change that dynamic?

Tom Poppendieck: I have never seen a successful lean company (if you define a Lean company as a company that does Lean practices). The reason is that practices are not Lean, even if some companies use them.

Looking at successful companies who apply lean thinking to develop their practices, they are typically very casual about permitting their competitors to come to see what they're doing because they know that their competitors will copy their practices. And when they copy their practices, they will fail. Because practices are not the thing, It's the thinking. It's the probing. It's the questions you ask and how you remove the obstacles preventing people from solving them. So there's not a Lean way.

There's a Toyota way. There's a Tandberg way. There’s Scania way. There's a Steelcase way. There is a John Doerr way. All different ways of applying lean values to different contexts, and different industries, at different times in the evolution of technology.

Mary Poppendieck: And I thought you were going to say: "you've never seen a lean company!" Because no company who's really lean is ever satisfied with where they're at. They always have so much further to improve, to be even close (to being Lean).

Tom Poppendieck: Even Toyota never wrote down the Toyota way because it would be different by the time they finish a book.

 

Rodrigo Aquino: How is the lean philosophy able to contribute to innovation?

 

Mary Poppendieck: Innovation, by definition, means something that didn't exist then comes to exist. Remember, we have all kinds of people in the world that are struggling with whatever problem, and lots of people are trying to come up with ways to solve it. Somehow only a few people do. Only a few companies do. But the companies that are really good at innovation don't have an innovation program. They figure out how to have a lot of minds trying a lot of experiments.

I was at 3M for 20 years, and in the time that I was there, they put just every year, many, many, many new products on the market. All sorts of various innovative products. And how they did it? They basically said, "anybody who has a good idea and can gather a team can spend some of their spare time figuring out how to make a product." And a product has its margins and uses some proprietary technology. And if you think you have a good idea, go for it.

There was a whole bunch of a lot of different minds that were turned loose to figure out for themselves what kinds of neat problems they might solve. When you try to coordinate and centralize innovation, it doesn't work. When you make it possible for all the smart people in the company to use their brains to come up with exciting ideas on how to solve customer problems or problems that potential customers might have, that's when you get innovation.

Innovation is about trying many things and keep improving.

The last thing about innovation is: innovation always requires people to think bigger on a system level. If you think about innovation, some of the time is bringing stuff in from other fields. I have a background in a different area, but if I look at my background and look at a problem, I could apply that (experience). Sometimes, it means taking a look at the problem, seeing a deeper problem, and attacking the deeper problem rather than the surface problem.

So, systems thinking is also an essential aspect of innovation. And thinking holistically, rather than focusing on just a piece.

Tom Poppendieck: A lean sensei does not give answers. A Lean sensei asks questions. The purpose of those questions is not to evoke an answer but to remove a barrier to the person's thinking.

The goal of innovation is to question your assumptions. To question them, you have to identify what assumptions you're actually making that keep you from thinking differently. Once you understand your questionable assumptions, then you are immediately free to think differently. And that is where innovation comes from.

Mary Poppendieck: Let me go back to the 2000s. I'd already been writing code in an engineering department (not an IT Department) where my software controlled big equipment for a couple of decades. And then I discovered that there was this process whereby people had these big projects and requirements. I thought, how could that possibly work? I had never seen that before because my background is in engineering programing, not IT programming.

I had been in a manufacturing plant where we instituted a just-in-time program, which eventually other people might call Lean, and it was phenomenally successful. We did it because we were in competition with the Japanese, making what we were making (videotape) much cheaper.

We needed to be able to figure out what they were doing so that we could compete. And we successfully did that. So, combining my manufacturing background with my programming experience, and watching how people were developing software in the late 1990s, was shocking. I took ideas from completely different domains and tried to apply them to software just to get people to think differently.

The idea is that today, we have developed some brand-new ideas about the right way to do things. And you know what? Most of them are wrong.

That's why I get a little worried about using Lean; because people have made it mean the wrong things. So you have to be careful with whatever you're doing. If the practices you're doing come from 10, 20 years ago and you're in software, they're out of date. You need to figure out how to take today's problems and look broader and more profound and say, what is wrong about these things that we've been doing? Where are they going off the rails? Where are they tripping us up?

Because we've now developed a new culture around Agile, and talk about problems with Agile. Why? Not because Agile is wrong or bad, but because it solves the problems of the 1990s. We need to solve 2020 problems. We don't need to solve 1990s problems anymore because our domain moves too fast. We need to look at what the issues are today. A lot is being invested in ways to solve the problems of 15 years ago. I assure you that the problems are different.

We need to get several steps backward, look at other fields and what they're doing, and how they're managing similar kinds of problems. That's where innovation comes from. We need to figure out where the future is going. Where are the young kids coming out of school going to be in 10 years?

 

Rodrigo Aquino: Whenever I'm with you two, I learn every minute. I believe you and Tom have already answered that question, but let's get to it. What advice would you give a manager who wants to start a lean journey in his organization?

Mary Poppendieck: We were at a conference in France, on Lean, in Paris, and some people from a Bank called ING, in the Netherlands were there, and they gave a talk. This was, maybe 10 years ago, or something like that. And during the talk, they said they had metrics they should meet, but everyone else below them would only have two metrics. Only two metrics.

The first was that you should make a code change every week.

And number two is: it is better not to cause any quality problems. They just said, "change something every week, and don't you dare have the system go down." That was their instructions to the people working for them. They said that the most interesting thing was that all of the metrics they were measuring started improving dramatically when we did that.

What I say is, don't pass on your metrics down to the people below you. Instead, challenge them in a way that will cause them to be creative and to be thoughtful.

They didn't even say what kind of change it had to be. They didn't tell them anything about the kind of change that was for them to figure out.

Let the smart people that work for you figure out what to do. Give them some freedom and something to energize and challenge them. Communicate the purpose, what you are trying to achieve, as opposed to the way you want them to behave or the things you want them to do. Communicate what's important about what your business is trying to deliver to customers and have them think about creative ways to do that instead of telling them how to solve problems. Let them be smart. And don't let your metrics get in the way.

 

Tom Poppendieck: One of the most critical roles of leadership and management is not telling people what to do but instead telling them what the constraints are, establishing the domain that their thinking needs to work in.

The basic role here is that anytime you have to think about a problem, you have assumptions about the nature of the problem, the nature of possible solutions: the software's capabilities, your customer's abilities to adapt to new ways of thinking. And those assumptions are usually both necessary and wrong. They change in time, and you have to enable them to change while leveraging them to maintain contact with the reality that the organization is working in.

Mary Poppendieck: And they must be valid restrictions. Once, we were in Rio at a television company (Globo), and they would broadcast the World Cup in 8 months. They would have to find a way to stream all the games dynamically in a way they've never done before and still write all the software to do it. And you know what?

They had a deadline, and that deadline wasn't going to move. All the time, many agile teams were asking to stretch the deadline, but the games were going to happen whether they were ready or not, so they had to be ready. Because of that constraint, this deadline doesn't move.

They had many other things that they were allowed to do because the deadline wasn't going to move. Nobody tried to tell them exactly how it was supposed to work. They were just supposed to make sure they were ready to broadcast the games on TV when the cup started, and at that level of restriction, they were very creative because they didn't have unnecessary restrictions.

And they were working really aggressively to find ways to prove they could do things and then improve what they did. And I'm sure when these games arrived, you saw them on TV. So, when you're in a business environment, there are some absolute that you can't change and you can't argue about, and then there are things that can.

You need to make sure that the true constraints are very clear and that any other artificial constraints are not there. You need to find out the most critical constraints.

You have to say: is money a real constraint, or is it just artificial? Is time a real constraint, or is it just artificial? In that case, it was certainly not artificial. Find out the most important constraint, and everything else is negotiable. And then make sure that people work within only the necessary constraints. But within those constraints, they need to deliver.

That way, you get very creative teams. Every person we talked to understood what they were doing. They simply couldn't wait to see the games broadcast on TV and were working to make that happen.

That was an excellent purpose they worked for. You need to communicate the purpose and constraints and make sure they are real constraints. Within those constraints, let the people there be as creative as possible.

Mary Poppendieck: The organization comes from integrated events. The integrating events are the things that will happen, whether you like it or not, on this particular date. That's your organizing principle.

I'm sure Globo did quite well because their organizing principle was to meet that deadline, have a secure mechanism, and make sure that they could stream much faster than when they started all of those things. And everybody was really excited about that. I'm not sure it mattered how organized they were, but I'm positive it mattered that they hit the deadline, had the streaming speed that they needed and were able to put those things on TV, and everybody would kill for that, and the rest, well! What's so important about the unimportant stuff? What matters is the outcome and the impact, not how you get there.

 

Rodrigo: Mary and Tom, every time I talk to you I learn a lot and I feel spectacular energy. I remember the last time I saw you at the airport. After almost seven years, you have not physically changed. It's impressive.

 

Mary Poppendieck: Do you have time for one more story?

Once, somebody came and said to me that testing was a waste. I said that, in software, testing is fundamental. But he said that everywhere, in lean, testing is a waste.

The problem is; in software, testing is designed. Think about double-entry bookkeeping. If you're an accountant, you have to do double-entry bookkeeping; otherwise, you can make way too many mistakes. Is double-entry bookkeeping a waste? No accounting firm in the world would say that double-entry bookkeeping is a waste. Testing and software is double-entry bookkeeping because you have a complex environment. You do things two different ways and always make sure that they match.

Your testing is actually the design of how you want it to work, but you automate it to run that test against the code. Then the code makes it work, and you run the two together all the time because you got your double-entry bookkeeping. I could remember being so frustrated because he was so sure that testing was a waste, and I was so certain that he was absolutely wrong, but I didn't know how to explain it (to him).

 

Rodrigo Aquino: I often say that when you test something, you have the opportunity to learn about your process and improve it.

 

Mary Poppendieck: I understand what you're saying, but you realize that, in continuous delivery, you write the code, send it down the pipeline, and it goes in. The only reason that works is that there's an automated test running all the way down the pipeline. Otherwise, it would be weeks of manual checking. The only way we can have rapid deployment into the cloud environment is because we have created a double-entry bookkeeping mechanism.

It's not just to test your process. Testing is a mechanism to allow our code, with a high degree of confidence and security, to be deployed immediately because we look at it from two perspectives all the time. We never have just one way of looking at it.

We always have it from two perspectives. It's exactly the way accounting works and why we trust it. We've automated because we're software people. We know how to automate things, right!

That automation in continuous delivery is one of the major advances from 2000 to 2010 or 2015 in software development. Even knowing it, all the years before, it never occurred to us to use our own tools to make it possible to know we haven't made a mistake.

Tom Poppendieck: But if you stop there, it's useless because it only lets you prove that the software does what you meant it to do. It doesn't prove that what you meant it to do works for the customer.

It doesn't prove that what you meant it to do works in the market. The advantage of continuous delivery that all of this automated software testing enables is that you can try things quickly, try them out in the market, try them out with a customer, try them out against the problem you're trying to address, and see if it works.

You get feedback rapidly. Not from the software, but more importantly, from the problem domain that you are addressing. As I mentioned earlier, the software is useless, except to the extent that it actually impacts the problem you're trying to fix, the opportunity you're trying to exploit. The only way to find that out is to try it.

Continuous delivery allows you to try it rapidly. Try lots of things and see what works, which is kind of the theme of the whole afternoon; try it and see what works.

Use your technological shops to do that as quickly and low cost as you can so that you can deliver a real impact that matters to the people who are the reason you're doing it.

Data da publicação: 12/04/2021

Gostou do artigo? Para receber nossos informativos click here.