Start Stronger, Get Better, and Do More: A Conversation with James Sutton and Marc Danziger

Lean-Agile Straight Talk

Start Stronger, Get Better, and Do More: A Conversation with James Sutton and Marc Danziger

James Sutton, Marc Danziger, and Jim Trott talk about transformation, systems thinking, the borders that Agile erects that can inhibit scaling, coaching, and why Lean thinking requires you to start with understanding the existing culture.

Jim Sutton summarizes this as "Start Stronger, Get Better, and Do More." Start Stronger involves "how to start with much-better value candidates"; Get Better focuses on how to walk into a transformation; and Do More is the Lean principle of Perfection. This comes from their long experience with Lean, systems, and helping organizations and programs both large and small scale and succeed. With Lean thinking and Agile practices. Because the reality is that Agile transitions do not always scale up. As Jim Sutton says, success in a little thing does not mean you will have success just by doing more and more of that little thing. Scale requires more approaches, different kinds of thinking.

At first, I wondered if this would seem a little academic. But, as we got into it, it became apparent how helpful this is, especially to someone who is having to coach a transition in an organization. There is a lot to think about.

You can use the forums on the Net Objectives Portal to ask questions about the webinar. Note, you will have to register on the portal to do so.

Music used in this podcast: “And So It Begins” and “Easy Lemon” by Kevin MacLeod © Incompetech Inc.

Blog Type:

Podcast

Transcript

Introduction

In this show, Jim Sutton, Marc Danziger, and I talk about transformation, systems thinking, the borders that Agile erects that can inhibit scaling, coaching and why Lean thinking requires you to start with understanding the existing culture.

View Full Transcript

Jim Trott: It's September 8th, 2016. This show, "Start Stronger, Get Better, and Do More", with Jim Sutton and Marc Danziger.

[background music]

Jim: Hello. Welcome to another addition of "Lean?Agile Straight Talk", our regular podcast series from Net Objectives. I'm your host, Jim Trott. In this show, Jim Sutton, Marc Danziger, and I talk about transformation, systems thinking, the borders that Agile erects that can inhibit scaling, coaching and why Lean thinking requires you to start with understanding the existing culture.

Jim Sutton summarizes this as, "Start Stronger, Get Better, and Do More." What he means is Start stronger ?? how to start with much better value candidates. Getting better focuses on how to walk into a transformation. Do more is the Lean principle of perfection.

This comes from their long experience with Lean systems thinking and helping organizations and programs, both large and small, scale and succeed with Lean thinking and Agile practices, because the reality is that Agile transitions do not always scale up.

As Jim Sutton says, "Success in a little thing does not mean that you will have success just by doing more and more of that little thing. Scale requires more approaches, different kinds of thinking."

At first, I wondered if this would seem a little academic, but as we got into it, it became apparent how helpful this is, especially for someone who is having to coach a transition in an organization. There's just a lot to think about.

Before we get started, I want to remind you that you can explore more about this topic by jumping over to the resources section of www.netobjectives.com, or go into our new portal, portal.netobjectives.com.

At Net Objectives we're committed to discover effective software development methods, so that we can assist organizations in becoming more successful. We combine our experience to continuously extend the capability of what is possible in creating effective software development organizations.

We provide these approaches to our clients and the community in general so that we can assist people in achieving their goals and making their organizations more successful.

We welcome the chance to work with you. We're always learning and invite you to join in. Visit us at www.netobjectives.com. Please subscribe to the Lean Agile Straight Talk Podcast on iTunes and rate the show. It really helps. Let's keep the conversation going.

James Sutton is a senior consultant with Net Objectives. His special focus is on mission effectiveness of organizations by using Lean systems thinking at all levels and thereby making the workplace more joyous and energizing for everyone. James was among the first in the US to adopt Lean. Since then, he has led or helped project sized from thousands to billions of dollars. His work is described in his book, "Lean Software Strategies."

Mark Danziger is a leader, team builder, and technology visionary. He has successfully led programs for a wide range of clients from new startups to Fortune 100 companies. His core experiences in envisioning new products or systems, delivering technology, and process improvement. He's a certified Scrum master, a Scrum product owner, and a SAFe practitioner.

