Episode 100 – A retrospective

Read along you will

Shane: Welcome to the No Nonsense Agile Podcast. I’m Shane Gibson.

Murray: And I’m Murray Robinson. So today, Shane, I think we’re gonna talk about what we learnt over the past 99 episodes, since this is our 100th episode.

Shane: Yep. Episode 100. Who would have thunk ? 

Murray: Yeah. So the structure for today is what is the podcast and what do we talk about? What are we critical of? What have we learned? And then summarize it. So the whole thing is a super summary of the last 99 episodes.

Shane: And we’ll probably be one of the more agile podcast formats we’ve had, because it’s just you and me talking. So who knows where we’re going to go. 

Murray: So what do you reckon this podcast is about?

Shane: For me, it was you and me starting off. Being critical about a whole lot of things and having a conversation about them. And then somehow you seem to have this knack of getting access to a whole lot of people around the world who are fricking amazing. And so it then got driven by the guests we had.

And we started off talking a lot about agile ways of working, agile patterns and then somehow we moved on to product and then we moved on to leadership. 

Murray: Yeah, it’s been an exploration in depth of all of these great authors and thought leaders and we cover everything to do with creating an effective engineering organization that makes good products and services. And that’s far more than just technology. So I think that’s why we’ve gone so much into product and leadership over time as well. 

Shane: So what’s it about? It’s about you and me finding interesting people in the agile product or leadership domain and having a great chat to them and picking their brains about things that we would probably want to do when we do our next piece of work with an organization. That’s what it’s about for me.

Murray: There’s so much bullshit out there. That’s why we called this the no nonsense Agile podcast.

Shane: Well were actually going to call it the no bullshit agile podcast, but they got vetoed by somebody, not me. 

For me, it’s just interesting, given I’ve got a startup and we’re doing software engineering In the data domain, but still now it’s a product company. It was just timely that we started talking to people with great ideas on how to build and run product companies. 

You know, the leadership one, I still do side hustling with large organizations every now and again to get some more runway. And I find the leadership sessions that we do, really intriguing to then apply those patterns against those large organizations. And it’s given me more insight on how to coach teams better, and how to manage the stakeholders of various qualities that each of those organizations have.

Murray: All right. 

Since we’re the no bullshit podcast, let’s talk about what we’re critical of.

Shane: You’re critical of everything and I’m just lovely. So you’re a bad cop, I’m a good cop.

Murray: Let’s let the audience decide on that.

Look I’m very critical of waterfall project management having done a lot of it. I guess it has its place. If you’re really clear, we’re going to do waterfall. Do it, but don’t mix it up with Agile because most of what people are doing these days is fake Agile. They’re just doing waterfall with sprints done badly and Jira. And the sprints are only done in the dev test part anyway.

Shane: Yeah, I’ve probably become a little bit more mellow on that one over the last couple of years. I suppose if you’re going to work a certain way, Be very clear that’s the way you’re going to work and then focus on how you can work that way better.

So if you are going to follow a waterfall process where you are going to do requirements up front and then you’re going to go and do some design and there’s an air gap between each of those either in terms of time or teams then focus on the air gap. Focus on the handoffs. Focus on the way you communicate. Focus on the time between those things. If you’re going to do it, be honest about it, don’t bullshit and say you’re doing something else. 

And then there are great patterns out there for waterfall ways of working. So adopt them, do Prince 2 and PMP and all that stuff, but do it. Don’t pretend you’re doing something else because you’re not. 

Murray: Yeah. What I see out there these days is 90 percent of organizations claim to be doing agile and 90 percent of them are doing fake agile They’re just doing waterfall with sprints in the dev test part but still working in silos and not agile at all.

Shane: Yeah. And then, it comes back to what is agility? A couple of years ago, I would have really struggled to give you a good answer. One of our guests, gave me the definition that I use all the time now, which is our ability to change direction quickly.

Murray: Was that Joshua Koresky on the joy of agility? 

Shane: Yeah, and there’s a whole lot of stuff that has to come with that. It’s not easy, but if that’s what we can do, then we have adopted agility. I think that’s one of the things we get from a lot of our guests is agile is not the goal. We’re not implementing agile. We’re not transforming to become agile. What we’re doing is adopting more agility in our organizations. 

Murray: Yeah, so that we can achieve other goals which are revenue, profit, growth, good customer experience.

Shane: Yeah. Faster time to market, high quality products, more profitable product. And I think that’s one of the things we got as a core theme from everybody we’ve talked to is that, agility is a way of getting to that goal that you’re trying to achieve in a better way. Adopting or applying or implementing Agile with a big A is not the actual goal .

Murray: Yeah. 

I think we’re also quite critical of bureaucracy and authoritarian management.

