Join Murray Robinson and Shane Gibson in a conversation with Kyle Griffin about uncertainty, complexity and change. Our requirements are probably wrong. So show people and build small bets. Our plan is likely to be wrong. So let’s do things to mitigate our plan, being wrong. Our estimates are going to be wrong. So don’t rely heavily on the estimates being right. Our code’s going to be wrong. So design your code to be easy to change. Agile is good because at its core Agile is a system for dealing with uncertainty effectively.

Read along you will

Shane: Welcome to the no nonsense agile podcast. I’m Shane Gibson.

Murray: And I’m Murray Robinson.

Kyle: I’m Kyle.

Murray: Kyle Griffin ?

Kyle: Yes.

Murray: So, I saw your post recently on uncertainty in LinkedIn, and I thought it was really good. I want to talk to you about uncertainty and complexity theory and its relevance to, the technology work we do. But could you start off by telling our audience a bit about yourself?

Kyle: I grew up as one of those really geeky kids that was interested in math and science and programming. I was taking college programming classes when I was nine. And then I grew up and I said, that’s all fun, but you know what? I really love. I love teaching. And so with my big math and science background, I went into teaching programming, teaching software, and in the year 2000, I found this fabulous thing called extreme programming. And finally I learned how to teach people to make maintainable code And then in 2001, the XP people got together with a couple other people and said, oh, let’s call ourselves agile. So I followed that path and for the last 25 years I’ve taught programming and agile and coach to agile and run agile transformations and studied organizational change to figure out why agile transformations fail so much.

Murray: So? Do you consult in house, on a full-time basis clients or not?

Kyle: I have been independent for most of the last 25 years. Right now I’m working for the international consulting firm C prime.

Murray: Oh thats where Scott Seivwright came from.

Kyle: Yes. And there’s a bunch of folks like Michael Koustars consults through C prime a lot right now. So there’s a bunch of our LinkedIn friends who do. It’s a relatively larger, broad, agile consultancy. Before C prime I independently ran transformations. I would go in and teach classes. I helped some organizations build internal coaches instead of external coaches I do six month boot camps of learn to program , I bill take class on technical agility for a thousand developers and manage those people running through the classes for an organization.

Murray: What’s your exposure to uncertainty and complexity theory?

Kyle: So I have a math degree. One of the interesting areas of math is nonlinear dynamic systems also called chaos. Some problems are so dependent on initial conditions that the floating point, arithmetic precision that a computer can offer you isn’t good enough to get predictable results. If a butterfly flats, his wings in China once that can cause a hurricane in Kansas next week. And if he didn’t flap, it wouldn’t be a hurricane because that’s how sensitive initial conditions on earth is whether our earth sweater, isn’t the only system like that. It turns out that there’s lots and lots and lots of systems like that, including gravity. In most conditions, unless you have two enormous objects, like say the sun and Jupiter that dominate the entire system. If you have three bodies near similar masks, you don’t know what’s going to happen in the future. Predictability isn’t there. My foundation for understanding uncertainty is just doing the math of unpredictable systems.

Murray: Okay. So you wrote a post recently called agility in one lesson, we’re likely to be wrong so lets mitigate error sytematically. Can you just talk us through that?

Kyle: Sure. The foundations of agility is feedback systems. Why do you need feedback system? you need feedback systems if, and only if you are likely to be wrong. If you know what’s going to happen, then make a plan based on what’s going to happen. And if you don’t know what’s going to happen, then you really have to go out and figure out, what’s happening now, what’s happening now. You can’t follow your plan because your plan’s going to be wrong. And that actually covers all of agility.

Kyle: I know what’s most important to the user, except I don’t. I’ve got a guess about what’s most important to the user. And when I show it to them, they’re going to change their mind about what’s most important. Our requirements are probably wrong. So show people and build small bets.

Kyle: Our plan is likely to be wrong. So let’s do things to mitigate our plan, being wrong. Make loose long-term plans instead of tight ones. Check in how we’re doing every few weeks. Do a demo every couple of weeks. Let’s do a little bit of planning every day to figure out what we’re going to do next.

Kyle: Our estimates are going to be wrong. So don’t rely that heavily on the estimates being right.