Welcome, Jim and Mark. Maybe you could start with some scenarios to help set up this interesting topic for us.

James Sutton: Sure, Jim. This is James Sutton. Hi, everyone. When we were talking about doing this topic, this is one that cuts across all sorts of people that we work with. In fact, across most organizations in the world and there this common desire to improve. Sometimes, that's under pressure.

For instance, let's say that you're a leader in a company that builds most of the software that you use. Then senior management says that the software's not coming out fast enough, it's not helping the bottom line of the company enough. You might even be under some kind of pressure, a real or implied threat about outsource.

In that kind of a scenario, oftentimes, there already have been some Agile adoption, maybe Scrum in some of the teams, and maybe you're thinking of scaling Agile up to the entire organization. We want to explore what does that mean and what are the limits of doing that and what are some of the alternatives and options or ways to augment what you've already done in Agile.

Marc, if you have a different scenario, did you want to just describe that?

Marc Danziger: Yeah. There's the negative and positive side of the same situation always. The positive side to me would be in either a large organization or a small one, we've implemented Scrum. We've got the basic ceremonies going, we're working in the iterations, we're working off of backlogs, we're showing our work, we've gotten some improvement from having done that. We're stuck there.

The idea of creating a massively high performance organization, which is what I think everybody started with, hasn't quite taken hold. The question then is, "Now, what?" You look around at each other, "We got this far. What's the next thing that we do to take us further?"

This would apply both in really large organizations I see whose interpretation of going Agile is entirely centered around Team Agile, where the actual development teams become little Agile times and not much else changes. Hypothetically, you're a 20?person start up and you've got Lean teams. You've got the teams working, but you're still not getting enough done. That becomes the question of, "Where do you go and how do you get this to work better?"

Jim: Sounds like really good scenarios to get us thinking about this. Let me just ask. In both of your scenarios, isn't it just efficient to scale up Scrum to get us to where we need to be? Can't we just scale up? That seems to be a common approach.

James: That's a common them that we hear a lot. Sometimes, it's called scaling up Agile. The whole idea of scaling from a systems perspective because, as Jim said, most of my background is in systems in Lean thinking and application. The whole idea of scaling itself in a system, it's quite an interesting thing to explore.

It's taken as an article of face in the Agile world that it is possible to scale Agile from the team level right on up to the executive suite. If you look at systems in general, you see something different. This idea of scaling, I could give an example of, for instance, let's say that you got a headache and you've got a bottle of ibuprofen.

Maybe you could take one ibuprofen and that would deal with the headache but the way that we tend to think if we apply this scaling thinking is, "Surely, four idea preference would be better than one." [laughs] Is that really true?

This shows that we think of things as being linear. If the little bit is good, then a whole lot more is better. In fact, the way most systems in the world work is something...I'll use a word and then explain it. it's called homices.

Basically, in pretty much any domain, if you look in the national institutes, the health, and other data?driven organizations where they've collected a lot of data about how do you change things and what are the effects of changing things, the homices is that usually if you do something and a little of it is good, it's kind of a new shaped curve or an in?shaped curve if you turn it upside down.

If you a little bit is good, you keep going, it gets a little better. Add a little more, it gets a little better. Then, at some point, it turns the corner and then it heads down drastically. In fact, the way that systems work normally is that if a little bit is good, a lot can be disastrous.

There is a saying in a very funny book called "Systemantics." If you check it out some time, it's by John Gall. It's very witty and clever and not at all a dry academic read. Gall. He's a real classic, very enjoyable, and full of insights.

Anyway, one of the principles in Systemantics says a large system produced by expanding the dimensions of a smaller system does not behave like the smaller system.

When we look at Agile, the idea of scaling up Agile, what it really says is that what works really well at the small scale, at the team level, be prepared, if you try to apply it at the very large level, for something that behaves very differently than what you experienced at the small scale.

Marc: The other question I'll raise is what does scaling Agile look like in an organization? What does it mean to scale Agile? We've got 30 developers who are working in teams of 6. What comes next? How do you move that agility out into the organization?

There's a couple things you can talk about. The way I look at it contextually talks about scaling backward, upward, and inward. Where do the teams get the backlogs of work that they're going to work on?