Shane: Yeah, I still believe that there are fixed mindset companies and growth mindset companies. And I still believe that companies before 2000 are primarily fixed mindset companies because that’s where their leaders came from. What about you? I mean, do you still see that there is a two phase type of organizations where you fit into one bucket or the other?

Murray: Not post and pre 2000. I was always a bit skeptical of that, but I am convinced now by Ron Westrum and Jim Highsmith and some of the older guests we’ve had on who said that before 2000, there was always quite a lot of really innovative, fast moving, agile companies and organizations. Particularly during and after World War II in America. 

You’ve got the Lockheed Martin skunk works and so on. And then Ron talks about, one of the missile programs that was very innovative. So I think that it’s got to do with the stage of growth that an organization is in. A new organization only really succeeds if it’s innovative and generative and has agility. And if it doesn’t have leaders who are like that, then it’s going to fail. So successful new organizations start off like that. Then eventually they get taken over by bureaucracy because that gives them stability and all of these career bureaucrats join. And then after that, it gets taken over by these toxic pathological leaders who are just trying to extract what they can personally out of it. It’s not necessarily before or after 2000, but it seems like a life cycle that organizations go through over time.

Shane: So is that a life cycle in size? Do we say that as you scale, you then change the dynamics of the organization, you bring in people who can scale organizations, you bring in people who are used to more hierarchies because now we have too many people to run as a flat organization. And therefore, typically organizations pre 2000 have already got that need to scale.

Murray: We’ve had guests like Ron say to us that it’s all depending on the leadership. So NASA, in the Apollo program was quite agile and flexible and there’s even case studies of them using iterative software development, test driven development, stuff like that. They were really big. So my view is that it’s got to do with the leaders. You get organizations like Apple, who are still highly innovative under Steve Jobs, even though they were quite big. But what’s interesting about that is how it was very product and customer and user focused and innovative. Then Steve got kicked out. It became bureaucratic. And then he came back in and he changed it back into a much more innovative organization again.

Shane: Yeah, I did a post around Ron’s idea around generative, bureaucratic and pathological cultures. And one of the bits of feedback I got was people who say they’ve never really worked with organizations that they can tag as that, but lots of times they could tag people as that.

I read Steve jobs biography and he seemed to be pathological to me, but he was also highly generative in terms of the company. And so I wonder whether, it’s the organization that has those cultures or as the leaders, and that was same with that conversation we had around Tesla. Seemed to be generative to some degree, but also highly pathological. 

Murray: Pathological. When Musk got involved. He’s got two sides to him. He’s got a really dark side and he’s got a good side. I think maybe Steve Jobs is the same.

Shane: It’s only what you hear and what you read. But yeah, gifted people often are on a spectrum. And then, so again, I wonder whether, It’s the leadership of those organizations and then, of course, once the leadership changes, that’s when they flip .

Murray: Yeah, I think it’s the leaders, particularly at the top. And leaders drive the culture of the organization by what they reward and punish. And also by the rules that they put in place. So if you remember, we had Dan Mezick on who was talking about Open space agility and open organizations. And he was saying that he can change the culture of an organization in three days by getting an agreement from the top on what people are allowed to do and what they’re going to be rewarded and punished for. He thinks that culture is very clearly determined by leaders. 

Shane: I think it’s also one of the things that we’ve become quite brutal on is this idea of leadership versus management. Where managers manage the work to be done, the tasks, they’re quite directive and leaders manage the goal. They provide the goal to the team and then they provide the umbrella or as I like to call the shit shield.

And they let the team, get on with it. And they support the team and unblock the team. They effectively become coaches. I think that’s come through as quite a big theme. And then what we’ve done is we’ve tried to find people that can give us patterns on how you apply that. We had one just lately around OKRs and what’s intriguing for me is, that idea of OKRs should allow us to take a more leadership stance, right? It’s saying here’s our goals, here’s the outcomes, give us a bit of a hint of how we know we’re on track, but that’s it go away and do the work, but a lot of organizations I see treat OKRs as if they’re KPIs, they go back down to that stance of managing the work to be done, not managing the goal.

So I think a lot of the time the patterns can be applied in a great way within organizations. But often, we can just do what I call changing of the slippers, right? We change the terms, but we don’t actually change the way we work or any of our behaviors. And I think that’s come through quite a lot from a lot of people we’ve talked to.

Murray: Yeah, every pattern can be twisted into a form of micromanagement if you have micromanaging leaders. You see a lot of that with Scrum. 

Shane: One of the ones we haven’t done a podcast on yet, which should find somebody to talk about is the idea of an agile delivery lead, because I’m seeing that happening a lot now and that’s starting to make me grumpy and I do think whenever we get grumpy, we should have a podcast about it.

Murray: Let’s move on a bit to what we’ve learned. 

