Transcript

Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture podcast. Today I’m sitting down across many, many miles and 12 time zones with John Coleman.

John, welcome. Thanks for taking the time to talk to us today.

John Coleman: Shane, thank you so much for having me on the show.

Shane Hastie: You and I have corresponded and know each other relatively well. But I suspect that many of our audience will not have heard of you before. So probably a good starting point is who’s John?

Introductions [01:02]

John Coleman: Yes, probably not a bad starting point. If you Google my name, you’ll find conductors of orchestras and all sorts of much more interesting people than me. My name is John Coleman and I call myself an agility chef, the metaphor being when you go into an organization and you have all sorts of fancy ideas of what you want to do and then you open the fridge and then you see, oops, you don’t have that many ingredients. So I try to figure out what dish we can cook together, and the key thing is the co-creating. But I’m also a trainer from a sense. I am a trainer with scrum.org and proKanban.org, and I was involved with Daniel Vacanti in creating Kanban Guide back in 2020 and got a couple of podcasts myself, the Xagility podcast for executives and Agility Island for our practitioners. And excited to be here today, thank you.

Shane Hastie: Thank you so much. So thinking of our audience who are technical folks, what are the challenges that you see them struggling with when you open the fridge in the organization?

Scrum is a good framework and does not fit in every context [02:00]

John Coleman: So the options that are available to engineers, for example, when they open the fridge and they’re being given the usual options and Scrum is really good. I like it. I’m a scrum trainer myself. But sometimes the personal values of the people doing the work don’t tie in with the Scrum values. The Scrum values are very nice. The people might be really, really nice, but they might just have a slightly different belief system and it can feel sometimes like Scrum can be a form of imposition if everyone’s supposed to be committing towards the Scrum values. And maybe there’s other little things as well that they struggle with.

Some people will say, can’t you always deliver something in 30 days? But maybe some teams struggle with that. So are there other options out there available for people who struggle with some of the rigidity of Scrum? But at the same time, I do understand why it’s there is to help people to deal with complexity. Not withstanding all that, it can still be quite difficult. And what might happen is as soon as I turn my back, the team is doing something completely different to whatever the option is whether it’s Scrum or whatever the option is, design thinking or whatever it is.

Shane Hastie: How do we help them make good decisions?

John Coleman: The key thing for me is helping the team to understand what the options are. And this is something a lot of change agents need to be careful with as well. So sometimes we like to present options that are within our own fridge. We have our sweet spot and there’s certain things that we’re good at helping people with, but maybe those options don’t suit, actually. I discovered Shape Up for example in the last few weeks, which is about refining for six weeks and then delivering for six weeks and not having a Kanban board or any of these kind of things. A different approach, not so agile and so on in the way they declare it, but agile in different ways. And even if that’s something that’s not my sweet spot, being open to learning more about that. That’s just an example. But whether options that are not within my catalog, if you like, are more suitable to a team. So I think it’s important for change agents to be really open to what’s suitable for a team and not just what I’m good at doing myself kind of thing.

Shane Hastie: One of the things that you are known for is talking around complexity. What does complexity mean to a technologist?

What does complexity mean in a technical context? [04:14]

John Coleman: Eventually, if I was to really boil it down, maybe there’s some things that we haven’t figured out. And even if we get together with our colleagues, we still wouldn’t get it figured out first time. We might have to spin our wheels a little bit… Maybe spin our wheels is the wrong metaphor, but maybe go into some kind of empirical loop, try to learn something, try something, maybe use experiments to settle debates and things like that or twist old ideas from the past to deal with the problem that’s in front of us. Sometimes our expertise can be limited to deal with the problem that’s right in front of us. Maybe we even need help from someone who is in a completely different field of work. Maybe we need fresh thinking. And so when engineers feel like they’re going into analysis paralysis or they feel it’s a group think going on, it could be a bit of an indication that maybe we need to be more evidence-based and we need to be more open to how we’re going to solve the problems that are in front of us.