I worked in a company where they did a study, because management was really upset that it took them eight to nine months to get any work out of the development teams. The study showed that the development teams only had the work for two months.

The balance of the time was spent in strategy, executive decision making, economic and financial analysis, product definition, product redefinition, another round of product redefinition, product breakdown, and then giving it to the teams.

Taking a careful look at the product development stack in your organization which leads up to the Agile teams is one of the most valuable things I think any organization can do. In fact, I will often wind up recommending to organizations that before they even start talking about making their teams Agile, that they clean up the product stack.

The amount of lift they get from that is absolutely incredible. When you then turn around and stand up Agile teams who are burning clean fuel, who have good work to do, you get fairly dramatic performance.

Jim: We're talking about organizational breakout beyond Agile's borders. In what ways do you think that Agile has borders? We've all seen borders that come up through waterfall and other sorts of things. You don't think of Agile as being so constraining, but maybe it is.

Marc: Look at the history of Agile. It was designed and built by folks who typically worked in small development teams on highly defined projects, who didn't work in large institutional settings, and who basically could have the decision maker for the product, the person who was funding it, sit in the room with the development team.

That communication is what worked incredibly well. If you go back to Coplien's original paper, which I talk about all the bloody time, about Quattro Pro, which was written back in the '90s, what you found was that the CEO of Borland, whose name totally evades me...He was my friend's neighbor in Scotts Valley. I should know who he is.

Sat in with the team. He was readily available on an ongoing basis to make decisions, to expand requirements, to review work. When you can have that kind of access to decision makers who are really that present, you can do Scrum, you can do XP, you can do traditional Agile methodologies with a lot of success.

The problem you run into is the minute your organization is too big and the CEO is too busy or the Director of Product is too busy to join you on a regular basis...I now have what I'm going to call arms?length requirements where somebody thinks something up, they hand it to somebody else who researches it, expands it, helps define it, who hands it to somebody else who decomposes it, who hands it to a development team.

The person who decomposes it may be the product owner who works with the team, but I still have one or two hand?offs between the ultimate authority and the people doing the work. That's a very different kind of environment than Agile was really designed for.

Solving the problem of how you make sure you build the right thing, how you make sure you build the most valuable thing, how you make sure that what you're building actually reflects what the person who's writing the check was thinking, those are hard problems to solve.

In mainstream Scrum or in any mainstream Agile process, the answer for that is always conversation. What are these things? They're invitation for conversation. That's what a requirement is. What happens when there's no one to talk to? That's where Agile begins to run into limitations. That's one of the places.

James: Yeah, Marc. Agile, if you look at the manifesto, there's four major statements in there. Those tell us what Agile was really aiming at. They're all very powerful, very good.

The first one was about restoring the place for human judgment, because these big developments, big organizations, and then that trickled down, that whole approach, so that even small organizations were using the big organization approach, meaning Waterfall.

The place for human judgment kind of went away. There were all of these evaluation regimes like CMMI, ISO 9001 that said it's all about getting these processes baked and written out, and everybody's following it. That went so far.

When the people that got together at Snowbird back in 2001 and wrote the manifesto, this was the very first thing they said. Individuals and interactions over processes and tools. In other words, "Let's restore a place for human judgment."

Those conversations that you're talking about, let's give them a place for them to have an effect. If everything is all pre?worked out, then conversation maybe is almost irrelevant, because we're past that phase in the development.

Then the second one, working software over comprehensive documentation, which is all about getting the focus back on the product, less on descriptions or models of the product.

The third one, customer collaboration over contract negotiations. It's about having dynamic interactions with customers to improve mutual understanding and allow for quick course corrections.

The fourth one, responding to change over following a plan, adapting to circumstances instead of sticking with a plan that's not working.

Those four areas with the people that were coming, as you said Marc, often out of that environment where those were the very biggest concerns, they were focusing on human judgment, and product focused, and customer relationship, and adaptability, all of which are key at any scale or any scope. By no means do these cover everything that's important.

Marc: I think they do. I'm not challenging what you're saying, but I want to frame it a little bit differently. The principles set out there are the exact right principles. The problem is that in an organization where I have 800 developers, it's not very easy to manifest them.