And if I can kick it off, I think that uncertainty is at the root of a lot of what we’ve been talking about. We’ve had quite a few guests come on and say, everything is really uncertain. You need to start by assuming that a lot of what you’re doing is wrong or flawed or you’re lacking information. We’re uncertain about what the problem is. And as a result, the requirements are uncertain. The solution’s wrong, the plan’s wrong, the process is flawed, and your organization structure is wrong. 

That particularly came through when we talked to Stephen Bungay on the Art of Action, and he was talking about Von Clausewitz and the fog of war. And also with Kyle Griffin, when he was talking about uncertainty, complexity, and change. And plenty of others have said the same thing, that a requirement is really an untested hypothesis about what users want. You shouldn’t just take it and implement it. 

At the root of a lot of what we’re doing is saying we accept that a lot of things that we are told are going to turn out to be wrong. So we can’t just spend three months getting our requirements and then three months getting our architecture and then commission somebody to build it for us. Because by the time we get to the end, we’re going to find that a lot of what we thought we needed to do was actually wrong and we have to change it. So if you assume that a lot of what you know is probably wrong, then you need to focus on testing everything and reducing the time it takes to get feedback and also delegating. A lot of things come from this. From assuming that things are uncertain versus things are certain. What do you think about that?

Shane: So what I talk about a lot. And we got from one of our guests, is the idea of bets. So for me everything’s uncertain. There’s a whole bunch of assumptions.

Sometimes you think you have certainty. You could be right, you could be wrong. So what you do is you’re placing a bunch of bets. That’s based around that level of uncertainty you think you have. So even if we look at something simple like a research spike, what we’re saying for a research spike is we have a high level of uncertainty and before we commit to doing a whole lot of work, can we do a small amount of work up front to reduce that uncertainty?

Now we’re never going to remove the uncertainty, but we’re going to reduce it and we’re saying that small amount of work up front, has more value than just going in and trying and doing all the work. So yeah, for me, the idea that everything’s uncertain and then you place bets based on your level of uncertainty. Where do you want to invest your money? When do you want to stop investing? How do you know to stop investing? And I think that came through a lot more from the product people than it came through from the agile people. I think it’s a product behavior to place a lot of bets and reduce that uncertainty.

Whereas from the agile domain, I’m not sure I saw that. 

Murray: We had quite a few agile people who talk about product. Those people who come out of the scrum product owner world talk about uncertainty, and, Kyle, who was talking about it a lot, is actually an XP guy.

Shane: Yeah, I think a lot of people that came out of the Agile domain are in the delivery part of the value stream. And the people that are very product centric seem to becoming the before delivery part of the value stream.

Murray: If everything is uncertain, then it has a lot of consequences for what you’re doing. You think you have a clear set of requirements, and you have a clear process to build them and deliver them, right? But if you start from the point of view that the requirements are probably 60 percent right 40 percent wrong and you don’t know which ones are wrong and your process is partially right and it’s got a lot of flaws in it and you don’t know what they are until you encounter them. You end up taking a very different approach to everything you do. I think that’s what drives a lot of what we’re talking about with agility. Things are uncertain. It’s not just the environment that is uncertain. It’s just that our knowledge is uncertain and we don’t even realize it. And so therefore we need to change everything we do to optimize learning. 

Shane: And we optimize learning so that we can increase our ability to change,

Murray: So that we can increase our ability to achieve our goals . The implications of that then are that you need to focus on goals and outcomes, not focus on deliverables and tasks and, tiny little stories because they could all change. So we need to focus on the business goals, the business outcomes we’re trying to achieve.

Shane: Which then is interesting because if we talk about self organizing or self powering and self enabled teams, it leads us down the path that our teams need to be made up of experts and experienced people and no juniors. Because they are the only ones that we can describe a goal to and they can then go away and achieve that goal because they have all the skills they need. There a cross functional T skilled team, but I’m not sure that’s actually true. 

Murray: I don’t think everybody needs to be super experienced. I think you need to have experienced leads in your team. And look a lot of that goal and outcome focus comes from the military and they have a lot of 18 year olds and 19 year olds who don’t know much. They do invest a lot on training though. So one of the things that comes out of it is that you do need to train and build capability and be quite careful about the number of juniors you have, because in my experience a junior needs about 25 percent of the time of a senior person, to coach, mentor, and train them. So if you have four juniors and one senior, the senior is not getting anything done and the juniors are still learning. So it’s going to be slow. 

So there’s three main talent models, top Heavy, Diamond and Pyramid. There’s one where it’s very, top heavy. Everyone’s an expert, which is great, except it’s very expensive. You have. One, which is like a diamond shape. So there’s a lot of people in the middle and a few experts at the top and some novices and beginners at the bottom who are learning. I think that’s probably the most realistic model. And then the other model is the pyramid model, where you have a small number of people who are really good at the top and a huge number of people who are juniors and, quite a few in the middle. That’s the outsourced offshoring model. When you work with India or Vietnam, you get massive number of people with really junior level experience and that’s the small number of leads who are good. And it’s really a very bad model in my experience.

