How Agile Work Actually Works with Allen Holub

Episode 44

How do organizations actually work with Agile? In this episode of Programming Leadership, Marcus and his guest, Allen Holub, discuss what organizations get wrong about Agile. Allen has been an Agile transformation consultant for nearly 40 years and has seen the best and worst it has to offer. Luckily, he says the worst can be avoided. The challenge lies in company culture and architecture. The Agile way of working can be a shock to an organization’s system. However, those willing to suffer a few growing pains can reap tremendous rewards further down the line!

 

Show Notes

• Why Agile is failing (3:55)
• Teams are not Agile, organizations are (7:12)
• When Agile works (15:14)
• The inspect and adapt loop (26:21)
• Obstacles preventing organizations from being Agile (30:27)
• Why people can’t imagine work working differently (37:16)
• Advice for people realizing that they’re not actually Agile (39:46)
• Allen’s consulting strategy (43:13)

 

Links

• Toyota Kata, Mike Rother
• Follow Allen Holub on Twitter
• Holub.com
• Email Allen at allen@holub.com
• Schedule a video chat with Allen at holub.com/chat
• Agile and Lean Software Development Group on LinkedIn
• O’Reilly Infrastructure & Ops Conference: http://oreilly.com/infraops/blankenship

 

Transcript

Intro: Welcome to the Programming Leadership podcast where we help great coders become skilled leaders and build happy high performing software teams.

 

Marcus: Welcome to the episode. I am Marcus and I’m so excited to have Allen Holub on the show with me today. Allen, thank you for joining me.

 

Allen: You’re welcome. Glad to be here.

 

Marcus: As we get started here, I’m going to do a little bit of housekeeping. If you’re a fan of the show and you think with the work that we’re doing is good, would you support us by giving us a review wherever you listen to the podcast. The little stars or the numbers or the smiley faces, this seems to matter to the sponsors a lot, and it gives us feedback about which shows you enjoy and what’s working for you. So without feedback, it’s really hard to improve. We appreciate you as listeners giving that feedback to us. So wherever you are listening to this, hit the button and send us a little feedback today.

 

Marcus: All right Allen. So we are going to talk, we’re going to dive back into our conversation, and we were talking about the connection between the architecture of the system and the process by which it’s built. But I feel like this is a very meaty topic. So if you were to think about this, how should we frame kind of the introduction to this for the audience?

 

Allen: I just did a keynote to this effect for O’Reilly. It’s a software architecture conference. I called that one the three headed dog based on… In fact, I have a three headed dog. Oh, you can’t see me because you don’t have the video. But here’s my three headed dog.

 

Marcus: I can see that. And it’s true, he did. I’ll vouch for you.

 

Allen: Because everything is tied together into kind of one organism, right? So there’s architecture, and there’s process, and there’s the culture of the organization. And I might also add to that the physical plant, the place where you actually put the software together. It’s a factory there. People don’t understand the connections. So what ends up happening is if you were, for instance, adopting Agile, which a lot of people seem to be doing nowadays. In order for Agile to work, you have to have an organizational culture that supports that. Everybody understands that. But you also have to have an architecture that supports an Agile way of working.

 

Allen: So for example, if your architecture is a big end to your architecture, which is really dependent on a lot of isolated silos working together in effective ways, you start doing Agile things, which requires you to have these narrow vertical slices through the system that go from the UI all the way down to the hardware. And all of a sudden the communication paths within the system are not helping, right? They’re causing delays and so forth. So what that means is that if you have a big interior architecture, no matter how well it’s working, if you tried to change to an Agile process, that architecture is going to be working against you and it’s going to prevent you from being agile at all because you don’t have the speed that you need to be agile, right?

 

Allen: Agile is all about that fast, inspect and adapt loop. It’s all about learning. It’s all about learning by getting some code written and getting it into your user’s hands and getting feedback, and then adjusting what you’re doing based on that feedback. And that loop is a couple of days long on the outside. So if it takes two or three days to communicate with the database group, you clearly can’t have a three day long inspect and adapt cycle because there’s all these delays in the way of that communication. It’s just not going to work. Everything is connected.

 

Marcus: All right, Allen. Well first I want to introduce Allen’s bird in the background. You may hear him. This is Cranberry. Him or her, I’m not a bird specialist. I can’t tell by the squawking, but this bird is joining into the conversation. So if you hear the occasional honker squeak, it’s Cranberry, and just know that’s what’s happening.

 

Allen: I’ll try to get you a picture of him.

 

Marcus: Exactly. We’ll put that on the website. Now, Allen, this is kind of contradictory, what you’re saying, to some. I mean it makes sense, but I don’t see it in practice very often. I hear the end tier people who has the database team and the front-end team and the backend team, and maybe I’m not describing end tier very well, but those are just a couple of examples.

 

Allen: No, that’s really good.

 

Marcus: And I hear them say, “Well as long as each team is agile within itself.” So the front-end team just needs to work in stories, and then the backend team just needs to work in stories, so then we’re all being agile. But yours-

 

Allen: This is why Agile is failing. This is why there’s so many dark Agile shops. So many fake Agile shops. So many shops that have bought into the sort of Agile industrial complex party line about Agile is nothing but a process that you do on the team. And if you hire us, expensive consultants, to teach that to your teams, you’ll be agile. And that’s just nonsensical. Is that Agile is about being agile, literally about being agile. It’s being able to accommodate change, and it has nothing to do with Scrum and SAFe and all that garbage. That’s just entirely beside the point stuff.

 

Allen: So our goal here is to be agile with lowercase A. Our goal is to be able to accommodate changes quickly and at the same time, that goal is based on a realization that we cannot gather requirements effectively upfront because we learn as we work. Everybody thinks they know what they want, but they don’t actually know what they want until they start using something.

 