You wind up with things like LeSS, which basically says, "Well, gosh, if my organization is too big and complicated to do these things in, I want to rescale or refactor the organization to make that possible." That's how I interpret LeSS. I'd love to hear if I'm right or wrong.

That doesn't really work. It's hard to go to corporate America and say, "What I really want you to do is break down into these little pods, and we're going to have the little pods do components of work that will organically grow together."

The problem is how do I deal with creating the kinds of conversations and the kind of human?centered interaction in a larger setting? That's one of the big challenges that you have to break out of because traditional Agile methods at the team level don't solve that problem within a large organization.

James: I don't want to give the wrong impression. I'm not saying that the Agile principles are not right. I'm just saying they're not complete. For instance, the product focus that comes out in most Agile techniques is more along the line of whatever we started with is the idea of the value that we want to develop. We give ourselves space to learn and to change as we go.

What it doesn't explicitly address, and nothing I've seen that is in that area addresses, is how do we find the optimal place to start from. There's this assumption that we really know what the value ought to be and, yes, we will learn and we will iterate from there. The assumption is that we kind of know what it is we need to do.

What Lean science has shown us in even the scientific method is that oftentimes we really don't have a clue of what it is we need to do. We need a better starting place. Agile is very complimentary to that idea, but we can find some really powerful techniques outside of the Agile universe for getting that seed crystal that we begin working with.

One of them is called the General Theory of Innovation. You can Google that. It's a guy named Greg Yezersky. He has taken a very scientific approach to finding that initial seed crystal. You can imagine that the further off that you begin away from where you need to end up, the more iterations and the longer it will take to get from here to there.

There's a lot of power in getting closer to what will end up being the actual value that you need to develop for your company, or your customer, or what have you. Then, use the Agile techniques to get the rest of the way.

Marc: I'll book?end it with the opposite method, which is IDEO's design thinking process. Which opens by saying the first thing I have to do is to empathize and really understand the person or people I'm building something for and really immerse myself in their world so that I can ultimately come out with solutions that are of value to them.

All of those things are part and parcel of building a front?end process that will ultimately feed good work to the Agile teams that are doing the work on the ground.

Jim: For our listener's benefit here, a technique that is really powerful for doing what Marc just described with IDEO is called the Value Proposition Canvas. That is all about asking very empathetic questions of our customers or stakeholders that do get us to their pain points and what they need the most.

He's right. That does book?end the General Theory of Innovation type approach, which is a harder, science?based approach.

Marc: The other access I talked about, and I don't know if, Jim, you're don talking about the front?end stuff, was going up. One of the hard things in software is that we have to orchestrate, in these larger enterprise systems, a lot of moving pieces.

As much as we talk about contained objects, and containerization, and clean interface driven software, we still wind up having to integrate tons and tons of stuff that is done by multiple teams at a time.

What we find is that the orchestration, which talks about the timing of when certain things are done, and the coordination of what work is done becomes an amazing challenge above Agile. I now have my Agile teams working. The problem is how do I orchestrate their work?

The school answer that I had learned a long time was we'll do Scrum of Scrums. My experience is that historically really hasn't worked for me. I don't know if it's worked for anyone else out there. I'd love to hear about it. It really does require something with more structure.

I'll use SAFe, scaled agile framework, as the baseline for what the current thinking about best practices around structure look like. It's my belief that the model of orchestration they have with release trains, with orchestrated releases, with deliver when done, release when the customer's ready is actually a pretty terrific model.

The idea of orchestrating multiple teams so that you can build bigger things is one of the challenges that we see endlessly in our big corporate clients. You can minimize it a little bit through your work breakdown and through the work you do in the front end. You can minimize it a little bit through architecture that decouples as much as possible.

If you're doing work in the real world, it's a problem you run into, and it's a problem that has to get dealt with in one way or another.

James: The whole idea of Scrum of Scrums is a great example of the idea of scaling up team?level Agile practices and trying to make them work at higher levels. You'll see even Scrum of Scrum of Scrums and that sort of thing.

Like I mentioned at the beginning of the talk, that's based on the idea that it actually will scale. Just like Marc's experience has been, and I'm sure many of the rest of us, that doesn't always work out so well.