Shane: Which is the shiny seat consulting model where everything’s a pyramid. And, The partner pops in to do the presale and then pops in at the end when it goes tits up and then 19 graddies come in at the bottom of the pyramid to do all the work.

So I think we have been quite critical of large, shiny, suited consulting companies. In fact, we actually had a guest who came from one of them and he was quite open about the model. So I really enjoyed that one. 

Murray: Well we had the guy from Accenture. Mirco Herring. Is that the thinking of? Talking DevOps. 

Shane: Yeah, he did a good job. That was a good chat about DevOps.

Murray: Yeah, he was quite realistic. And we also had a couple of people who are used to work for the consulting companies, but are now independent. Peter Lamb was a guy I know who works with big companies here. He’s independent and he talked about the consulting model as well.

So the big problem with the consulting model is that they use a waterfall process to implement agile and change. So it’s we go away in our secret offices and we decide what the new organization structure is going to be. And then we roll it out and everybody gets trained and gets new jobs. And hopefully a lot of people get fired so we can save money.

Shane: I think there’s actually a couple of other patterns we’ve picked up. That means that whole model is broken. One was around the idea of goals and outcomes because You don’t typically engage a consulting company with a goal or outcome as the primary driver in the contract. There’s always some other monetization number of people, number of hours, number of tickets moved. There’s never really a shared goal, right? Because their business is to make money and your business is to achieve whatever goal you need. And there’s always a disconnect in there I can see. 

And then the second thing is because they have a bunch of graddies coming in, they want to processize the work. The classic one is where one of those large consulting companies took the Spotify model using the air quotes and, created their own version of it. I think it was a Jason Yip we had who came on when he was working with Spotify. And one of the things that came through really strongly with his podcast was he kept taking us back to what’s the organization strategy. Ignore the model to a degree. It’s the strategy and how are you executing the strategy? And he constantly brought us back to that, not to the team structure. 

But the team structure is important. And I really enjoyed having both Matthew Skelton with team topologies and Jorgen on with unfix. I found both of those a really good set of patterns that if I ever go and work with an organization at the beginning, at the foundational level, before we’re into delivery. I find those teaming structures a good way of having a conversation with organizations about how they think they should structure their teams to meet their goals.

Murray: Yeah. Brendan Marsh and Jason Yip, who actually worked for Spotify, both said that the Spotify model that people know about, they did actually use it. It’s not like they didn’t use it, but the thing was that they changed it all the time and it’s changed quite a bit since then. And that actually each team was allowed to change it however they wanted. So they had this idea of guidelines and guardrails, not rules and processes that you had to implement.

Shane: Which comes back to mission command, right? So again I’m amazed at how many patterns we’ve had from guests that have come out of the military and mission commands being one of the big surprises for me. That whole idea of setting a goal. Which is the first thing, ensuring the teams have the expertise and the experience to actually achieve the goal, which is the second thing. And then the third thing I picked up is this idea of boundaries, because the plan is not going to survive the first engagement.

But you need a set of rules or boundaries, a very small number, which tell people what is acceptable, so they can adapt to what they’re doing in that mission, as long as they don’t break any of those boundaries. But most organizations don’t do that. They don’t actually set boundaries. What they do is set a whole lot of policies, a whole lot of rules, a whole lot of management stuff. 

Murray: Yeah, mission commands. Great. And one of the things I’ve realized as we’ve been going through and talking about leadership with people is that I’m still too focused on management and tasks and I would be better off focusing much more on goals And working out how to measure the outcomes and then asking the teams to come up with the plans rather than telling, asking. Say, here’s the goal, what do you think? Come up with a plan. And then maybe as a coach, the best pattern is look, here’s some things you can try. You want to achieve this, you’re having this problem. Why don’t you try this? But I’m not going to make you

Shane: And that’s one of the things that we got onto or questions that we started asking, and I’d love to go back and ask them from the beginning, which is if you are a coach, if you’re going into coach an organization, Is there value you having been on the field before.

Murray: Oh, definitely. I think everybody said that I’m very critical of life coaching and I think we’ve had some influence on the community because when we started talking about what bullshit life coaching was as an agile coach a lot of other people were picking it up at the time. 

So an agile coach should be like a sports coach, like a professional soccer coach. You’re not going to get a professional soccer coach. who hasn’t played soccer, I think that a successful professional coach has played on the field, but they can also do life coaching. They have a whole lot of things they can do.

Shane: Yeah, they T skilled themselves. So I think if you’ve played on the field, then you are more valuable than if you haven’t. I think there are exceptions where people haven’t played the game. They haven’t been on the field and they are incredibly good coaches, but I think that’s an exception overall.

