In this year’s edition of the Leading Complexity program, we are privileged to welcome Kent Beck, the mastermind behind eXtreme Programming and a distinguished signatory of the Agile Manifesto. Dive into our interview with Kent as he shares insights on navigating complexity and offers invaluable guidance on addressing it.
Summary of the video below
The discussion revolves around the concept of managing complexity in projects and organizations.
- Four Factors Model: Presented by Professor Zaninotto at an early eXtreme Programming (XP) conference, this model highlights the dynamics of complex situations. The four factors include:
- Interdependencies: Elements within a system affect each other, leading to a chain reaction of consequences.
- Multiple States: Each element can exist in various states, making predictions difficult.
- Variation: Both external and internal fluctuations affect the system, making elements behave differently even in known states.
- Irreversibility: Changes made to the system can’t always be undone, leading to permanent consequences.
- Application to eXtreme Programming: XP tackled the fourth factor of irreversibility. Before XP, software development was linear and inflexible. XP introduced the ability to embrace and adapt to changes, making decisions less permanent and more flexible.
- Advice for Leaders: Leaders dealing with complex scenarios, especially on a large scale, need to address at least one of the four factors. The interdependencies between teams, especially in large organizations, can become bottlenecks, affecting the entire system. Leaders might need to make certain processes less efficient to eliminate detrimental dependencies, aiming for broader, more significant gains. This approach requires leaders to change the rules of their game instead of merely exerting pressure.
- Leadership Pitfalls in Scaling: As organizations grow, leaders often inadvertently increase complexity by establishing silos and creating more dependencies. This isn’t because of malintent but stems from a desire to simplify operations. However, simplification shouldn’t be mistaken for understanding, especially in human-centric activities. Leaders need to recognize and avoid the “legibility fallacy” – the mistaken belief that if something appears simple, it is effective.
Transcription
Hi everyone and welcome to this interview. With me, I have no less than Kent Beck. For those that don’t know you, could you please present yourself?
Sure. Thank you for the invitation to conversation today, Tomas. My name is Kent Beck. I’ve been a geek since the early 70s. I grew up in Silicon Valley and my dad was an engineer so I’ve been doing this for a long time. Written some books. Probably best known for signing the Agile Manifesto. I was one of those 17 middle-aged white guys who wrote that and signed it. Although I didn’t write any of it.
My mission in the world is to help Geeks feel safe. Oftentimes we as geeky people feel unsafe sometimes in situations where we actually are safe like in a social situation.
But sometimes we actually aren’t safe and we feel unsafe because we’re doing things that have negative consequences and we don’t really … kind of we know it but … You know like writing code with bugs and so a part of my practices been developing tools and techniques around taking more responsibility for the work that we do. JUnit is something I wrote with Erich Gamma. Test-driven development is a way of feeling safe and secure in the work we do.
As a programmer, I must thank you very much for those tools. It’s been well used, I must say. So you will be in this program called leading complexity and you will be talking about the four factors model. Could you tell us a little bit about how you see complexity, how you define that, and what the fort factors model will bring?
Sure so at an early eXtreme Programming conference, we invited the dean of the school of Economics at the University of Trento. A guy named Zaninotto to come and tell us from an economist’s perspective why eXtreme Programming might work even though at that point everybody was saying “No it couldn’t possibly work”. He presented this model, and it took me probably 15 years to understand what he had told us. But I have found it very helpful since then. So when you get into a complex situation where you kind of don’t know what’s going on currently and everything that you try makes things worse. That kind of situation doesn’t emerge at random. It’s a confluence of the four factors that Professor Zaninotto presented.
And the four factors are:
So you’ve got this system and it has lots of elements and one of the factors is there are interdependencies between the elements so if something happens here, the consequences flow to one or multiple others of the elements and then the consequences of that flow to others so you got these interdependencies.
The second factor is that each of those elements could be in many different states. It’s difficult to predict without understanding all the details. If this happens here, what exactly is going to happen there. And because it could be in any different state and depending on what happens there, different consequences are going to flow. Already the pictures starting to get fuzzy.
The third factor is that there’s variation externally, the inputs coming into this system, and internally so the elements don’t always act exactly the same way even if you precisely knew their states, so things are changing all the time and these effects are rippling through the system in unpredictable ways.
The last Factor, the fourth factor, is irreversibility, and this is where you can break it, but you can’t necessarily fix it. You make some change to the system, and everything just falls apart and you can’t just unfix it.
If you’re in a situation that’s complicated and where you’re getting unintended consequences and you have all four of those factors present, you’re out of luck. There’s nothing that you can do to kind of bring that system back in even some sort of dynamic equilibrium.
In the case of eXtreme Programming, it’s the fourth factor that we address. Software development before that was very irreversible. You do an analysis document and that was exactly the system that you were going to build even if you made mistakes. Then you’d build a big design document and that was exactly the system that you were going to build even if you made mistakes. You made all these irreversible decisions. In eXtreme Programming, the subtitle is “Embrace change”. If you discover that this isn’t the system you want, you can just change. Very few of this of the decisions and eXtreme Programming projects are irreversible, are set in stone, and you can’t change them. That means that even though there’s variation and there’s interdependency and there are many states, you can still try experiments and steer this complicated thing in the directions you’d like to go.
That’s the four-factors model. You have interdependencies. You have many states of the elements your variation coming from the outside and from the inside and you have irreversibility. When I’m in one of these situations, the first thing I want to understand is: are all those factors present? If they are, like software development in a gigantic bank, for example, all four of those factors are going to be present. I can’t just fix that problem by doing a little bit better job. I need to address one or more of those factors before I can have any hope of having a positive effect on the system. Does that answer your question?
Absolutely it will. But it also raises my curiosity. You gave the answer: if you’re in that situation you should be using eXtreme Programming. If I want to know the long answer to this I should participate in the Leading Complexity program and listen to your session. Do you have some advice, some shorter answers for leaders that are having a couple of teams and having a check in the box for all those four factors – what should they do?
Address one or more of them. For example, eXtreme Programming tends to work at the scale of 10, 20, 30 people. What do you do if you have a thousand people developing software? For example, in a thousand-person organization, oftentimes there will be teams and kind of organizations of teams and there will be interdependencies between the teams and it’s those interdependencies between teams that cause a lot of the problems. Now people introduce those interdependencies for reasons that make sense to them in the moment. Like, okay, so we have a security team and we’re going to do all the security work in the security team and everybody’s going to be dependent on the security team. Well, what’s going to happen next is that the security team is going to be a bottleneck for anybody else. If any of that variation happens within the security team. The leader leaves or an important individual contributor goes to another part of the company, or somebody just gets sick, or there’s a glitch in a project. The results of that are going to be felt in the entire organization.
At scale, if you introduce interdependencies to achieve economies of scale, or whatever good reason that made sense to you, you’re in that state where all four factors are present and you might need to detune your organization. You might have to make things, well actually you always have to make things worse. That’s one of the sad facts of the world, things always get worse before they get better. You may have to make things a little less efficient, micro efficient, in order to remove the dependencies that aren’t serving you in order to make larger macro games.
There’s a profound responsibility in leadership to look at the larger picture out of all the little pieces and say, not just push – There seems to be this model that leadership is about pressure and pressure actually makes things worse and reduces the amount of honest feedback that you get so you’re less prepared to deal with your problems. I’m advocating a style of leadership that says “No, if you’ve got all four of these factors present, figuring out which one you can reduce is your job as a leader”. Nobody’s going to come up with that and, you know, down in the middle of the chaos, it’s your job to see: “Okay we’re playing a game we can’t possibly win. We need to change the rules of the game”.
Very interesting, my feeling is that it’s very common that, especially when scaling up, leaders have a tendency to actually make it worse. They are putting people in silos. They are introducing platforms that it’s not really helping and especially and then saying you are only focusing on this and you should only be focusing on that kind of so creating the dependencies, even so, kind of making it even worse.
And not because anybody’s evil or stupid no that they’re trying to achieve goals in an environment though in which it’s impossible.
Yeah, they are I’m quite sure that they are making this because they believe that it makes it simpler.
Sure, I call that the legibility fallacy. If it’s easy to glance at and think you understand, then it’s good. We’re dealing with the profoundly human activity and if you think you understand it fully, you’re definitely fooling yourself.
So many wise words …
And more to come if you pay to sign up for the program. (https://leadingcomplexity.com/)
.. exactly what I was about to say. Thank you very much for filling that in for me. Great having you in the program. Great having this conversation. I’m very much looking forward to hearing the full long version of you telling us more about your wisdom when it comes to this four-factors model and how to Lead in complexity
Thank you