Allen: So until you get something that’s still in somebody’s hands, you can’t get the feedback that you need to actually figure out what to build. So in order to do that though, that implies things like these tight inspect-adapt loops, right? Where you build a little bit and then get some feedback, and build a little more, right? The best way to do this is that if you actually have a customer in the room with you, you can work a little bit and you can say, “Hey Fred, come over here, take a look at this. Is this okay?” Right? And then based on that feedback, you can change what you’re doing.

 

Allen: So the idea is to get to the best possible result by getting as much feedback possible while you are working. And if you can’t do that, you can’t be agile in any real sense. And all of that other junk, Scrum and SAFe and all that stuff, those are all layers around that core way of working that are supposed to make it work better, but they mostly don’t, right? SAFe is the opposite of Agile, and SAFe is not Agile at all. Scrum can be Agile. Scrum is an Agile process. So in theory, if you’re doing Scrum, you’re also doing all of the Agile stuff. You understand the Agile manifesto and you’re doing all this stuff that’s in there, right?

 

Allen: But Scrum is very, very lightweight, although it has a lightweight team structure, right? The SM and the PO and the dev team. It has a very lightweight set of ceremonies that you can do. But that’s kind of trivia, is that you can get by just fine without those ceremonies or without that particular structure and stuff. But we’re talking about Scrum work is not Scrum. If Scrum works, it works because it’s Agile, and then you’ve layered the Scrum stuff on top of it because it makes you feel good or something. I don’t know why you would care, but they are, right? You certainly don’t need it. To put it in another way, Scrum won’t work without Agile, but Agile works just fine without Scrum.

 

Marcus: I wondered if there was that kind of thing happening.

 

Allen: Right. All of that stuff ultimately just doesn’t matter. At least it doesn’t matter to me. What matters is getting that tight feedback loop.

 

Marcus: So if I’ve got a team, and I’m sure that somebody is listening, and I have a couple people in mind, so if you’re one of them, I know you’re listening, and you’ve got these siloed teams and every team is Agile and the front-end and the backend seems like a great example.

 

Allen: Let’s stop right there. Teams are not Agile, organizations are.

 

Marcus: Say more.

 

Allen: Okay? That’s important.

 

Marcus: Say more about that. Yeah.

 

Allen: In order to be Agile, the whole organization has to work in a way that supports that feedback loop.

 

Marcus: The whole organization? The marketing department?

 

Allen: Let’s think about it for a second, right? Let’s say that you’ve got an Agile team that needs to get permission from a database group to make changes from the database, and they need to get permission from a UX UI group in order to make changes to that. And they have to get permission from some kind of framework group or another to be able to make a minor change to the framework so they can get done what they need to get done. So you’ve got four external dependencies there. Four, did I count right? Three or four-

 

Marcus: You’ve got the main team and then three external dependencies. Yeah.

 

Allen: Right. So four. Every one of those, there’s wait time involved, right? So I can do a little work and then I’ve got to stop, and I’ve got to wait to get some kind of response from another team before I can keep working, and then I have to stop. So what that means is that all of that delay time is in between you doing the work and you getting the stuff into your customer’s hands so that you can get feedback.

 

Allen: So instead of being able to get things in your customer’s hands in a few days, it’s going to take a few weeks by the time you incorporate all of this delay into it. And the delay is expensive, right? If you learn Lean, there’s a whole cost of delay thing. Delay is really expensive. But more to the point, Jerry Weinberg in one of his books made a claim, which has been backed up with a lot of research since then, which is the number of projects that you work on simultaneously impacts your productivity in serious ways. If you only work on one project at a time, we’ll set the productivity at 100%. If you’re working on five projects simultaneously, your productivity is reduced by 80%.

 

Marcus: Wow.

 

Allen: Right. So you’re only doing one fifth the work you could otherwise be doing just by working on five things at the same time. So all of those delays, right? People say, “Oh, it’s no problem. I’ll work on something else.” Well, that doesn’t work. It doesn’t help you. Right? So the only way you can get stuff into your users’ hands quickly enough is to work on one thing at a time and have complete control over everything you need to have control over to get the code into your user’s hands.

 

Marcus: This reminds me of… Johanna Rothman hates WIP, she hates work in progress, it’s her big anti-pattern that she’s… So I feel like every time there’s that delay of while I’m waiting for the database group, what do we do? Well, we have to remain efficient, so we start another story. We take another task.

 

Allen: Right. But that doesn’t help your efficiency, every time you do that, it drops your efficiency by another 20%. So you can’t be doing that, you’ve got to be working on one thing. But getting back to the original notion of process and stuff and how it all connects, that means you have to have an honest to God cross-functional team. So you have to have literally all of the skills on the team that you need to get an idea into your user’s hands. And that involves UX skills and it involves database skills and involves testing and it involves everything else that is normally in these silos. So if you’re going to work in an Agile way effectively, you have to get rid of all of these organizational silos, because otherwise the delays will be so long that you can’t be Agile in any kind of realistic sense of the word.

 

Allen: And then you start banging up against Conway’s Law, right? Conway’s Law which says that the structure of the organization or the structure of the communication paths within the organization control the structure of the systems that the organization produces. Software systems is just one kind of system, but it is a system. So if you have a bunch of groups that are in silos, you can only talk effectively to people that are in the same silo because you’re sitting with them. And communication between silos is difficult. So if you’re coding, you’re going to want to write as much code as possible that’s focused on the silo. That gives you an interior architecture.

 

Marcus: And you’re going to want a contract or something that feels very formal.

 