Murray: But their coaching is very narrow. So they focus on people, feelings maybe some general organizational stuff. The problem we’ve had in our industry is we’ve had all of these executive life coaches come out of HR and, the therapy community come in and get all of these agile coaching jobs and be fairly useless in my opinion.

Shane: Yep. I think a sign of success. When things look like they’re working, everybody wants to jump on the bandwagon, just look at Gen AI right now. And then people who don’t have expertise or experience come in the market because it’s a free for all.

Murray: Maybe the good thing about this current downturn in the Agile consulting market is some of those bullshit artists will go on to the next thing. They’ll become AI coaches 

Shane: Prompt engineer coach.

Murray: Prompt engineering coach or leadership coach or something. 

Yeah what have you learned about leadership from our interviews?

Shane: This idea that, set the goal don’t manage the work to be done. And then just a whole lot of behavioral things that have come through in terms of being able to sniff out certain kinds of behaviors. When I’m talking to people so yeah, it’s more of a kind of flavor that’s come through rather than a core thing for me. What about you?

Murray: Yeah, the most memorable one we had was the interview with Scott Sievwright. He’s the Scottish guy who led the agile 2020 Reflect conference. And it got quite emotional. We were talking a lot about having authoritarian fathers and having to go on a journey towards leadership and Scott describes leadership as a really quite an emotional thing, a form of what you might call emotional labor. But , quite a few people we’ve had have talked about servant leadership, open and honest communication is critical, even if it’s news that people don’t want to hear. And then the whole thing about a leader’s role is setting goals and building capability, coach mentoring and supporting.

And a bunch of people who said a leader should not focus on managing the tasks, but they should focus on improving the system to remove blockers for the teams.

Shane: Yeah, good leaders are effectively good coaches. They help the team hold themselves accountable. And then they provide that lens that the team often can’t see. 

Murray: Another thing that’s come through a very strongly from the product people is the idea that we have to collaborate with our customers and users all the way through. We had a very strong theme from the UX people like Christian Crumlish and others is that you really need to research customers needs and you can do it continuously. I’ve talked to a few people about this and they keep thinking you want to go and do a three month research phase and stop everything. That’s not it at all. You can talk to customers every week in the middle of development because you can say, Hey, this is what we’re thinking of doing next to solve this problem. Here’s a mock up of it. What do you think?

Shane: Yeah, it took me a while, but I now categorize product organizations as research led or MVP lead. And the way I articulate it is. Research led organizations say they don’t understand the problem to be solved and they do some research work up front to understand that problem before they ever get near a solution. MVP led or lean product led people will have an idea they have a bet on what the problem is, has a high level of uncertainty, but they want to build something quickly and test it with their customers to both prove that the problem exists and that their solution will fix it. And I think as we went through and talk to the product people, I can categorize organizations or people’s patterns to one of those two.

In the data domain, we have massive arguments amongst ourselves about the way we work, the methodologies we use, the patterns we use, the terms we use, and I saw that in the product domain as well. There’s actually no one agreement in this is how you should build products. So all the product people have been quite open to other patterns but they definitely have their own patterns and for me, one of those is research led versus lean or MVP led.

Murray: But there’s a combination of both of those. So Teresa Torres talked about continuous discovery. Which is the idea that you set yourself up so you get three or four real customers talking to you every week and you can do whatever you like with them. You can do research or you can do MVP testing.

Shane: So I think, Teresa’s pattern was really useful, regardless of which approach you take. But what I’m saying is when you get started, you either start off your company, your product with the idea that you don’t understand the problem you need to solve. You don’t actually know what the product is yet.

So you’re going to to do a bit of work up front to understand the domain, the customers, their needs, their jobs to be done. The problem that you need to solve because you don’t actually know what it is. And then you’ll go through and prove that you can build a solution for it and that you can monetize it, people will buy it and it solves that problem.

The other option is the lean startup approach, which is you think you know what the problem is, but you haven’t proven it. But the way you prove it’s a problem is you start building out that minimum viable prototype, and put that in front of potential customers to see a whether the problem exists and be whether your solution is going to solve it. And I think fundamentally they’re two different ways. . 

Murray: I think you can use both. So I reject the idea of let’s have a phase of three to six months of doing user experience research and jobs to be done before we do anything. But I also think that you can be doing your research all the way through.

There’s a lot of different research methods. You can interview people, you can observe people, you can watch them using your platform. You can get data analytics. These are all research methods that you can use. You can also show people things and say, what do you think of this? And you can show it to them at various stages. You can show it as a drawing as a high fidelity mock up or as something’s working, but you haven’t implemented it yet. So I think that you can be somewhere in the middle.

Shane: Yeah, I’m going to disagree with you. I think you’re either one or the other, naturally. You can use patterns from all those techniques and they’re all valuable, but you’re going to naturally be one of those two. 