Shane Hastie: So recognizing that I need to be more open as an engineer, how do I step into that space because I’m actually trained to make decisions.

John Coleman: Indeed. And essentially humility gets handed to us, doesn’t it, when we do experiments. And first of all, we need to be open to running some of these experiments or probes to try and figure out what the right option might be. And I would say 70 to 80% of the time we haven’t figured out something, what we thought might solve the problem isn’t actually what will solve the problem. It might even be the wrong problem. So often are we even looking at the right problem? And within that problem, are we looking at the right people who might have that problem and do we have the right views on what those people are looking for? I remember I had some people coming to me, they were doing an executive MBA and they were presenting to me their projects for the quarter. And I remember this group in particular and they had all these slides on this persona called Caterina, and Caterina did this and she did that and this is what she wanted, this is what she needed.

And I asked them, I said, “This is all really nice information. Did you try to recruit somebody like Caterina? Did you try to talk to someone that was like Caterina to see if that’s actually what her problem was and that’s what she needed?” And they didn’t. And even simple little steps like if you got UX’ers working with you or people doing discovery or research to try and understand what the customer wants, even going along just to take notes could really open your eyes to the way your customer or end user or consumer is actually using what you’ve built. They might be using it a very different way to what you intended. It might be much better way than you intended. You might never have realized that they would do that with what you built or what you might do next. So I like the expression if people use Scrum for example, there’s a thing in Scrum called a sprint review and it’s kind of like going to an event to see what the customer asks for, but she doesn’t want. It’s very difficult to figure out what the customer wants, isn’t it?

Shane Hastie: Yes, the I don’t know what I want but I’ll know it when I see it.

John Coleman: Yes, exactly.

Shane Hastie: Which is a perfectly legitimate approach to eliciting requirements and yet so often we don’t involve the customer. But wasn’t this what all of the agile methods and these ideas were supposed to help us overcome?

There are approaches for learning and understanding customer needs [07:39]

John Coleman: Yes, indeed. And some of them do a reasonable job of helping us to deal with stuff that we haven’t figured out. Design thinking, for example, lean startup, lean UX, really good at helping you to dig deep and learn humility, even if we don’t have humility at the start, it’s like getting into a boxing ring and you get your backside handed to you because you’re not able for the opponent that’s in front of you. And what we learn when we do experiments with those approaches really helps us.

Often we also need to be able to move some of our work that we haven’t really figured out into the work that we think we’ve figured out. And being able to deal with that transition, it’s important. And so having some options that allow you to have some stuff that you haven’t figured out yet, as well as stuff that you have figured out as well as some stuff that you thought you’d figured out but now you realize you’re in the wrong place, having something that’s flexible enough to help you to deal with those kind of categories of work that’s in front of you is important.

Treating everything as though we haven’t figured it out or treating everything as though we have figured it out can lead to bad results. For example, people do standups for example, or they do daily scrums or depending on what kind of approach they’re using. And often they talk about what they did yesterday, what they’re doing today, even though they’re not supposed to do that kind of stuff. That was only ever a suggestion. Maybe what I did yesterday was so obvious and really I don’t need to go into the details of all of that. Maybe I’ve missed a trick. Maybe we should have talked about, well what do we need to work on together today? How can we help each other out? Is there any work that needs a bit of love and attention that we forgotten about a little better or maybe something’s got stuck and we need to get behind it and see if we can get it sorted.

I think teams need options that help them to deal with all these different types of complexities that are in front of them. And some of the options that are handed to us aren’t so good at dealing with deep complexity. And some of them are very good at dealing with deep complexity, but that’s what they deal with. And then once you’ve figured stuff out, you kind of need some other option to help you. And I think that’s tricky for teams to be changing approach all the time in terms of depending on what they’ve figured out and what they have.

Shane Hastie: Having to change approach though is a way that we do then adapt to make sure when we shift from that uncertainty to at least a little bit of certainty. How do I sense when this needs to happen?