I don't want to be critical of an approach, but I just want to point out that the LeSS approach is kind of a Scrum of Scrums based approach, or at least that's really heavy in the thinking.

If you're going at it from that angle, then you need to be very aware of the limitations of how far that metaphor can scale up.

Jim: It seems to me that, naively, one of the challenges with Scrum of Scrums is that I'm always having to invent. I used to work in aerospace, and if I was having to coordinate the building of a whole bunch of parts on the airplane as it's being built just with the Scrum of Scrums, it would be a disaster. There's a lot better techniques, I think, that we could use.

Marc: Yeah, definitely agree. Again, I it's a good idea, and there's a foundational interesting issue. I just finished reading this great book about the growth in the economy of the Bay area versus the decline in the economy in southern California where I live.

They powered past this one very fascinating point, which is how the counterculture of the '60s fed the technology boom that followed and how baked into our technology thinking a lot of very countercultural precepts are.

One of them is let people do their thing and good things happen. In fact, if you do that and you're in the Bay area, good things did happen. We have this antithesis to management, and money, and the business of software development that I feel is in a lot of the Agile culture.

Which is, on one hand, totally understandable, because developers have always been excluded from that. They're kept in a room, and they're fed, and they're supposed to deliver good work. They're not really embraced into being part of those things.

It also means that it's very hard for these developer?centric methods to work well in environments which are largely driven by management money. It'd be nice to find some things that split the middle there, if it were possible to do it. In the line of the famous movie, "No bucks, no Buck Rogers."

James: [laughs] I like that.

Marc: From the movie "The Right Stuff." I can have the best technology ideas and software ideas in the world, and if I can't get funding for it, nobody's going to let me build it.

Jim: If Agile doesn't really help or there needs to be more than that, what's your recommendation? What's your thinking?

James: Yeah, we sort of...Go ahead, Marc.

Marc: You first.

James: I was just going to say we already explored the idea of starting stronger. It's like compound interest, the old story about if you start putting money in, even a lump sum when you're age 21, then by the time you hit retirement, you got enormously more than if you wait until you're say age 28.

It's the same idea that if we start with more value, we end up with more value. I like the little acronym VIVO, value in, value out. The value you get out is proportional to the value that you put in. The next one, get better, is very interesting.

This gets in with the kind of software we're developing, what's appropriate for getting better. There's one major paradigm and it's applicable in relatively simple systems, or at least systems that are very well understood going in, where you have a very clear idea of where you want to end up.

Then you an assessment of where you're at. Then you map a path from where you're at to where you want to end up. That works in many systems, but a lot of the time, especially when we deal with trying to get a competitive advantage, we don't really know exactly what that end place looks like.

In the last five years, there's been a lot of work that has come out in the complexity theory world, particularly David Snowden, S?N?O?W?D?E?N, that says that there's another extreme that we can go to. That is we start out with really without a good idea of where we're going at all, but we do start with an assessment of where we're at.

Then we look at the circumstances that we're in. The way we do that is we collect as much information about stakeholders, for instance, about customers and their needs as we can, doing very little analysis, very little processing. Just put lots of little facts together and then take a look, like pieces of a mosaic or a piece of art.

We put all those pieces together and maybe collect the ones that are related to each other, and then we say, "What kind of world are we really in with our customers and how can we take a step a little bit closer towards that world? What is our next step?"

That allows for an exploratory wall through value. Agile's very good for supporting this because with iterations, we have time to reconsider frequently and repeatedly. Over time, the picture of where we actually need to end up to get that competitive advantage, it's a much better picture and much more powerful destination than it would have been if we had taken more of a rote approach to charting our path to get from here to there.

Marc: That ties a little bit to the way I look at it, which is again a little different from my experience. A lot about culture. Before I knew any methodology as a leader who was trying to solve problems, I tried hard to build good cultures. I didn't really know explicitly what they were. I knew it when I saw it.

I've learned a lot more since then. In fact, I've made a striking statement that's got me in trouble and I'll make it again because I like being controversial. If you have a super high?performing culture in your organization, you almost don't need methodology.

When the Miles Davis quintet gets up on stage, they don't need a score. They know each other so well. They know their instruments so well. They have such a great common sense of musicality that somebody can play one note, and they can take off and play off that for an hour. They could. They're not with us anymore.