Murray: You get a lot of agile people who say that we’ll build something and we’ll get feedback. And there’s a lot of the scrum community, XP communities like that. And then you, have people like Debbie Levitt and the jobs to be done guy, Tony Ulwick who wanted to do, lots of heavy research before you do anything, but I think most of our product people were wanting to do it, as you go.

Shane: I think most of our people were MVP focused and that’s probably because that’s where both of us, we’re not heavy research, heavy jobs to be done people. We don’t think that way. And therefore we naturally find people that think the way we do. 

Murray: it comes back to the language and definition of words, Shane, if you have a broad definition of MVP, which includes talking to people every week and showing them mockup’s and talking through their problems, then I’m part of that.

Shane: Yeah. And they’re all valuable patterns. 

We can take the agile manifesto and apply it to product behavior, product thinking and it fits perfectly, but we don’t often see product people talking about the agile manifesto, which intrigues me.

Murray: But what’s really interesting is Marty Kagan is actually very critical of Scrum, but pretty much everything he does is completely aligned with Agile as far as I can tell.

Shane: Yeah. And then his latest podcast is really really scathing of agile coaches.

Murray: That’s really funny. Cause when we had him on, we agreed with nearly everything he said, and he agreed with most of what we said. There’s a number of people who said that Agile as it’s being implemented is half of scrum done badly plus Jira. And I think Marty is basically saying that’s what Agile is and I don’t like it. I want to do this other thing. Which ends up being what we really think Agile is anyway.

Shane: I’m sure one of the terms I got off one of our guests was the idea of a ticket prison. I’ve been quite vocal on my dislike of JIRA because it’s an ITIL based ticketing system that we try and use to manage change fast and it’s an oxymoron.

Murray: One of the core things for me that’s really come out is the idea of doing everything continuously. Particularly came out with the continuous delivery people like Dave Farley and the DevOps people, and also people like Teresa Torres. So there’s this idea that we should focus on continuous learning by doing continuous discovery, continuous delivery of value, continuous improvement.

And at its core, Agile is about continuous improvement. We are uncovering better ways of developing software by doing it and helping others do it. So uncovering better ways that’s just continuous improvement. So that’s like the core idea of everything I think we’ve come across. Do everything continuously so you can learn continuously.

Shane: Scott Ambler talked about method prisons and again, one of the benefits I love of doing this podcast is I get to finally speak to some, heroes I’ve had for many years, and Scott Ambler was one of those. I really enjoy the ability to talk to some people that I’ve admired for years and whose patterns I’ve adopted. I almost treat the podcast as free training.

And then some people that I probably should have known about and I never did, so like Mary and Tom Pompadick I should have known about them, but for some reason I never stumbled across them or read any of their work. And people that have really intrigued me. So people like Tom Gilb, who had this massive brain. And done this really a massive amount of writing. When I read his stuff, I can see the patterns he was thinking about come through the next 20 years,

Murray: Yeah. Tom Gilb is very interesting and quite a lot of the Agile Manifesto authors knew about him and talked about him, but he didn’t want to get involved in the Agile movement and he’s been critical of it. He was very focused on outcomes wasn’t he and success measures and doing things very quickly. He was saying that he works with companies to redefine a troubled project. And he spends a week with them and they’ve already got a new architecture by the end of the week. And a new plan. 

The other thing I wanted to talk about is scaling. What have we learned about scaling, Shane?

Shane: Scaling’s hard. I don’t think we’ve ever gotten an answer. We were very vocal of our dislike of SAFE at the beginning. I don’t think we changed our stance. I think we have changed how often we bag it. But I don’t believe in it. I don’t think it’s valuable. We had a couple of guests that talk about if an organization is adopting safe, it means they’re willing to change. And therefore that’s a good thing. And then they can go in and do the right work. I’m still calling bullshit on that. And I’m just not going to work with organizations that have gone down the SAFE path because I don’t think they actually want to change the way they work to increase their agility.

Murray: Michael Kuster’s actually does work with safe organizations and he does teach them safe, but he was basically saying that he uses it as a way in. That the best thing about SAFE was that it persuaded executives that there was a way of scaling it. And then that becomes a big source of entry for consultants, and also it’s a great way to make money. I think everyone jumped on the SAFE bandwagon purely for the money. 

What’s really interesting is the big state of Agile report from Version One that comes out every year, shows that the number of organizations using Safe has dropped from 53% to 26% last year. So there’s been a massive reduction in people using Safe. And I can say anecdotally that our largest local safe certification providers just shut down their safe courses. So maybe people were starting to realize how bad it is. .

Shane: Well, They probably can’t afford to get retrained every time there’s a x version coming out. I like the idea of it as a pattern library. I still see that as massive value.

Murray: It’s not though. Disciplined Agile Delivery, what Scott Ambler talked about is a pattern library. But I am actually safe trained. Remember I went and got my certification and I coached a big safe team in a Telco and when you get right inside in safe, it’s a whole lot of super detailed processes. 