Kyle: And then our code’s going to be wrong. There’s all sorts of things that come up in the code, especially as code changes. So what are you doing to make it easy to change your code? When you find out that it needs to change?

Kyle: There’s a lot of social activity and agility. Why do I need the social activity? Why don’t I just ask Shane to write the whole thing for us? Because now I’ve got an extra brain helping to protect against the error that I know is going to come up.

Kyle: I want to push for people to be less certain about their opinions, about the future. And because I’m going to be wrong, I need agility.

Murray: you can derive all of agile from this basic assumption?

Kyle: My foundational claim is agile is good because agile is a method of handling, being wrong.

Murray: I wanted to add something to your examples. Our process is likely to be wrong. So lets adopt a light weight malleable process. Check how are we going every few weeks and then improve our process.

Shane: Murray, you’re wrong. you need a well thought out methodology. That’s on an, a three diagram of lots of boxes. And every 90 days book, some immutable things that you can’t change. Cause , you’re right.

Kyle: I’m a huge fan of saying, look, if I’m likely to be wrong, then it’s really important for me to respect the positions that I disagree with because they might be right, I could be wrong. And so I’ve spent a lot of time working on, Hey, under what conditions is a plan centric or spreadsheets driven approach good. If you’re going to be right about what the future holds. Go ahead. Do it with your spreadsheet.

Murray: But when does that happen, realistically?

Kyle: That’s the question. I think that all of modern business software falls in the you’re going to be wrong domain.

Murray: Yeah.

Shane: When people say, when do we use waterfall over an agile approach you often fall back to, engineering or road engineering of building. You’re not going to iterate on that. And yet in New Zealand, we’ve just had a major highway built. It was many years late. I mean, COVID hurt. That was, it was uncertain. There’s some other problems. They didn’t follow the plan. They base course down and they had to redo the work. So, they, weren’t doing a lot of quality or testing upfront, but if I put the lens on what’s the chance they’re going to be wrong. Versus what’s the level of certainty. And in what areas are they likely to big wrongs and that’s a good lens to put on it, that’s where we want to iterate get fast feedback loops for those things that could go wrong. So they’re probably built some motorways before. The probably had some experience of where it’s likely going to wrong. And so that’s what I should focus on. Rather than saying the certainty in everything they do.

Murray: So I talked to a guy at Civica who are a big construction company, build a lot of roads, he said that the requirements that they get in the tender are not what they actually do by the end of it. When they building roads about, 20 or 30% of it will change because first of all, the council, or state government who’s asking them to do it will get lobbied by people who say I don’t like this and I don’t like that. So they’re going to have to change it. And then there’ll be pipes that they weren’t sure where they were, or the clay is not right, or there’s big boulders. Or just things that were wrong in the original design documents. Said they have to change.

Murray: So I think software is far less certain than building a road. And yet, for some reason we have project managers all the time saying no, it’s predictable. They want it to be predictable. This is what’s going on here. You’ve got managers who want it to be predictable. So they say it is predictable because that gives them a feeling of control.

Kyle: So let me say it differently. They are coming from a world where you say, I need to produce a million sheets of paper. We’re going to produce 10,000 sheets of paper every day. How long is it going to take to produce a million? That is a domain that is predictable.

Murray: One of the main principles of production is to drive out on certainty. That’s what six Sigma comes from six Sigma is one in a billion chance of a change. That’s what we need in order to produce Piper consistently and reliably and at lowest cost. that is a domain where agile wouldn’t be appropriate. I wouldn’t want to produce my sheet paper one time, each time having a sprint planning in the retro.

Kyle: So I understand that there is at least one organization that has done waterfall really well. So what’s the most dangerous thing you can think of that has a people involved that you would like software to be right on

Murray: Landing on the moon.

Kyle: bingo, so building software for the moon landing or for the space shuttle, was this incredibly well done waterfall method, get the requirements, write down all the requirements, check the requirements, do testing on the requirements line item that we have checked every sentence and period of the requirements, reconfirm all of that. And then go on to the next phase. They did it perfectly and extensively, and there were no mistakes and it was a fixed platform, the space shuttle, and they did waterfall really well.

Murray: The canonical paper on waterfall software development came out of NASA

Kyle: Winston royce.