Similarly, I've worked as part of super high?performance teams which largely did self?organize, where everybody had worked together enough and everybody had high enough levels of internal trust and confidence, and where people partitioned work on the fly. We got incredible amounts of work down with a minimal amount of methodology.

Things were tested. Things were documented. The basic, necessary outcomes were done, but they weren't very focused on the day?to?day "Tell us how to do what we do so we get good results."

One of the things I wonder sometimes ?? again, I'm going to try and write something about it because I'm not going to have trouble in the world ?? is the question of whether Agile methods are a scaffold or a cast around a group of people ideally aimed at helping them grow in a high?performing culture.

I talked a little bit about this in the last talk I did. I don't want to totally repeat myself, but these things are super important to me. Google did Project Aristotle. As you know, Google gathers data about everything everybody does. I'm sure they track bathroom visits by the hatch. They looked at high?performing teams and less high?performing teams and they tried to figure out what's the actual difference between the two?

What makes high?performing teams high?performing? They had a bunch of assumptions. In fact, the core thing which is common across every high?performing team was trust. This is one of the reasons why as managers who are leading a natural transformation, everything you do that kills trust destroys your transformation. Everything you do that builds trust furthers it.

The need to be attentive to culture and to look inward within your Agile organization for how you can take people who are doing the rituals and doing the right things, and how you can get them to communicate better, to trust each other more, to engage more with each other in their work and be more excited about it, are things that should be front of mind for every manager who's dealing with this.

I will argue ?? and I'm willing to bet a decently expensive dinner in Los Angeles, which is a pretty expensive dinner ?? that if you have an organization where those cultural norms are attended to, but some of the methodological ones aren't as mature, you'll get more performance out of your team. Performance being value delivered successfully, tested working code out the door that meets the requirements of the people who ask for it.

Then you will...Go ahead.

James: I was just going to say you've put your finger on a great example of why Agile, as good as it is, needs to be augmented. I have seen so many cases where the Agile implementation in an organization is actually very good, but the leaders have not shown themselves to be trustworthy.

In fact, it's still a very dangerous place for people to work. Even though they're doing all the right things, the communication has closed way down. As you said earlier in the call, communication is at the heart of Agile. Without that augmentation and...How do you build trust?

I used a model for building trust. It's from Steven Covey, the son not the dad. It's called "The Speed of Trust." Excellent book. He has a very, almost...What's the word for it? Step?by?step approach to building trust. There's all these components to it.

If you're not competent, you're not going to build trust. If you don't stick with your agreements, you're not going to build trust. On and on it goes. You can actually take that model and very proactively...if you feel as a leader like your trust is not as high as it needs to be or that your organization needs you to be more trusted, you can actually apply that model and begin to increase the level of trust or trustability.

Jim: It's maybe surprising to me to hear you guys talking about trust in the same context as Lean, but it seems like that's really an important thing. The other thing that strikes me is you're talking about cooperating with existing cultural norms rather than trying to change culture, as you're trying to get stronger, get better, and do more.

Marc: Exactly. Start where you're at and begin to move towards where you need to be.

James: I'll point out that in the reality of the kind of work that I've done, if I had ignored the existing culture, I would have been shown the door. I've seen people who do it. I've seen people who are change agents, either employees who have taken on the positive change or consultants who've been brought in to do change, who basically look at the current culture, wave it away, and start talking about the city on the hill they want everybody to build.

The reality is the existing culture eats them up, chews them, and spits them out. You have to accept an existing culture and understand an existing culture before you can even begin talking about changing it.

Anybody who's listening to this who's thinking about becoming a change agent ?? I'm hoping that's why you're involved in this stuff at all. The world needs a lot of change agents ?? you have to understand that to understand the existing culture, to work within the context of the existing culture, is not to accept the existing culture.

Jim: It takes a while. That organizational immune system rises up.

James: Yeah, it's true.

Marc: It's more than that. It's like there's this arrogance. There's a great quote from the guy who wrote "Lives of a Cell." Any time you walk into a complex system and start suggesting common sense fixes, they're virtually always wrong. They're wrong because you don't understand the system. You're ignoring the reality of what the system really is.