Shane: Yeah, So I agree that it’s not a pattern library where you can define your own way of working, and I believe that’s what every organization should do. But because SAFe is made up of a whole bunch of patterns that everybody else invented and iterated somebody once told me it’s the best place to go to get a single documentation repository where you can see every pattern that somebody else is implemented and decide which ones make sense to you. So from that point of view, it has some value. 

But that’s the other thing that was really interesting for me. Is , I’d love to actually go back and retrospectively work out whether our guests came out of a development stream or a product stream or a leadership stream or a military stream or whether they came out of XP or they came out of RUP because a lot of those patterns we can see happened years before the manifesto turned up.

Murray: I think organizations can be agile. In fact, we just had an interview from Evan Leybourn from the Business Agility Institute. And he talked about how agility is something that organizations can have throughout and that it’s key to resilience and growth.

So how do you scale then? I think Spotify model can work but you can’t just copy it and implement it in your organization. In fact, one of the things that came through very strongly was you can’t just copy somebody else and expect it to work because they developed a solution for their situation and for their skillset, their workforces. That worked for them. And also a really large part of successful transformation is going on the journey. It’s not the destination. It’s the journey that makes all the difference. It’s the fact that you are getting together and developing solutions to your own problems.

So you’re embedding continuous improvement in what you’re doing. And the solution you’re coming up with is always just the best we can do at the moment, and then we’re going to improve it again later. 

Shane: Yeah, for me, if you’re applying a pattern, you’re making a bet. You’re saying, I think I have this problem, and that may be certain or uncertain that you do. I think this pattern that I see somebody else using will solve that problem for us, given our context. That’s a bet. So treat it like a bet. See something that has value, implement it, try it. If it doesn’t work, throw it away. If it does work, keep it. If it looks like it works, but not quite, then iterate it for your context. And often we lock in our way of working as an immutable thing . And that’s broken. 

Murray: So the pattern libraries for scaling I think the one I like most is the one that came from Jurgen Apello with his UNFIX model because he looked at all the different models and wrote them up in a really easy to understand way. 

I also really liked Scott Ambler’s approach in the book. Choose your wow, which talks a lot about the specific tactical things you can do with teams that Juergen doesn’t get into. So those two go well together as pattern libraries, I think.

So a pattern approach you identify a problem. You say, let’s try this pattern, try it and see let’s take a bet on it and see what we can learn from it. And then if it works scale up, but don’t just apply the Spotify model, to your organization and then stop learning.

Shane: Also, you’ve got to remember, the concept of patent domains, so yes, Matthew Skelton, with team topologies is probably, the most famous one for team design over Spotify model. But that is patterns for team design. We need patents for mindset, we need patents for development, we need patterns for everything else. Look at your whole way of working, segment it up into domains, and then make sure you’re constantly betting and testing patterns in each area.

Because if, even if you’ve got the perfect team design, if your development process sucks, or if you can’t scale your infrastructure or you can’t scale the way you pay people, you can’t scale the way you onboard customers or your customer journey you’re going to fail, you’re going to get a bottleneck.

And so the key thing, as long as you’re continuously improving each time you find a bottleneck, then that’s a good way of working, but I’m with you in that you can’t pick up somebody’s template, somebody else’s A3 diagram and apply it to your organization because some of those things will work and some of them won’t.

Murray: Yeah, and also, every pattern has a light side and a dark side. It’s meant to be used for the light side, but there’s also anti patterns in how you implement scrum, for example, that Stefan Wolpers talked about. And OKRs, OKRs are very simple pattern really, and yet it’s used in a lot of really bad ways. Always behind this there’s this mindset of we’ve got to micromanage people and control people because everyone’s lazy and untrustworthy. At the core of it is this theory X, theory Y mindset.

Shane: And also, when you apply a pattern, when you make a bet you learn something and that learning is often more important than anything else. When we have Ryan on around the Amazon product development process it was completely different to what I expected. The way he described it was nowhere near what I thought they were doing. So again, patterns have value, but we can’t, pick up somebody else’s work and apply it directly to the way we work and expect 100 percent fit. 

Murray: Yeah, I agree. 

All right. Should we do a summary? 

Shane: Yeah, look it’s been an amazing run. I got to give you credit for the quality of our guests, because that’s all your work. I think if we didn’t have the quality of guests we have coming on, that keep teaching me something new and the massive amount of learning that I get out of a hour and a half recording from talking with our guests, then I probably would have been bored by now.

So yeah I’m looking forward to the next hundred amazing people that you manage to find and come on the show. I think part of that is you are quite brutal in your criteria for somebody coming on. But I think that’s the key is, doing that research beforehand to make sure they have something valuable to talk about. They can talk about it. And that when we do want to deep dive into the meat and potatoes and understand how you can apply this then they’re able to articulate that. And I think that’s part of the value of the podcast that we’ve been doing.