Allen: Some sort of contract and interface between the silos. And you’ll have that same kind of interface in place between the tiers. There’s going to be a one-to-one mapping from the end tiers to the silos. If you go to an Agile arrangement with a cross-functional team, where everybody’s, “You need us on the team.” You don’t have the silos anymore. Those contracts go away. You don’t want the program organized into those layers anymore because the layering is actually artificial and it’s causing you problems when you’re trying to work on an entire story. So the whole architecture [Cranberry squawking]-

 

Marcus: That was a loud squeak from Cranberry.

 

Allen: The more I talk, the more noise he’s going to make. And so you have this situation then where if you’re working in an Agile way, you need an architecture that supports working in an Agile way, where the individual teams can work on their little corner of the application without stepping on the toes of other people that are working elsewhere in the application.

 

Allen: And that drives you naturally towards things like microservices because they are so tightly focused and so strongly abstracted, right? Is when you’re working in a microservice, that microservice has little or no connection to other services in terms of the workflow. So you’re not impacting other teams at all. It’d be rare for two teams to be working in the same microservice at the same time. It’s possible, but it’s not nearly as common as two teams having to work on the database at the same time. The deterrents are much larger.

 

Allen: So we have all these connections then. We’ve got this cultural issue. We’ve got the tier issue, the organizational structure issue. We’ve got the architectural issues in terms of microservices, there’s non-microservices. There are physical issues. Physical plant issues, right? If you’re going to be working in an Agile way, well that’s a collaborative way of working no matter how you collaborate. If you go with mob programming at one extreme, which I really like, I’m a huge fan of mob programming, but that’s really collaborative.

 

Allen: The other extreme, you’ve got pair programming, right? If you’re just working as a bunch of individuals sitting next to each other, you’re not collaborating at all. So I would argue that any team that is just working as a bunch of isolated individuals is not really an Agile team at all because there’s no cooperation.

 

Marcus: Maybe not even a team of any kind.

 

Allen: Yeah, a team of any kind. Exactly. It’s just because there’s no collaboration going on. But that’s noisy, right? So you’ve got these big open space offices and everybody’s afraid to make noise because they don’t want to bother the person next to them. And that’s a huge problem. So now all of a sudden you’re saying, “Okay, if we’re going to be Agile, the teams have to have their own space. And there has to be a door on that space so they can close the door and make a lot of noise and not bother people.” So the open office goes, everything changes. Everything has to change.

 

Marcus: It’s a big change. What you’re saying is a big change.

 

Allen: It’s a big deal.

 

Marcus: Frankly, I’m having a little empathy for these people who are trying to do something good with Agile and they said, “Well, I’ll make the team Agile. I’ll make the front-end team Agile, and the backend team.” I mean, they were doing something, they had probably good aspirations and good ideas. They probably just didn’t realize how deep these ideas go in the organization.

 

Allen: Well yeah, it’s true. And the other issue too, of course, if you have a team that says, “Oh, we’re going to be Agile.” I don’t even know what that means. Right? For a team to be Agile, what does that mean? Simply having a Scrum master and a product owner and a backlog is not going to make you Agile. In the actual definition of the word, right? The dictionary definition of the word. But a lot of people think that’s what it means, right?

 

Allen: A great quote from Andy Hunt, he said, “Agile has come to me. Do half of Scrum badly and use JIRA.” And he’s kind of right. There are a lot of people that actually believe that, “We’re Agile, we’re using JIRA.” Right? I could go on for a long time about JIRA, but JIRA is an anti-pattern in the Agile world. JIRA is a ticketing system. It’s designed for bug tracking. It’s not designed for processing stories or handling stories. So all of the statistics and stuff that JIRA gives you are of almost no value if you’re talking about real agility, if we’re talking about getting value into our users hands.

 

Marcus: So we’ve been talking about these anti-patterns. Let’s turn now… I mean, not turn, but I’d love to hear some of the… Tell us a story or give us a description of a situation where it’s working well.

 

Allen: There’s lots of places where Agile is working well.

 

Marcus: Is there?

 

Allen: Big companies and small companies and everything in between, right?

 

Marcus: Okay.

 

Allen: Let me say, to start off with, there is not a single highly functioning Agile software company that is using SAFe. Not a single one. Twitter and Facebook and Spotify and Microsoft, none of those companies are using SAFe. So it’s got nothing to do with that. When we’re talking about big scaling things-

 

Marcus: And SAFe means is the Scaled Agile Framework for enterprise or something like that?

 

Allen: Yeah. And if they just called it the SFe, left the A out, just called it the scaled framework. Okay, fine. But it’s not Agile. It’s not Agile by any definition of the word. A lot of companies that are fully Agile are small ones, they’re startups, right? I live in the San Francisco area, so I tend to have a lot of connections with startups, but I do work with occasional big companies in all sorts of industries, banks and medical companies. I’ve done some work for Viva. And the issue there is that the ones that are actually Agile are probably not following any of these particular frameworks. But they’re working in a way that allows them to get feedback easily. That comes back to that core issue in technical Agile is getting feedback quickly.

 

Allen: Around here, the bigger companies are Salesforce and Spotify has an office. They’re good sized companies that are doing things a very Agile way. Basecamp comes to mind. There’s a big bank in New Zealand, ANZ bank, that just went fully Agile in a very controversial way.

 

Marcus: Really?

 

Allen: Well what they did is that they did it right, in the sense that the C-level spent some time and really understood, really learned what it meant to be Agile. And they thought, “Okay, now we’ve got to do this, but so much stuff has to change that we just cannot do this incrementally.” And they did a big bang switchover for an entire bank. They switched over in like a year. It was enormously disruptive and they had to get laws changed because people were middle-management. There’s almost no use for middle management in an actual shop.

 

Allen: Scrum does not have a project manager role. That’s on purpose. If you go into a shop and you say, “Oh, we’re a Scrum shop.” And you look around and there’s a project manager attached to every team, you know they’re not a Scrum shop. That’s just not possible because there is no manager role in Scrum. If you’re doing Scrum, there aren’t any of those. There are other things. The teams manage their own work.

 

Allen: So what do you do with all of these middle managers that used to be around doing that stuff? And ANZ said, “Well, you guys, we’re not going to fire you, but you either have to get with the program or leave voluntarily. So we’ll train you to do something else. You’ve got a bunch of good skills, we can put you to work inside the organization but not as project managers because we’re not going to have those anymore. The job is going to go away.” There were like lawsuits and labor issues-

 

Marcus: I bet.

 

Allen: … and all these other stuff, and the bank saw it through. They said, “This is what we’re going to do and we have the right to restructure ourselves as we see fit.” And they won that one, and they did it. That was pretty impressive. I don’t know that that’s the best way to do it, I think you can do it in an incremental way, but if we’re talking about big organizational wide changes that impact everything, that’s probably the most efficient way to do it from a money point of view. If you do something incrementally, it applies to architecture too, right? If you try and change your architecture incrementally because you’re afraid of something, you can do that, but it’s going to be probably an order of magnitude more expensive to do that than it would’ve been to just rewrite it. Right?

 

Allen: And people are afraid of rewriting for some reason. My experience has been when there’s a lot of fear of rewriting, it’s because the company isn’t Agile, and if I go into that company as a consultant and look around and I say, “There’s a bunch of low hanging fruit here. And we could just make a few minor tweaks and probably free up half of the time that your people are spending working on the existing system to work on a rewrite instead. And so it won’t cost you anything compared to what you’ve got now to do the rewrite.”

 

Allen: Spotify has done, I believe, three rewrites at this point. The first one they just said, “Okay, people are happy enough with the player, let’s just leave it alone for a year and we’ll spend that time… We’ll put a skeleton crew on it and let them maintain it, meanwhile we’ll rewrite it from scratch, from the bottom up.” And Microsoft does that every time they do a major release of a big product. People don’t think about it that way, but that’s what it is. And Apple does it that way. All the big companies understand this. And they don’t mess around with these little incremental tweaks here and there. They know that that’s not cost-effective. So the same applies with transitioning over to Agile, is that if you do it all at once, it’s enormously disruptive, but it’s cheaper.

 

Marcus: But it’s cheaper. But it’s painful, right?

 

Allen: It’s painful, but it’s cheaper.

 

Marcus: You pull the bandaid off fast, it’s going to hurt.

 

Allen: Right.

 

Marcus: I want to go back to something you said. You mentioned that these CEOs did it right in the New Zealand bank because you said that they got training, that they really embodied, they really adopted, I guess, the Agile mindset from the very top.

 

Allen: Yeah, from the very top.

 

Marcus: Do you see that this is like understanding what it means to be Agile at the top layers of the executives is generally… That deficiency is a big problem with people or I’m sorry, huge problem.

 

Allen: Not understanding it is a huge problem.

 

Marcus: Yeah. Yeah.

 

Allen: Again, there’s all these connected organization-wide changes that have to happen. And whether they happen all at once or whether they happen incrementally, it doesn’t matter, they’re all going to have to happen eventually. And if you have somebody pushing back against them, because I don’t understand the why, then they’re not going to happen. If the CEO is saying, “We’re not going to do that.” I remember I went into a client, a couple years ago now, and I almost lost this job. This was one of these things where I had a conversation in the cafe with the person I was going to… Talking with the client before I had even started to work. I thought we were just talking as a couple of buddies sitting in the cafe having breakfast.

 

Allen: And then we came away with that and they said, “We don’t want this guy, we’re going to fire him.” What I was saying were things like, “Well, if we’re going to do mob programming across the organization, we’ve got to set up a space where they can do that because it’ll impact their ability to mob effectively.” They’re going, “Oh my God, we can’t give conference rooms to teams.” There was all this craziness surrounding that. All of this, “We’re organized in a certain way and we’re kind of settled into that way and we’re comfortable with it. And yeah, we hired you to come in and teach us a new way, but we don’t really want to change anything.”

 

Marcus: Not too much.

 

Allen: Not too much, yeah. But what I’m saying is, “Okay, so we can do mob programming” and that’s fine, but then you’re going to be in a situation where you’ve got five mobs all working in the same space, all making huge amounts of noise. And you have two choices there, is that you can put up with it and some companies do. Hunter Labs is the company that Woody started doing mob programming with, and they’re still mob programming with, I think, six or seven teams in a big room. One big room.

 

Marcus: I bet that’s loud.

 

Allen: It’s loud, yeah. But they’ve learned to love it, as they put up with it. But often the best way to do mobbing is to put every team in its own space. So you can’t do one without the other though. Instead of you saying, “Okay, we’re going to do mobbing, then you’ve got to start thinking, okay, how do we make that effective?” How do we support the teams in such a way that they can do this new technique as effectively as possible rather than having to fight the environment and that sort of thing in order to do the work that they’re doing. Getting back to where we started, I remember if you don’t-

 

Marcus: Architecture and-

 

Allen: If the guy is on top or the men and women on top, don’t understand them, they’re not going to support it.

 

Announcer: Be part of the inaugural O’Reilly Infrastructure & Ops Conference, happening June 15–18, 2020 in Santa Clara, California. Get the training and tools you need to successfully manage existing legacy systems while migrating to more modern and responsive, predictive, scalable, and cost-effective infrastructure—without interrupting your day-to-day business.

 