Murray: Yeah. Royce worked for NASA and he said, most people think you’ve got to develop software in this stage process with different teams. But I strongly recommend having worked at NASA that you do everything twice, that you build a prototype first, and then you build the real thing because that’s what we do at NASA.

Kyle: That is my number one. Favorite line from that paper is yeah. Do it, burn it, do it again.

Murray: Yeah, so he was very big on prototyping, but that’s not what people took from it.

Kyle: So who is the most outspoken. Let’s do this iterative guy in the world today in business. I’d vote for Elon Musk. Wait doesn’t he do rockets. So you think that the most dangerous thing you can do is build rockets. And so that’s clearly the right domain for waterfall. And yet the best guy doing rockets today is running a highly iterative. We’re likely to be wrong. Some of these rockets are going to explode approach. So I have one, Hey, this is the best waterfall process I’ve ever seen. And yet the people doing that stuff now aren’t doing it that way

Murray: also jury. War time when time is of the essence, everybody stops doing that. So example, in world war so Lockheed Martin had their skunkworks and, if you go and read through the rules of the Lockheed Martin skunkworks, it’s all very agile. Before anybody called it that.

Kyle: The 14 rules from skunkworks is the best of the pre agile framings of agile stuff that I’ve seen.

Murray: For example Germans developed the jet engines and then the British developed it after seeing it. And then America wanted one. So the British gave the, USA air force, a jet engine, and they went to Lockheed Martin skunkworks and say we need a us pipeline for this engine. You’ve got 90 days and they succeeded.

Kyle: And what’s interesting to me about the skunkworks rules is how much of it’s social, if you want this high for forming iterative team. You can’t micromanage the smart people doing the work, there’s a bunch of stuff on the Lockheed Martin 14 points that is social driven rather than, Hey, here’s how you have to do the management. It hearkens to psychological safety stuff even.

Murray: Yeah. I did my waterfall stuff at a big Telco and my manager there said we got this from NASA. We had a group of consultants come in and they said this is how NASA does that, so we said there was good enough for NASA. It’s good enough for us. And the result was that everything was always late. Everything was always over budget. Everything always had serious quality problems. And, there was always series of crises in which people got fired inthe middle of it. Every time, usually by a lot.

Kyle: One of my favorite to discussions is, okay, so you’re doing waterfall. How are you cheating? Because we know everybody’s cheating, you are moving gold posts, you are changing numbers. You are, I didn’t see that. There’s all sorts of stuff going on. And there’s always all of that stuff going on. I have never once walked into a place where the cheating wasn’t happening. Sometimes we’re willing to admit it. Sometimes it takes work to uncover where the cheating is happening. But it’s been a game of mine for awhile. I got really excited about the chaos report back in the late nineties when it started coming out first and every time I look at an organization, the chaos report seems to describe the real situation better than whatever other official numbers we’re running into.

Shane: wonder how many agile coaches go into an organization and just sit and observe at the beginning of their engagement to see what’s going on, to understand the way they’re working. I get the impression that a lot of them are going in and just bringing out the playbook on day one and starting to direct. So they’re not observing theyre not inspecting. They’re just going straight into a adap.

Kyle: The biggest problem I have with the agile industrial complex is we are peddling solutions instead of figuring out what problem needs to be solved.

Murray: Okay Can you Tell us a bit more about what complexity theory is and how it might be applicable to us in software development?

Kyle: I tend to ask one question, how good are your predictions? So you say here’s my estimate. Here is my estimated error level. Here is the confidence that I have of the error level. So a good measurement, includes a center, a range, and the level of uncertainty. How long term can you make your predictions? When I’m talking about complexity theory? That’s almost the only question I want to address because the other things confuse people.

Kyle: They say, oh, this is a complex domain or a chaotic domain. NO how good are your predictions? If you can tell me, my predictions are within two days a year out. I know a lot about what your system can do. And if you say my predictions are within three weeks, On a one-week estimate. Then I know something else about the system you’re talking about.

Kyle: You can go play in spaces and look at the difference between adaptive systems. You can look at what we call NP, complete systems, where you can’t find the best answer, unless you try all of the solutions. You can talk about adaptive systems. You can talk about complex adaptive systems. You can talk about the VUCA systems that the military likes to talk about. You can talk about the wicked systems that the complexity theory people like to focus on. how do you win a war in Iraq? That is a complex system. How do you make peace in Iraq? That’s a wicked problem. We don’t even know what the question is much less what an answer should be. And there’s real. Science on this topic of wicked problems.