I'm completely sold on that notion. The systems that we deal with and organizations that are made up of people are immensely complicated and very subtle. If you walk in and just make a bunch of common sense declarations of, "Well, Just start trusting each other. As of Monday, everyone will just start trusting each other. We'll behave in a trustworthy way." You're basically talking nonsense.

James: This is another great example. We had talked a little bit earlier in the call about the idea of...in a simple system, you can come in with the end in mind and just chart your path to get from here to there. In the instance of an organization, it's not that simple.

You really do have to have a way to start...Certainly, a general idea of direction is good. We want to be more productive, we want to have higher quality, those kinds of things. We want to be a place that more people stay for longer periods of time. Those sorts of things.

Other than that, it's very much a discovery process. In the objectives, we have an approach called inflection points that helps us chart our path from one decision to another. The one I was describing earlier from the world of complexity and David Snowden is called sense making. There are approaches for discovering, in light of the culture that you find yourself in, how to get from here to there. It's important to do that.

Jim: It's more of a journey.

Marc: Right. The other comment you made about culture and Lean. I am not nearly the expert on Lean that Jim is, so I'm fully prepared to say something and get spanked for it here publicly. My understanding of Lean is Lean is premised very much on the idea that the people who do the work know how to do the work. That manager's job is to make their work simpler and better.

It starts with a level of respect for manufacturer's work. The stories that I've read in various books about Lean which focus on manufacturing talk very much about...there's a story in one book about how a Japanese company came to visit an American company that was advertising itself as Lean and was going to be a supplier to the Japanese company.

The Japanese visitors didn't want to go to the conference room and see the PowerPoint. They walked out on to the factory floor. They walked around for five minutes and they came in and they explained that they were done and they were leaving.

Management was aghast. They said, "Here's what we've seen. You as managers don't know your way around your own factory floor. We watched you interact with the people on the floor. You don't know the people on the floor. The people in return are acting as though they don't really care. They're smoking. They're not deeply engaged in their work."

In fact, in some of the classic charts where they talked about Lean, the factory's on top and the manager's on the bottom, as opposed to the more typical pyramid with the CEO's on the top and the people doing the work on the bottom. I actually like that visualization a lot. It makes a really key point about the fact that the people doing the work are the people we need to be supporting. They're not there to support management. Management's there to support them.

James: I've experienced exactly that, Marc. In a major corporation that I worked at in the past, the company hired a Lean...the lean trainer they call a sensei, which is a very rich word. I know you know this, Marc, because of your martial arts background. It's more than a trainer. It's a life advisor thing.

His whole approach with us is not about the Lean principles, which you learn about in the book "Lean Thinking," which are important, but it's a very Western way of looking. The people who actually originated lean, they start with culture.

The sensei came in and evaluated our culture and then basically roundly castigated management for not creating a good environment for work. That's another key of going beyond Agile. The things that are in an Agile coach are all very good and all necessary, but there's this extra factor that needs to be there. It's the sensei factor. It's the focus on the culture and on facilitating the movement of the culture towards a more humane and human?friendly culture where the work can be done.

Marc: Humane doesn't mean lazy and it doesn't mean lackadaisical. People want to work. My experience is that if people are given a chance to do meaningful work and to really excel at it, they get excited about that and they work really, really hard. That's awesome and that's how it ought to be.

The goal for managers ought to be creating a place where people want to put a hundred percent in, do great work, get excited about it, and are rewarded at the end of the day. Again, I don't see any contradiction between that kind of thinking and Lean.

James: Absolutely. The work that I've done, we routinely quadrupled productivity. We cut defects to a tenth of what they had been previously. There's lots of tangible effects of this kind of thinking. Think we said a lot about getting better. Jim, did you...?

Jim: There's a question that came in. This is pretty interesting about culture. If you guys could maybe talk about it for a second. What is culture? Is it beliefs? Prevalence of meetings or rituals or climate? Too much change may be really hard, but lots of things change easily at the team level. Whose beliefs are you really trying to change? Is it management or the team or what?

Marc: Jim, you want to go first?

James: No. I'd like for you to go first.

[laughter]

Jim: Easy question, Marc, so you get that one.