Murray: And I’m always very interested to hear from the audience who else they want us to interview. 

Just to summarize for me, I think we are encouraging everybody to adopt a critical mindset to all of this. But the other thing I noticed was what a huge gap there is between what people are currently doing in practice and what they could be doing if they implemented the approaches described by our guests. Because we have all these brilliant people who’ve actually done this stuff in real life at various companies around the world and got fantastic results. And, in practice in the industry, people are only doing about 10 percent of what’s being recommended. So dial it up to 11 as Spinal Tap said.

Shane: I think part of it though, is the cognitive load to be able to take, somebody who’s talked on a podcast or reading their book or going on their course and then taking the core of what they’re talking about and apply it in a completely different context. That is hard. Yes we don’t, adopt everything they say, but I don’t think we can. I think that actually to be able to do what they’ve done is impossible. But like you said, take as much of it as you can and apply it and see if it works for you. 

Murray: The hard part for me is convincing other people to allow you to do it. It’s not hard to read what they said and try out their patterns. I’ve found that pretty straightforward. The hard part is getting permission to do it.

Shane: I don’t ask for permission. If I get brought in to help a company, you’re giving me permission to help the team be successful. That’s what I’m there for. For me, it’s about how do I actually apply it in the real world? Yes, I understand the concepts. But actually the meat and potatoes. The how you actually apply that is where a lot of difficulty is. And that’s why I really want to experiment with is this idea of a dojo. I’d love to get somebody from Walmart, who actually started it on to deep dive, but we had a lot of our guests talk about it.

And this idea of learning while doing intrigued me since we first talked about it. Reading a book, doing a course is great, but that immersive learning by doing is probably the best way to learn these patterns. 

Murray: That was Brian Finster we had who talked about dojos at Walmart and he was really involved in setting those up. Maybe it’s just me, but I find it quite easy to read a book and then, apply the ideas that they’re talking about. 

Shane: And that’s part of the podcast, right? It’s often we don’t agree and, it’s always good that we can actually agree to disagree sometimes.

Murray: Yeah it’s been very interesting learning experience, a very interesting deep dive. I feel like I don’t need to go back to uni to learn these stuff. Cause I’m learning it through, our guests.

Shane: And, if somebody wants to come on the show, the key criteria is get recommended by somebody else that we respect and trust that you should come on the show. And then, you’ve got a good chance.

Murray: What I look for is people who are saying interesting, smart stuff. I often come across them through LinkedIn or through recommendations. Often they’re people who’ve written a book, but not always. Some of them are just, practitioners who’ve just really interesting and have a lot of experience. 

Shane: Yeah, so we should probably harvest from YouTube or some of those other areas where there’s content creation that’s not a book because there’ll be some interesting learning and patterns from that area as well.

Murray: I have been going through Gene Kim’s DevOps conference stuff recently and finding people there that are interesting to talk to. I think actually the DevOps community is doing much more to push things forward than, The Agile community these days.

What about Datamesh Shane? Is Datamesh worth going into still?

Shane: My personal opinion is it’s a great set of principles that have been around for years that we’ve tried to attain. It has very little meat and potatoes under the covers, very few patterns that help you implement it. I had an original definition of it, which I thought was highly valuable for organizations and it looks like the market’s moved away from that definition. So I’m not a great fan of DataMesh.

Murray: Yeah. Anyway. Just to wrap things up, we love to get feedback from the audience. Very few people actually give us any feedback. But we love it when we get feedback and we’re very interested to get recommendations from the audience on interesting guests to talk to.

Shane: yeah. Or interesting domains, give us a domain that you’re interested in and then Murray will do his magic and find people who can talk authoritatively and with passion in that domain. We’re currently on leadership. Who knows where we’ll go into next.

Murray: I want to pursue the safety domain a bit more. I thought Ron Westrum was great. And one of our listeners referred me to a number of other safety professors. So I might try and get some of those people. Who’ve we got coming up? We’ve got John Cutler the Northstar product guy. Nick Fine is, who is a UX thought leader. Diana Larson, who’s the author of the book great retrospectives, I think it’s called. And I had a recommendation from one of our listeners to go and talk to Vanguard Consulting. They have this systems thinking method, which seems really interesting and really effective. 

Shane: We have never planned the domains or the subjects we’re going to go focus on. We’ve just happened to have agility and end up in somewhere interesting and then go, cool, let’s find some more people that can talk about this because this is tweaked both our interests and we want to learn more. And I think that’s a great way of running it.

Murray: So there we go. I think we’re done 

Shane: We’re done! As, Bob and Josh says, can we put a fork in it?

Murray: Yeah, I think so

Shane: we’ll catch you on the next one!

Murray: All right. See you later.