Murray: So design thinking people talk about wicked problems. What does it mean?

Kyle: A wicked problem is one with low predictability, no reversibility. You can’t try this solution. And then that one, because once you’ve tried this solution, the state has changed enough that you’re in a mess now and you have to actually figure out what the problem is. And high consequence. So there are big negative consequences to getting it wrong.

Murray: Shane. What do you, think about all this complexity stuff?

Shane: I think a good lens. So, from a data world we struggle with applying Agile principles and patterns more than the software world. And that’s because we have less control over the data. So, in the data world we tend to get given something, we have no control over and it’s normally in a complex way, and then it moves on a regular basis. We have no certainty. So that, makes sense to me.

Shane: Also , one of the things we’ve had coming out of the podcast on a regular basis is the difference between organizations that were started in the two thousands forward and organizations that were started in the seventies. And so I think about the ones in the seventies they’ve grown bigger, they have become more complex. And so they then have a perception of certainty, because they have hierarchies, they have ways of working that are immutable. Everything’s documented. Everybody knows how it works. And like you say, you look under the covers, everybody cheats. So this idea of complex organizations where there’s a sense of certainty, but there’s not then that brings another lens on it for me as well. I think startups don’t build complexity in day one. because it’s small teams, they worked together, they haven’t built complexity into their systems yet.

Kyle: A startup’s operating in an uncertain world. the game in a startup Is can we pay our team next month? We are running adaptation. The notion that I have a product and that’s what I sell. That’s laughable in the startup world.

Shane: Look at the mindset. Facebook, Google, apple. Look at the way they work. Look at the organizational structures. My understanding is they have agility as a mindset built into the organizations, especially when I use your lens of likelihood of wrongness. They know they’re going to be wrong. And so they put of working in to mitigate that early.

Murray: I was wondering if you could take us through some patterns in this space. The one I know best is the Cynefin framework. Some people think it’s the answer to everything, some people think its useless. I think it’s overdone actually not really very closely aligned with what people are saying in complexity theory. What do you think about it and what are some good patterns to deal with uncertainty, complexity and change?

Kyle: Cynefin has helped a lot of people understand that there are systems that aren’t predictable. There are a lot of people who go in going, oh yes, I know how systems work. They work. like vending machines. You put in a dollar and you get out a soda. That’s how systems work. Cynefin has done a very good job of saying that’s how some systems work, not all systems work that way. Sometimes you put in a dollar bill and the machine falls over. The people who I’ve argued with recently about Cynefin, have said it’s a sense-making framework. It helps people think about the problems.

Kyle: I’m a math guy. I come from numeric uncertainty for 40 years, so Cynefin doesn’t help me very much. It doesn’t impact my mental model, but it seems to have impacted some other people’s mental models in ways to help them appreciate. There are different kinds of systems. I’m not a fan of the particular breakdown. I hate to the word chaotic as used in the Cynefin frame because it doesn’t match standard usage of the word chaotic.

Kyle: it’s not dealing with topics like VUCA. It’s not dealing with topics like wicked. It’s not dealing with adaptive systems or, N P complete systems or even perfectly understood systems that are still not predictable. Those are the areas that are interesting to me. And so I have lots of quibbles with it. You want to understand complexity. I’m going to recommend Doug Hubbard’s book, how to measure anything. an estimate has a center or range and a likelihood. If you can just get that idea deeply embedded in how you think about things. I think that is the most powerful thing you can do to understand uncertainty. Getting used to saying it’s about 50%. I’m right and about 50% time wrong is a skill that everybody should have if they are dealing with estimates or futures at all.

Murray: So putting that aside, if you are in this uncertain complex domain of software development ,what are the patterns for dealing well with it. Now I suppose we should say agile is a pattern for dealing well with it, but maybe there’s some other ones as well.

Kyle: One of my recent friends says as a foundational principle, do something little and check to see if the little bits are the right little bit. don’t know how much else you need.

Kyle: There’s the whole domain of how do you work together with other human beings. You make sure everybody’s brain gets involved and you don’t try and do all the brain, work yourself. That’s an important pattern that is maybe not appreciated well enough.