In addition to talks from leaders at top companies like Netflix, American Express, and Honeycomb, you can go hands-on with experts like Sam Newman and Liz Rice in one- and two-day training courses. Thinking about getting your Certified Kubernetes Application Developer (CKAD) certification? Take a prep course during the conference to make sure you pass on your first go. O’Reilly has made it easy for you to make the most of your time at Infrastructure & Ops by following one of seven new learning paths. These provide a distinct chronological path to gain a solid understanding of a specific topic, including Kubernetes, microservices, AI, and security. Plus, there are plenty of great opportunities to connect with like-minded peers at events like Architectural Katas, Speed Networking, O’Reilly Author Book Signings, the Expo Hall Reception and more. Register for the first O’Reilly Infrastructure & Ops Conference today, and enjoy worry-free cancellation before May 15. Visit oreilly.com/infraops/blankenship

 

Marcus: I remember when I was at a company and it’s been a while, 20 years ago. I had just read Kent’s book, Extreme Programming Explained, and I was very lit up. And I went to my boss and I was a development team lead and I said, “We need to be this, we need to spread this out.” And the business analyst group said, “You guys can run off and do your little Agile thing and we’ll just keep sending you the 100 page spec. We don’t care how it gets done.” So it was very much seen as like a local implementation detail for how software was written. And you might not be surprised to hear that it didn’t really change anything.

 

Allen: Right. Of course not. Right. But that’s common. Right? That’s commonplace, what you’re describing there. This thinking that the Agile stuff is all concentrated on the sort of how we get Waterfall. They see it as a way of getting Waterfall done better.

 

Marcus: Right. We’ll put the Agile in the middle of the Waterfall, right?

 

Allen: Right. A Waterscrummerfall, right? It doesn’t really work, of course when you try and do that. For one thing, you don’t have the support that you need, for another, you’re wasting huge amounts of effort, just puts you back against the outside organization all the time. You don’t get the tools that you need. You’re forced to do a bunch of Mickey Mouse garbage like meetings and reports and all this junk that’s getting in the way of you getting stuff out the door. It’s actually hurting your effectiveness.

 

Marcus: I think the thing that hit me so much that you said so clearly, was the idea of, you really don’t know what you want. 100 page BRD has clearly had a lot of thought put into it, but I found it was actually always wrong.

 

Allen: It’s always wrong.

 

Marcus: No shocker there. The question is only, in what ways is it wrong and how much is it wrong? And then even if it’s in the business analyst’s mind in a way that is somewhat less wrong, once it hits the paper, it’s wronger, and once it gets into the programmer’s mind, it’s so far from what was envisioned.

 

Allen: Right. But more importantly, once it gets into the hands of your customers, it’s so far from what they were envisioning.

 

Marcus: Right. Exactly.

 

Allen: Right. So you’ve got to think about the business cases. If you’re going to transition to Agile, and you have a business that doesn’t understand Agile, the way you have to do that is to sit down and go, “Okay, what are our business problems? And let’s look at how we can solve those.” What keeps you up at night? What are the business problems? And if the problem is we keep delivering this stuff and our customers hate it, well then you can say, “All right, well let’s work on that. Let’s figure out a way to get some customer feedback into the system early so that if we’re on the wrong track, we can learn about it early enough that it won’t be expensive to fix it.” And everybody understands that.

 

Marcus: Yeah.

 

Allen: Is you’re not using the word Agile, you’re just saying, “Okay, here’s a business problem that you’ve got.” And in my mind I’m going, “So let’s approach it using lean Agile thinking.” But I don’t say those words.

 

Marcus: But I mean you mentioned the inspect-adapt loop already.

 

Allen: Yeah.

 

Marcus: Now I’ve heard of the OODA loop, and I’ve heard of Adaptive Action, and there’s all of these-

 

Allen: OODA loop is a little different.

 

Marcus: It’s a little different?

 

Allen: It’s a little different. Yeah.

 

Marcus: Well tell me about the inspect-adapt loop, I think is what you called it.

 

Allen: So the inspect-adapt loop is a learning loop, right? The OODA loop is a focusing loop, which is a little bit different. Inspect-adapt loop is a learning loop. The idea is you get something small into the hands of your users, you watch them use it, right? So that’s something else a lot of Agile teams get wrong, is they do these ridiculous dog and pony show demos for “stakeholders”. And that’s of no interest to anybody. There’s no use to anybody.

 

Allen: What you do is you get some stuff into your user’s hands, then you watch them use it, and then you listen to them as they talk about it and you ask them questions, and you have them ask you questions, right? Every time they have to ask you a question, you’ve done something wrong because it ought to be intuitive. And you figure out what’s wrong by watching them more closely and talking to them, right? If you’re doing an iteration review or a review properly, mostly you’re listening and it’s your customer sitting in front of the computer, not you, it’s not a demo.

 

Allen: So you get that feedback, you understand all the things that are wrong and then you fix it immediately. Now, while it’s easy. Because if you put off the fixes for six months or eight months, it’s going to be harder, right? If somebody is off working on version two, while you’re getting feedback on version one, by the time you can incorporate that feedback, version two is done and it’s harder. So you need to get that feedback as quickly as you possibly can in order to do it efficiently, in order to spend as little money as possible making the change.

 

Allen: So you deploy something small, you get into user’s hands, you get some feedback, you use that feedback to make a small change, right? That’s the adapt part. And then you go back around and you release that. And you keep spinning around to that circle until everybody’s happy, which might not ever happen. But from a business point of view, you say you do it either until everyone’s happy or until we decide that it’s not worth investing any money into this. Is that we won’t bring in enough new customers to justify the cost of the additional work, so there’s no point in doing additional work. So there’s no hardcore business decision that you can make there.

 