Understand complexity and read the signals to know when to shift modes [10:00]

John Coleman: I believe that we need at least somebody around the team or in the team to be educated and skilled on complexity and understanding what signals there might be and helping to essentially guide the team. I mean, a lot of teams are self-managing and so on. And you don’t even have to have a team, you can have a crew. For example, airline pilots when they sit in the cabin together, they might never have seen each other before, but they’re so well trained, there’s trust already in their training and so they can team quite quickly. So crews, you can have a crew for example. But teams and crews often need some kind of guidance. Can we expect everybody to be an expert on complexity and really understand the compass that you need to read? It’s not a straightforward compass of a north, south, east and west. It’s a kind of almost like three-dimensional compass.

Does somebody understand how to read the compass that’s in front of us and at least inform the team or crew about what might be happening. And then that might give some hints in terms of what might be appropriate response types to deal with this situation. So there was a great example at the end of 2021 in the UK where Boris Johnson was trying to figure out what to do when Omicron landed on the UK shores. And he was looking at the scientists and the people who do the numbers and all that, all his medical experts and so on. And they didn’t have an answer in terms of what would happen. And then he was looking at the people maybe doing the experiments in the labs and trying to see well will the vaccines and the booster that was available at the time will they work with Omicron, and they didn’t know they would need six weeks to figure it out.

And he made the decision actually to be a little bit paradoxical, what we call aporetic and kind of asking, are we actually doing the right thing here? And I believe, don’t know, this is my personal opinion, I don’t know if this is sure or not, but I believe that he went aporetic and he said, “Okay, I need to buy some time here.” And he brought us into chaos in the UK and got millions of people to get the booster very, very quickly, more quickly than any program done before. And whether it worked or not, history will tell us, but it seemed to help the UK to be the first economy to kind of come out of COVID. And that was a great example of someone who understood that the experts don’t have the answers. The people who are even experimenting will take a while, I need to do something here.

And a lot of people think, well you shouldn’t be in chaos. Sometimes you need to go into chaos, sometimes you need to release the shackles and just do something. But as long as you’re just not doing something that’s going to make it worse, that’s the trick. So having all of these skills, can we really expect everyone to have those? I mean, I’d love if that was the case. I would just expect that there would be at least somebody either in the team or crew or around it who can help the team or crew to understand what they might be facing and help them to realize that actually if they did spend more hours than that, that’s not necessarily the problem. Or getting more engineers to help them, that’s not necessarily going to help them. That might need to do something a bit more dramatic.

Shane Hastie: Building on that, you have a new thing in the world, Kanplexity. Tell us about Kanplexity.

Introducing Kanplexity [13:10]

John Coleman: Thank you, Shane. So I was working with a team in an oil company in early 2019 and they asked for some help with Scrum and they were really, really good people. Each of them had a PhD of some sort, different types of PhD as well, double PhDs. I believe one of the ladies was publishing articles in journals and so on, really, really smart team. And they were working together on a really, really complex problem. And I had to try and figure out something for them. At the time, there’s something in Kanban we call cycle time, you might call it flow time or lead time. We won’t get into debates about what you should call it. But essentially, how long does it take you to get a feedback loop from the situation in terms of whether we’re doing the right thing. And I checked it out, their cycle time was roughly four to six months for each item.

I felt that a lot of the options on the table weren’t really going to suit them. And so I met the team and I showed them a number of options. But one of the things I did as well was one of the things I learned over the years was to learn the business domain and technical domain of the people that I’m working with. And so even though I was on Wikipedia and doing my own research, I was actually asking these people to teach me about rock pressure and drilling under the ground and all these kind of things. And I’d never know as much as these people, but at least I had some idea what they were trying to deal with. And so that kind of reduced maybe what I would’ve thought of would’ve been maybe 10 options to maybe two or three. And I thought Kanban might be an option for them. That at least could we try to optimize our flow so that at the moment their work takes four to six months, but if we optimize the flow, can we get that down to shorter than a month even?