Murray: So One patterns is when things are uncertain talk, to a lot of people, get a lot of ideas and act, try something and if it works, do more of it, and if it’s not working do less of it. I’ll have my million dollars now please.

Kyle: Well, Yeah, but what you said and pick a small piece, because doing a six year piece, doesn’t get you what you want.

Shane: And figure out how you’re going to measure it before you do it because having a conversation, understanding what you might measure actually helps you articulate and plan for what you’re going to do.

Murray: That’s often the hardest part.

Shane: It is it’s okay. It doesn’t have to be exact there is no certainty. Predictability never happens. Have a guess at what you might measure and if you’re 50%, at least you’re better than you were with. Not guessing what you’re to measure.

Kyle: I will say that in this domain, we’re talking about the speed at which you can get feedback is more important than high precision on your feedback.

Murray: I would also add Mission command as a pattern in this uncertain complex domain. The idea is that when you’re briefing somebody who reports to you, you say, this our goal. Let’s talk about why its an important goal. And then let’s work together to plan how we’re going to achieve that goal. And then, go and try it. And you are authorized to do whatever you need to do to achieve the objective. So I expect you will change your plan the moment you encounter the enemy. because thats the thing about plans and warfare. The moment encounter the enemy, your plan comes unstuck and you have to do something else. Im back in base, a long way away And you’re there on the ground. So you are in a far better position than I am to make decisions. So I’m going to push the responsibility down as much as possible. So the former head of NATO said, we train our commanders to push decision making down until it hurts and then push it down more Cause that allows you to be agile and flexible on the battlefield. You can see this in the war, in Ukraine, where the Russians get written orders from their generals, and they do exactly whats written in the order and nothing else if they, deviate from the order, then they get shot . but the Ukrainians have had NATO training where its all about mission command and pushing decision making down to local teams as much as possible. And you can see how the Ukrainian army has been amazingly effective with a smaller army.

Shane: and If you look at it in corporates, , how many managers sit in the boardroom and tell people what to do rather than, lead and say, this is the goal of the organization and empower the people below them, to achieve that goal. So we’ve seen this as a theme on the podcast, time and time again, that it’s about leadership and goal setting, not about management and managing the tasks.

Kyle: So when people say, Hey, where do you think agile came from? I have half a dozen answers. A lot of people would like to say science because it’s hypothesis driven. Science is the theory. Hey, I’ve got an idea. It’s likely to be wrong. What are we going to do about that? That’s the foundation.

Kyle: But then agile is about working in teams under conditions where you’re likely to be wrong. And when I think about agile, I lean hard into mission command as very foundational, because that stuff went through Boyd and then Boyd went on to influence the entire us Marine Corp.

Murray: Yeah, maybe we should go to summaries Shane.

Shane: Excellent. Allright. I’ve got lots of takeaways from this one. So I love this idea that there is no such thing as predictability. It doesn’t exist. So let’s stop pretending that it ever did and work on the basis it doesn’t, and then figure out ways of working that solved that.

Shane: I love the idea that, we need feedback systems because we’re probably going to be wrong. And so the whole idea of, agile is saying, well, we gotta be wrong. So what can we do to give feedback to know that earlier than if we waited.

Shane: What we get constantly on the podcast as a theme, allthough, agile manifesto and Agile principals have done a great job of, having a common language that we’ve all adopted. A lot of it’s been around before XP those kinds of things. And so for me, I’ve learnt today about Lockheed skunk works and the fact that there were 14 rules, well before the agile principles of manifesto come out.

Shane: So again, we’re adopting patterns and ways of working that have been proven time and time again. And the last one for me is this idea of wicked problems and that, , effectively, there’s no definitive formula for wicked problem. As soon as you find an answer, everything else has moved. And so the, solution won’t work because nothing stable. So we just have to, bringing the feedback loop. We know we’re going to be wrong, so let’s get early warning and how we can change it. So that was me, Mary, what have you got?

Murray: Product development is probably a wicked problem a lot of the time. There’s not one problem with one solution. There’s a problem set, people disagree about. And then there’s a set of potential solutions to those wide range of problems. So this is where system thinking comes in.