Allen: That’s basically the way the loop works. Inspect and adapt applies not just to the program though, it applies to your process. So if you’re not going to do this big bang ANZ thing, what you do is you make a small change and you look at the impact, and then you decide whether that worked or not. And if it didn’t, you change it.

 

Marcus: You change it. And that’s, in my mind, the heart of Agile, is the learning loop that you create that then you’re continuing to change.

 

Allen: Yeah. When you want some direction, there’s a whole… Mike Rother has this thing that he calls the Toyota Kata, that is another kind of system of loops that you use for doing this kind of thing. So his idea is that you start off by understanding the current condition, where are we now? And then you try and figure out what awesome is this? Where would we really like to be? And then you say, “Okay, what small step can we take that will move us in the direction of awesome?” And then you formulate an experiment and say, “What can we try as an experiment, and we’ll see if we can move that way.” Right?

 

Allen: And you come up with an indicator, not a metric necessarily, but an indicator that you’re moving in the right direction. And then you run the experiment, then you look at the indicator and you see whether it’s moving or not. And if it has, then you come up with another one that gets you a little bit more, a little bit closer to awesome. It’s that same inspect and adapt thing, but now we’ve got a goal in mind, is that we’re focusing on getting someplace in specific as we’re working.

 

Marcus: He really liked that point.

 

Allen: He likes talking. When there’s a lot of talking around, he starts talking.

 

Marcus: I see.

 

Allen: But when I’m just here working, he’ll be absolutely silent.

 

Marcus: That sounds about right.

 

Allen: When I’m talking to somebody, he wants to participate in the conversation.

 

Marcus: Well who doesn’t? He’s an extrovert then.

 

Allen: That’s correct.

 

Marcus: There we go. So all of these ideas are simple to say, but pretty hard to do.

 

Allen: I would say the opposite. I would say that all of these ideas are trivially easy to do if you get rid of the obstacles in the way of doing them.

 

Marcus: I was going to say, what do we have to undo, unlearn? That’s where I was headed, was obstacles. So what are some of the obstacles you see?

 

Allen: Well, the existing company culture is one.

 

Marcus: Do you have an example of a culture that gets in the way?

 

Allen: If you have a culture that’s based on hierarchy.

 

Marcus: Okay.

 

Allen: If you have a culture of bosses, where people are above other people. And jobs all move up the hierarchy. You can’t get a raise unless you move up the hierarchy. And there’s a culture of people telling other people what to do. None of this can work. For an Agile team to be effective, it has to be able to make decisions because the cost to delays associated with working up the hierarchy are the same as the delays that you get working with any other silo. It’s just that now we have a management silo we’ve got to deal with. So if you’re going to really move fast, you’ve got to be able to make decisions. You look at Spotify as a great example. They’re sort of the uber-Agile company, not the Uber of Agile but uber-Agile in the German sense, so super Agile.

 

Marcus: Yes, that’s a good clarification.

 

Allen: If you look at Spotify, for example, they don’t have budgets. The teams don’t have budgets. If they need to spend some money, they go spend some money. Everybody’s got a credit card. I know a lot of people that work for Spotify. I love to tell this story about how the team that was doing the backend decided that they needed to get together with the team that was doing the front-end, and one was in Europe and one was in New York, and they just all used their company credit cards to buy a bunch of plane tickets and go to New York. They didn’t ask him… Oh, come on, be quiet. They didn’t ask anybody. They didn’t get permission, there wasn’t all this elaborate junk in the way of doing things. They just did it. The only requirement for spending money around Spotify is that if somebody raises an eyebrow, you’ve got to explain how it helped the company to do whatever it is you just did.

 

Marcus: Absolutely.

 

Allen: But people are trusted. So that’s another cultural issue, right? There’s a culture of trust. If you think about the way things work in most hierarchical organizations, that’s a culture of distrust. That’s a culture where you don’t trust anybody to make even simple decisions. You can’t even go to the supply cabinet and get a pencil without getting permission from somebody, and the key and unlocking the supply cabinet. There’s no trust at all in those organizations. So that’s got to change, right? Everything’s got to change. It’s all connected.

 

Marcus: If it can change. If the people at the top I mean-

 

Allen: If it can’t change, you can’t be Agile.

 

Marcus: I’m not sure it can be a very good place to work, and a lot of other things too.

 

Allen: Right. If we’re going to Agile, is that it’s all got to change eventually. It doesn’t all have to change at once. It’s all got to be moving in the right direction and people have to understand why. And you’ve got to be Agile. Again, that inspect-adapt loop applies to the process changes, applies to everything. A company that is not willing to change culture or change internal process or change governance or change or anything like that, they can never be Agile in the literal sense of the word. Because if you have a bunch of rigid processes in place, you cannot be rigid and Agile at the same time. You can see that immediately, right? You go into a company and they say, “We’re Agile.” And you look at them and every team in the company is doing Scrum. And they all start their sprints on a Wednesday. That’s not Agile, that’s rigid. It’s about as rigid as you can get, where you’re forcing a process on every team.

 

Allen: You look at Spotify, there are no two teams in Spotify doing exactly the same process. A lot of them are doing Scrum like things, a lot of them are doing XP like things, a lot of them are doing Kanban like things. A lot of them made a process up. They’re doing Scrum, they start their sprints whenever it makes sense, they stop whenever it makes sense.

 

Marcus: Things that makes sense. That sounds like a guiding principle of doing what makes sense.

 

Allen: Yeah. Well, doing well. Yeah, but you’ve got to learn what sense means, right? From the perspective of a command/control Waterfall guy, none of the stuff we’ve been talking about makes any sense at all. It’s all crazy talk. It just seems so un-intuitive to them. Right? We’re getting into a Daniel Kahneman slow thinking, fast thinking problem. Is that it seems very un-intuitive. They can’t imagine how it’ll work.

 

Allen: They say, “Businesses don’t work that…” People literally can’t imagine it. You see it sometimes. They go, “Well businesses they just don’t work like that.”

 

Marcus: Right.

 

Allen: How can you have a business without managers? It’s just insane. It’s crazy talk. Right? And the projects, right? Without projects. A product focus rather than a project focus. That’s a big deal. They literally can’t imagine a business functioning without that kind of stuff in place, right?

 

Marcus: I was actually going to ask you about that because I have the person… I mean, I’ve got enough gray hair that I remember before product management was a thing and the product man… The developers sort of did everything. There wasn’t as much specialization in my world of engineering 20 years ago when… 25 when I started. So teams were just made up oftentimes of groups of people, like everybody could sort of do the same thing across all the applications and all this other stuff. And we, as programmers, sort of owned the product. I sat down with the customers, they told me what they needed, I went back and I talked with a buddy, we sat down and buddy-coded it. It was kind of simple.

 

Allen: Well that’s not very Agile, wasn’t it?

 

Marcus: Well yeah, you can call it that. But now not only do we have Agile, but I feel like we’ve also pulled product management out. We’ve set them into their own discipline and their own group, and we’ve said there’s a silo… And I hear so much more tension between these groups called product and engineering.

 

Allen: Right, when it’s all artificial. And as you say it’s recent. I agree with you completely. But it’s a cultural thing again, and it’s a thinking thing. Somebody is thinking that the organization has to be hierarchical, you’re going to get silos naturally, because that’s what hierarchies do, is they form distinct silos. Because you have directors and directors got to be director of something, so there’s your silo.

 

Marcus: That’s right. There’s your distinction.

 

Allen: So if you’re thinking in terms of that organizational structure, it’s going to actually produce silos that didn’t exist before. And when a new discipline comes in, the person thinking is going to be, “Let’s turn this into a silo.” Well they’re not thinking that consciously. That’s what’s going to happen. So ultimately it goes back to that culture again, to hierarchical thinking versus network thinking. Agile shops are very much networking shops, not hierarchical shops. Communication is network communication, it’s not up and down a hierarchy.

 

Marcus: It also reminds me of a lot of David Bomes. He’d talk about wholeness and about fragmentation and every… All these are just mental models that we hold about who’s in charge, who has power? I mean, I don’t actually know. And I live in country that’s sort of like farm country, but I don’t know anyone that works in an actual silo. Not like a grain silo. I don’t know anybody that works in a grain silo. So these are just mental models. They become so calcified in our thinking, we can’t see any other way that it could work.

 

Allen: Well that’s exactly right. See that’s the problem, is that a lot of the pushback I get on Twitter when I get pushback is from people that literally can’t imagine businesses working in a way that is different than the way that the companies that they work for right now work. And it’s kind of self perpetuating because if you get your first job with a company that works like that, when you move onto your second job, you’re going to kind of be looking for companies that work like that because that’s where your skills are.

 

Allen: So it’s much more likely that you’ll get a job with a company that works like the old one because you are skilled in working in a system like the old one. So you tend to never break out of it. You started off in a company like that, you stay in companies like that forever. And the people who start out in small Agile startups are never happy working in those big corporations, they just can’t tolerate it. So they tend to perpetuate Agile thinking in the companies that they move into because they just can’t imagine working any other way. So here’s the situation. All too often I hear this, “Well, in the real world we can’t do that.” And of course what that means is, in the company that I work for, we can’t do it.

 

Marcus: The real world.

 

Allen: But it also means in all of the companies that I’ve worked for in the past, we couldn’t do that either.

 

Marcus: Oh, that’s right.

 

Allen: Right. And the people that start out working in an Agile world, they have a very different notion of what the real world is like. So if you work for three Agile companies in a row, and somebody suggested to you that you break things up into silos and put command and control in place, they would say, “Well, that doesn’t work in the real world.”

 

Marcus: Right. Because it’s not their real world. The real world. Yes. Yes. And of course this is a podcast for people who live in the real world. But I love that we’re actually differentiating because if you’re listening and all of this sounds very foreign, just recognize that your real world is probably very different than Allen’s real world or a lot of other people’s real world. It’s not the real world, it’s just the way you think about the work that you do.

 

Allen: It’s also why it’s so hard to transition to Agile. It’s why so many companies fail at it, right? Because they’re changing their definition of “real world.” It’s very basic-

 

Marcus: Changing your worldview.

 

Allen: Changing fundamental ideas about how the world works.

 

Marcus: Changing your worldview is really hard, which is why religion got so popular. There’s lots of reasons, we won’t go into a lot about religion, but of course religion and lots of these philosophies carry a worldview with them.

 

Allen: Yeah.

 

Marcus: So yeah, we have gone just all over the place. Let’s kind of end the show on a practical note. If somebody is listening and they’ve got that front-end backend database team and every team, I know I’m not suppose to say this, but they think, “Oh, every team is Agile, they’ve got their stories, they’ve got their sprints.” But they are listening and they’re like, “Oh my gosh, that’s why we can’t deliver value very fast. That’s why it takes months to get anything out.” Allen, where do you usually suggest people start changing their thinking? Is there a little bit of a tip of the spear we can start to wedge in here?

 

Allen: Yeah. At least the one that I use, right?

 

Marcus: Okay.

 

Allen: Different coaches and different consultants have different approaches. My approach is to start by trying to get the definition of the work under control. The way that I like to start is to start with stories, with user stories, and to really teach people what a story is, because a story is a description of your users doing something. It’s not a description of you doing something, it’s a description of your users doing something. It’s a work that’s in the domain.

 