But because their work is deeply complex, I was troubled by this and it wasn’t just that it was deeply complex, they also had some constraints as well. You hear Steve Tendon talking about TameFlow for example, and he’s got a theory of constraints background. And so I did a lot of research understanding Steve’s work in terms of theory constraints and others. And so I had this problem, we had deep complexity, we had a real bottleneck, a physical bottleneck, a few physical bottlenecks to deal with, and what can I do to help these people? And so I had a feeling that maybe they need to do some kind of review with their stakeholders every five or six weeks, maybe. And I was flexible because I noticed it was really difficult to get these… these are really important stakeholders like senior vice presidents where that means (really) important persons meeting together (although they’d be too humble to admit that).

And it was really cool actually Shane, because I learned a trick as well from the team that I was working with. I would never before have asked the team to send out pre-read before our review because I found that they wouldn’t read it, but they did send it out and they didn’t put any major ceremony into preparing the pre-read because that itself would’ve interfered with doing the work. But maybe a couple of days they spent putting together a pack and sending that out. And the execs that came in, they actually had read the pack. And then what we had is what Michael Küsters would call a a Steve Jobs style review where we were talking about the work, we were talking about what we’re going to do next. We were deciding on strategy and tactics in the review. And so that was really cool.

And then we started doing retrospectives and they were meeting every day, pretty much every day. They didn’t have planning so much, they were pulling in work as needed and so on. But they did have five to six-week periods and I was just flexible about when things happened and used really nice techniques as well in terms of helping them with retrospectives. And applied a trick as well, which I do now regardless of approaches where instead of doing really fancy retrospectives, and I did use some really fancy techniques and so on, but I realized that it was more important that the team actually got better. And so what I said to the team when they did have a retro, I said, look, let’s say you’ve got an hour and a half or a retrospective or something like that or maybe two hours or something like that.

Build time into the retrospective to fix things immediately [17:00]

We all know what the problems are in 20 minutes, don’t we Shane? So we said okay… I could have said, okay, let’s wrap it up now and we can put those items onto our list and we’ll look at those a later date or even next week or whatever. But I said, “We’ve got an hour, 10 minutes, how about we fix something right now?”

They said, “What? Huh?”

“Yes, we have an hour, 10 minutes. Do you think the lady at reception’s going to change because you want her to change?” I was just being a bit dramatic. Basically, in other words, change what’s in your control and let me deal with the stuff that’s beyond your control and I’ll work with the organization to get that stuff fixed. And we were really thorough about that. And so in the retrospectives then one of the first things we were doing is we were looking back on the things that we’d improved and they noticed, oh yes, we did this and we did that. Only one little thing every cycle if you like and to get better. So yes, Kanplexity was born so I codified it at the time, Shane, and I wrote a document on it and put it together. And so that’s how it started.

Shane Hastie: And what would the benefit be for a team to think about Kanplexity as an approach?

When is Kanplexity an appropriate approach? [18:00]

John Coleman: if you find that you need another option, if your work takes longer than 30 days, there’s lots of techniques to help you to get worked on shorter than 30 days. You can use example mapping for example from Matt Wayne where you can say there’s 13 examples for a particular item. And you can say that a team, well can we just do one example? And they say no, we need to do the other 12. Yes, maybe you do, maybe you don’t. But can you just do just one example and then let’s learn. And then you might find out there’s four new examples the next time you do a review and you might find out seven of the examples you thought you had to do, you don’t have to do it all. And so there are lots of techniques to help people to get work done in less than 30 days.

But let’s say you’ve tried all of your tricks and all that kind of stuff and you still find that they need lot more than 30 days. Having something that is flexible is important I think without losing our soul at the same time. We still want to be sincere about trying to achieve some kind of agility, but maybe having something that’s a bit more flexible that maybe you don’t need to have specific roles. Maybe all you need is a team or a crew and maybe someone who’s willing to be the guide, could be someone in the team, could be an executive, could be a change agent, and them working together to look at the compass and orient and decide what to do next. That’s a major upgrade in the 2022 version by the way, that I basically refactored it based on Kanban Guide, which was released in 2020 so I don’t have to redescribe Kanban anymore and I could just focus on the complexity side.