Murray: So I think that there’s a big problem with management thinking. Managers who are saying , software development plans should be predictable and I’m saying theyre fundamentally not. And I think that agile and complexity theory are based on uncertainty and they based on this big revelation that happened in physics as people moved from Newtonian physics to Quantum theory. There was this whole shift during that light enlightenment period, when people suddenly realized that a lot of stuff is uncertain. Even maths is uncertain Because in math, you can write a statement that says this statement is false, how can this statement be false if the statement is false? At its very root. Everything has uncertainty and Newtonian thinking doesnt accept that. And Taylorism and that sort of managerial thinking, doesn’t accept it.

Murray: There’s this whole concept within managerial thinking, which I think comes from aristocracies and imperialism and early modern ideas that there is an authority who knows what the problem is and what the solution is, and you just have to do it. In the workplace, Taylor said, the worker is an idiot and they’re going to be lazy and do as little work as possible. so you need a group of talented engineers who work out what the work is. And tell people what to do and put in place a system of rewards and punishments so that they do it. So there’s this real class system ingrained in older organizations as Shane was saying. And then it’s just this real idea a lot of managers heads and in a lot of organizations that software development should be predictable. We’ve been doing it for enough time now that we should know what happens. And therefore I’m going to make a plan on the basis that it is predictable. I’ve heard cIO is a big corporations say things like software is predictable. We should be able to crank the handle and get out the result we expect should be like a sausage machine. And those people are completely deluded in my experience, but I think they’re saying it because that’s how they want it to be. It’s very important for them to be in control. And so therefore they say the world is controllable. If you just try hard enough. And the only reason you’re saying that it’s unpredictable is because you’re not trying hard enough to nail things down. And that’s where theory X and theory Y comes in. I think because theory X is all about the world is controllable and I’m going to control it. And you and theory Y is more the world isn’t controllable and we all have to cooperate so we can learn. .

Kyle: I always want to say the nice version of this. CIO is have a high turnover rate, an awful lot of the high turnover rate is that they’re saying, Hey, here’s, what’s going to happen. And it’s predictable. And then it’s not, because it’s not on the other hand, how do you get somebody to hire you as CIO if you’re here saying, I know you want that to happen and it might, or it might not, but we don’t really have the level of predictability to give you what you CEO want. How does that go? Politically?

Murray: I would say we, can deliver an outcome in a fixed time for fixed costs. As long as you’re prepared to be flexible about the scope. What we need to do is focus on the goal and the measurable outcomes you want to achieve like lead generation or increase in average basket size or increased speed of performance, decreased failure rates, whatever it is. We will give you as much of that as is possible with the money you want to spend in the time you want to allow. If you let us be flexible about the scope, if you try and nail down the scope upfront and the time and the budget, you’re not going to get any of those things. It won’t give you the scope the time or the budget, and it will be crappy because trying to nail down the scope causes enormous problems in all other areas. It always does. It always will. And anybody who says it isn’t is just lying or delusional.

Kyle: My experience is your a hundred percent correct in what you said and the odds that I can get to that to go over politically to very senior management is not zero, but it’s also not very high.

Shane: Yeah, successful CIO’s are leaders. So, they go into an organization and they have the conversation before they go in to say, I’m not here to manage the work to be done, I’m here to take the organizational goals and articulate it to the technology skilled people so they understand the goal and then empower them to achieve that goal with you. And that’s what a good CIO does. They become a leader. The problem is a lot of the CIO roles are filled by people that used to be technology managers.

Murray: Okay. Kyle that’s been really great having you on it. How can people find you? Do you have a book? Do you have websites?

Kyle: I’m mostly, find-able on LinkedIn. Secondly, I have a couple of books. I have a book called the scrum princess, which is a fairy tale telling how scrum works. It’s much more memorable and purpose-driven than the scrum guide. And second, I have a book on the use of ceremony in business. Humans are fundamentally social creatures. We have lots of emotional social behavior. And why are we trying to hide all of that from business?

Murray: Yeah.

Murray: Well, thank you very much for coming on Kyle.

Kyle: Thank you, Murray. Thank you, Shane.

Shane: Excellent catch you later.

Exit: That was the no nonsense  agile podcast from Murray Robinson and Shane Gibson.  Thanks for listening.