Allen: And then we can learn how to make those stories smaller, and then we can say, “So what we now have to do is get this thing implemented as quickly as possible and into somebody’s hands. So how are we going to do that? And let the teams figure out how to make that work.” That’s never going to involve having silos.

 

Allen: So practically speaking, it means that you have to have permission to set up a little side project somewhere where the teams can kind of work outside of the system in order to prove that they can actually get something done working that way. But you’ve got to say, “Okay, so we’ve got to borrow a database guy and we’ve got to borrow a product person and we got to borrow a UX person. They’re not going be on our team, we can’t do that. But we need to borrow them for a few weeks so that we can get this done and out the door quickly.”

 

Allen: And kind of approach it from that point of view, is approach it from the point of view of getting the work under control. One of the core problems is that a company that’s not working in an Agile way is not defining work in an Agile way either, except defining a unit of work properly, is they’re breaking things up into projects, which typically match the silos. We have a project to modify the database to do X. We have a project to build a UI that looks like Y. And so what you need to do is break people out of that so you can say, “Okay, so we have a project to get this capability into our user’s hands, and to change everything that we need to do in order to do that.” Every iteration is a project.

 

Allen: And start with their thinking, because that’s the way they think, but try and just tweak it here and there in order to make it work. If you can get it to work at all, then you can start pulling in more changes because the people are saying, “Wow, this is working. You’re delivering something and we haven’t delivered before.” And then you can say, “Well, if our team had a room of its own, we could sure get work done a lot faster. If we didn’t have to get permission every time we have to spend a dime on training or something, then we could sure learn a lot faster and get stuff out the door faster.” And you can just work a little at a time and gradually pull all of the things into the system that you need to pull into the system.

 

Allen: And that’ll work. It’s slow though. It’s not the big bang thing. It takes a while. A company is going to do it even close to successfully if it’s sort of a medium-sized company, three, 400 people. It’s going to take them three years to five years probably to do that.

 

Marcus: Well, and I like what you said, you really… I felt like the way you described it of, imagine we had to get this done, and then you used this magical word, for me at least, you said, “Team, how would we do that?” And you didn’t say, “Here’s how we’re going to do it, with my Bible of Agile.” You said, “This is an exercise for you of a problem solving exercise.”

 

Allen: Right. I never do that. I think that those guys that are the Scrum guys that come in and say, “This is the way it’s done.” They do enormous amount of damage. To some extent, what I do is clean up after those people. Is that what I do when I go in as a consultant, is I say, “Okay here’s some options, here’s some ways that it’s done.” And if we were doing it in a sort of Toyota Kata kind of way, it would look like this, and kind of Scrum would approach like this, and XP would approach it like this. I give them a toolbox and then I say, “Okay, so come up with something that’ll work for you guys.” If it doesn’t work, and I know that in advance, I’ll still let them fail.

 

Marcus: That’s what an experiment is. It’s learning.

 

Allen: An experiment that they’re trying, and it’s their experiment, not mine. So I might have notions that it’s going to fail based on my experience, but maybe it’s not going to fail for them. I don’t know. They’ve got to try it. And if they try it and it doesn’t work, obviously it doesn’t work, then of course they’ll be open. Excuse me. Cranberry, be quiet.

 

Allen: If they try it and it doesn’t work, then they’re motivated to try something else, provided that they have the freedom to do that. So ultimately it comes down to that, right? The teams have to be empowered to decide how they’re going to work, right? They have to do whatever they need to do in order to get the work done. If you’ve got somebody outside going, “Oh no, you can’t do that.” Then they’re not going to succeed. They’ve got to be able to be autonomous.

 

Marcus: I think that’s a beautiful place for us to wind up here today. Allen, where can people find you and engage with your work online?

 

Allen: There are a couple ways to do it. I’m pretty active on Twitter. That’s @AllenHolub. I’m easy to find.

 

Marcus: We’ll put that in the show notes then.

 

Allen: Okay. And email works. And again, that’s also my name. It’s Allen@holub.com. It’s the same as the Twitter handle, but I’ve moved the @ sign.

 

Marcus: Okay.

 

Allen: If you actually want to talk about bringing me in to do some training or something, if you go onto my website holub.com/chat, you can set up a video call and we can chat over video and actually communicate that way.

 

Allen: One thing that I don’t want to do, I’ve had two really bad experiences in the last month with this, so I’m just never going to do it again. Is the person on the other end was five people huddled around one speaker phone in an echoey conference room, and I could understand about one word in 10, so that won’t work.

 

Marcus: Now we know.

 

Allen: If you have decent equipment, okay, but we have to talk in a way that we can understand each other. And if we can do that, I am more than happy to do it. The final thing is that I’m one of the co-moderators on a really big LinkedIn group called the Agile and Lean Software Development Group. So if you just search for Agile and Lean software development, it’ll pop up in the LinkedIn search thing. And there’s 150,000 members, but I’m one of the moderators, which means that I’m watching every question go by and commenting on most of them. That’s a pretty good way to interact with me also, if you want to do that. Just go on LinkedIn.

 

Marcus: Allen, thank you so much for being on the show, and tell Cranberry “thank you” as well.

 

Allen: I will. He’s got a lot to contribute.

 

Marcus: Yes, he does. All right, that’s a wrap. Thanks everybody. See you next time.

 

Outro: Thank you for listening to Programming Leadership. You can keep up with the latest on the podcast at www.programmingleadership.com, and on iTunes, Spotify, Google Play, or wherever fine podcasts are distributed. Thanks again for listening and we’ll see you next time.