Marc: That's right, exactly. I'll get the softballs. [laughs] First of all, culture is a set of patterns of behavior that are usually tacit. They're not usually formally set out in laws or rule books. People who are together and work together typically will behave in many similar ways. It's an interesting thing.

I was in Idaho going river rafting with my kids. There's some important thing we didn't have that we needed. We went to Cabela's, which is a big hunting, outdoor store with lots of outdoor gear, very hunting?focused. We drive in the parking lot and every vehicle is a lifted pickup truck with certain classes of bumper stickers.

They're all dirty. They've been used. They're not driving around town. Cabela's didn't have what we needed. They sent us to REI, which was like three blocks away.

I'm three blocks away in the same city at another outdoor store, and the parking lot is full of Subarus ?? literally full of Subarus ?? with a whole different set of stickers on the backs of the cars.

What you found was that the culture of people who shop at Cabela's is very much aligned. They probably think a lot alike ?? they choose the same kinds of vehicles, they do the same kinds of activities. Based on the bumper stickers I saw they have a lot of very similar political and cultural beliefs.

Then when I go to REI I see Subarus, which are also capable outdoor vehicles, which people who backpack and kayak and that sort of stuff all use, but not a lot of...I think no pickup trucks in the REI parking lot. The bumper stickers were radically different than the bumper stickers I saw on the Cabela's parking lot.

The culture of REI shoppers is very different than the culture of Cabela's shoppers, even though both of them are deeply focused on doing stuff outdoors. If I go to a company I'll find that organizations have these patterns of behaviors that are very, very well established and are typically pervasive through the organization.

Again, they're totally separate from the rule book. When you look at people's sets of behavior, that tells you a lot about the organization. I hope I've defined culture well enough and haven't been over?vague about it.

James: That's exactly the way I think of it. I think of it as two things. It's a combination of behavioral norms and also shared beliefs. In any organization, alignment is very high on behavior or else people will leave, one way or another, but there's also memes.

For instance, in the political world you say, "You can't trust any politician." You've got a group of people that think that. Then you've got another group that says, "Government is where you can make a difference."

Obviously those memes lead to different behaviors, but if you look in the agile world, sometimes you'll see a meme that you can't trust any leader or you can't trust any manager. If that meme stays in place, even if you change the behavior, it's still going to work against new behaviors where it's advantage is it can actually contribute to health. You have to hit it high and hit it low.

I see we're almost out of time. We didn't get to do more yet, can I say just a word real quick about doing more?

Jim: Clearly this has been a conversation that needs to go on for another time. I want you to do the last word here and then we'll wrap up.

James: The idea of doing more here, I want to back up just a bit. In the Lean world, the Western Lean interpretation of Lean, which is basically replace mass production, and everywhere in the world, except in software, and it's making inroads in software.

There's five principles that have been identified a value stream flow polling, and perfection, and obviously, in two minutes I can't say much about that, but the one that is most neglected in the software world is the Lean Perfection principle, and there's nothing like it in the world of Agile. It is incredibly powerful. The idea in the perfection principle is actually two aspects.

One is to detect defects as quickly as they happen and remove them immediately, and there are some echoes of that in the Agile world. There's the other side of it is to preclude defects in the first place, and make it literally impossible as you develop a system to introduce whole classes of defects.

The way that works is what I've done with Lean programs before, is we did an analysis of the kinds of defects that we had experienced in the past, and we grouped those into classes, and then we asked a question for each kind of defect, what could we do to make that literally impossible or at least extremely difficult, or the workers on this program to introduce?

Then we used things like methods choice, architecture, language choice, standards, and many other ways to remove those. What happened was a defect that never goes in the first place never has to be reworked, and an enormous amount of labor is removed by that.

[background music]

James: I just barely cracked the door on that idea, but it's something that's very practical and is a little talk on that for the valuable things in Agile.

Jim: That wraps up the show for this time. Thanks for listening, and thanks for being involved. We welcome your feedback on what you heard and your suggestions for future topics. You can send a note to Al Shalloway at [e-mail] or to me, Jim Trott, @jim.trott, T?R?O?T?T, @netobjectives.com. We'll talk again.

Transcription by CastingWords

• Log in or register to post comments