And in the orientation guide it indicates that if you feel you’re… It even describes which space you might be in and give some examples and so on. But then depending on the category we’ve tried to codify because Cynefin is what is based on the decision making framework from Dave Snowden and Cognitive Edge and the Cynefin company. And we tried to make it a bit more accessible for people so that okay, I’m in this area so I need to facilitate for this, I need to optimize for that, this is what I should be looking for and maybe these are some things I can do. These are some response types. So that’s been a big addition to the guide.

And the other thing that’s changed in the last three years as well is, it’s much more informed by the different types of agility out there, like the Vanguard Method from John Seddon, and product management and product leadership, like deep listening, even from Indi Young. Apparently sometimes we don’t need to have the script when we interview the customer, sometimes we should just listen to what they have to say and just really, really listen and not be derailed by our own goals.

And lots of influences. Theory of constraints and there’s elements of Agile and Lean, of course. And even intent-based leadership from David Marquet. It’s there’s a big influence there. Particularly David Marquet’s most recent book as far as I’m aware, Leadership is Language where he talks about the red work and the blue work. I believe he was on this show. And I really like that in David’s work and it’s a really simple message. Are you in execution bias? I had 200 students at a university in London in January this year, 250 of them using Lean UX and having humility handed to them by the experiments that we’re doing. 70% of them were in execution bias, they were persevering when the evidence was overwhelming that they should either stop or pivot. In fairness, some teams collapsed into other teams and I actually congratulated them for that because that takes humility, doesn’t it? To say, okay, this idea isn’t going to work.

So yes, lots of these influences are in there now and really tested it with lots of teams since those early days when I was at the oil company, worked in other sectors as well. I will confess though, Shane, that even though I have a software development background myself, Kanplexity is optimized for people in non-software. You could use it in software equally. But I was thinking, do you know what? There’s probably a need also for some options for people outside of software because the way engineers are using agility in whatever way they are. But a lot of the time there’s frustration that the rest of the organization isn’t also practicing agility and it is spreading across the organization. And often I find that some of the options available for those departments, for example, might not be so suitable. And just trying to provide something that says, for example, if you haven’t figured stuff out, maybe you do need to have a review.

But if you have to figure stuff out, maybe you don’t. Giving you some hints about when you might need to have a standup and when you might not. If everything is clearer and you know what you need to do, you probably don’t even need to get together. And also there’s an influence from flight levels as well because in flight levels they’ve got interactions, they don’t have events and some of those interactions don’t have to be synchronous. I’ve been using a tool called Loom, for example, to send video messages. I sent one only a few hours ago to someone and it’s very handy across time zones and particularly if I’m working part-time for a client or something like that, send a video and they can like or react or comment at two minutes, 37 seconds and reply, “No, I didn’t like this, John.” They can even reply to the video with a video. So being open to people not having to actually get together for some of these interactions as well. We’ve learned a lot, haven’t we, in the last few years. So it’s kind of adapted to all of that as well, I think.

Shane Hastie: Some really interesting ideas here and things that I’m sure some of our audience are going to want to explore further. To do that, John, how do they get hold of you, and where do they find it?

John Coleman: Thank you, Shane. So the easiest place to find a Kanplexity will be Kanbanguides.org, that’s plural, Kanban Guides as in G-U-I-D-E-S.org. Also, orderlydisruption.com, which is my own company or x-agility.com. It’ll be on any of those three websites. By the time this goes out, it’ll already be up there on those sites. And yes, you could find me there as well. There’s Contact Us forums at those places. And you can also check me out on the Xagility podcast or the Agility Island podcast.

Shane Hastie: John, thanks so much for talking to us today.

John Coleman: Shane, thank you so much for having me. It was a real pleasure. Thank you.

Mentioned: