Peter's full question: So I wanted to start, I know that you are probably best known for a book called “Management 3.0”, which I certainly found really influential, but I know that recently you published a new book, “How to change the world” and at a high level it seems to be, how do you deal with a bad organization, what are the approaches. Do you want to talk a little bit about why you chose to write the book and what the key takeaways from it might be?
Yes, sure, after I published my first book “Management 3.0”, I noticed that most people struggle with a topic of changing the organization. According to several surveys, it ends up as the number one obstacle to Agile transformation, the existing organizational culture doesn’t fit with what Agile expects from an organization and change management turns out to be hard and people with the necessary skills are not available, and these are all issues that deal with changing organizations, organizational transformation. So I thought “Let’s look into that a bit more” and this sort of emerged naturally into a little book, less than one hundred pages, that wanted to be written and I called it “How to change the world” because it is a topic that people struggle with.
2. And it’s specifically techniques for managing change within an organizational setting?
It’s actually a broad overview of change management, I see it from a systems perspective, you have to change continuously, it never stops, you have to change at the individual level, address people at the individual level not just rationally but also emotionally. Third part is you have to see that as a social network in which you are trying to inject a behavioral virus and you want that behavior to be copied by the other people in the social network. And fourth is you can see it as a system with a boundary, an environment, and if you tweak the boundary or the environment, you might be able to change people’s behavior inside of it - so those are different angles looking at the same problem.
3. Pulling them all together, because typically a book will cover one or the other?
Exactly, yes, and I sort of have a meta view, I’m using existing models that I’m quite honest about that, everything already exists, I’m just drawing things together and turn it into one meta model as I called it.
4. And you are also talking about things like meta beams, as you did in the original book?
I did that already in the first book, so that is not covered in the second one.
Peter's full question: So going to the first book, it also feels like it's pulling together a wide range of strands, in “Management 3.0” you literally talk about everything from a very detailed management style things, like Hygiene versus Motivators, to more traditional Agile topics, why was it that you decided to pull all that together into a single publication?
Well originally it started as an idea to write a book about complexity science and software development, because both topics fascinate me very much and then I started one or two times and failed and then I figured I have to maybe start as a blog and get some people’s feedback, doing things iteratively - what a novel concept! And then I got feedback from people on my writing, and it turns out that they struggled with management of organizations and that was an insight I had three or four years ago and that led me to conclude that I had to focus my book on the management topic. I happen to know a bit about it, because I was a manager for fifteen years, so I was struggling myself with the role of the manager in an Agile organization and trying to come up with solutions. So they gave me a bit more focus for my book that otherwise would have been perhaps a thousand pages or more. That was very useful, and I always give that as example of being Agile as a writer as well, because the audience gave me the idea to write about management , it was what they wanted to read on my blog, so that is how the book emerged.
Peter's full question: In fact maybe I wanted to ask just a little more about the emergence of the book, this is an interesting topic., I was speaking with Chris Matts earlier today, talking about his new book which is a graphic novel, and asking about the process of developing the book. So what was your process for developing this book with “Management 3.0”, was it a big design upfront? Did you do it incrementally? Did you find substantial iterations, how did that work?
I think that was pretty Agile as much as you can be as a writer, I started with an initial version of a backlog, the table of contents. You need it, otherwise you do not get a contract from a publisher, so they need to have a feel of what the book will be about and they know that the table of contents will change. And they will know that most writers are too late delivering their stuff, but for me it was a matter of honor, I said “No, I will deliver on the day of the deadline, I will try to be Agile so will commit to a deadline, and then the backlog will be fluid.” So in the end I think I implemented about sixty or seventy percent of the original backlog, but other stuff got added later that I had not foreseen earlier. Still in general the basic structure is still there of the original idea but it was modified into something else and I delivered on the day of the deadline four minutes before midnight then I was done. So I think I was quite successful at that.
Peter's full question: That is great. So I wanted to go back to some of the contents within the book. I think one of the things that underpins it is this idea of simple versus complex, complicated or chaotic systems. For somebody who doesn’t have background in that, could you just give us a brief overview of what the types of systems are and how and where software development fits within that?
Sure, according to science there are basically three types of systems, the ordered ones are the ones that we construct, like cars or machines, but most pieces of software are ordered systems, we know exactly how they behave. The chaotic ones that are totally unpredictable like a double pendulum, or the three body problem as the physicists call it, the stock markets have chaotic behaviors otherwise all of us will be making lot of money but nobody predicts how they are going to behave. But in the middle are the complex ones, those are the most interesting as far as I’m concerned, they are the cities, the immune system, the brain, software development teams, etc. So I believe, me and many others, Agile addresses software development as a complex problem recognizing that the software team is a complex system, not an ordered one, not a chaotic one we hope, but a complex one, and that is why the practices are always about complex adaptive systems.
Well I always like comparing it with gardening as one of the few metaphors that I use. A gardener takes care of a complex system: the garden, and puts a fence around it to define where the boundary is, makes nutrition available to make sure that what can grow, can grow healthily and rapidly, remove all the weeds anything that not does add value, that just takes energy away from the useful stuff that has to be removed, call it removing impediments in Scrum. Yes, sometimes you might have to make sure that some plants are positioned elsewhere from other plants because they don’t grow together well - these are the structural issues of an organization. And that’s it, that’s what a gardener does.
There are a lot of gardening tools if you want to have a beautiful garden, that is a lot of work going in to managing that complex system, but we have to recognize that it is a system that is alive, and the growing is done by itself, you don’t shout to the plants “Grow, grow, grow!” - That doesn’t help. Unfortunately this is often how managers perceive their responsibility for managing organizations, they simply shout to the developers: “Write more code, go faster!”, but that doesn’t work, they have to work within constraints, and the nutrition to make sure that growth happens.
Peter's full question: So something else you talk about in the book is this whole idea of innovation, and one of the challenges I think that organizations find is the balance between repeatability and innovation. A lot of organizations are trying to minimize variability or, as I sometimes put it, remove learning from the organization because the way to get no variability is to have no learning. How do you, in practice when you are developing software projects, balance between knowing when you are going to be done, but still having the space to innovate within a project lifecycle?
Good question, sometimes I get feedback from Scrum teams that tell me that they feel like they are the slaves of the product owner, they simply do sprints after sprints, feature after feature, what the product owner demands of them, and they feel there is a little innovation or experimentation going on. But what I’ve learned from Complexity Science, is that are basically three forms of innovation and survival of systems in complex environments, one is anticipation, is trying to predict the future. Actually human beings are quite good at that, because Daniel Dennett, the philosopher called the human brain an anticipation device and that is how we cheat nature basically. But human beings got addicted to it, we do far too much anticipation, so Agile has thought “We have to cut down a little bit, we have to do more adaptation responding to change, we anticipate the next sprint and then we respond to any changes.”
So those are the first two, anticipate and adapt, but what people often forget is that there is a third, which is experimentation, that is not anticipating because we have no idea of what is going to happen, is also not adapting because nobody is requiring you to build something. It is simply trying things for the sake of trying. Many Scrum teams have no capacity for experimentation; it’s not planned to experiment, while people like Donald Reinertsen for example, say that we learn most when we experiment, when we do not know what the outcome is, of something that we are going to do. So we have to make capacity available for experimentation - that is always my message to scrum teams: do some experimentation, do not just anticipate and adapt.
Peter's full question: It’s interesting because Don actually goes a little further and says that in information theory, you have the maximum learning when you fail half of the time, your experiments are unsuccessful in terms of getting the outcome that you expected. How do you sell that message in larger organizations that are perhaps a little uncomfortable with the idea of failing, because I teach classes for companies like JPMorgan, large banks and a good rule of thumb in a large company is the way you from VP to senior VP is by not failing?
I think the message that people sometimes have is we should celebrate failure but I believe that is wrong, I believe we should celebrate learning and as Reinertsen said, learning is maximized when you have fifty percent failure and fifty percent success. So it is not the failure that you should be celebrating because you will get more failure, if you start celebrating just failure, you have to celebrate the fact that you are learning, focus on the fact that you learned something regardless of the outcome - failure or success. Yes it is true that perhaps this scares some people away who do not like the failure, you can explain that the other reason for celebrating is to celebrate good behaviors.
Because if you emphasize people having good behaviors you are maximizing the chance that they will do that again and again, with a high chance of repeatable success. So the two reasons for celebrations are: one is learning and the other is having done good things, like following good practices, sometimes they might fail, but usually they succeed, so what I usually tell teams is ”Keep in mind that are two ways, two reasons to celebrate. One is learning fifty percent failure and fifty percent success. Two is, you did a good thing probably it led to success maybe failure, but hopefully not.”
Peter's full question: One of the challenges that I find is that often engineers are promoted into management and they become team leads and they gain management responsibility. And it was hard enough when the management role was old school, which is tell people what to do and collect the reports at the end of the week, but now I think the schools required by managers are much more sophisticated. You talk about the ideas of self-organizing teams, what would be some of the advice you would give for an engineer who is just moving into their first management role in terms of managing in a light enough way to allow for self-organization in the team that they are now running?
My first advice is to consider if that is really what you want because management is a specialization just like marketing, just like testing, just like any other kind of job in an organization. And just a year ago Seth Godin the famous marketing guru said: “Marketing is too important to leave to the marketing department everyone is involved in marketing”, and I believe the same applies to management. Management it’s too important to leave just to managers, we are all involved in managing the system, and that is the key insight from Complexity Science: the management of an immune system is distributed all over the system, the management of the brain is distributed all over the system.
I believe this is very, very interesting discipline like testing and marketing, but you have to understand if that is really what you want and then understand that you are managing the system and not the people, like the gardener is managing the system in which the plants and the other organisms grow. They are not managing the plants themselves, so if you have that right mindset, beautiful things will happen, I’m quite sure.
Peter's full question: Talking about making beautiful things happen, when you work with complex adaptive systems, often what you do is you focus on creating a shared sense of purpose, you create these guidelines that should direct the activities rather than micromanaging the specific tasks, so you talk about things like purpose and constraints. Are there any suggestions that you can provide in terms of how do you pick the most important purposes or the most important constrains to get a specific management outcome from a team or an organization?
Well my two main messages: I think with purpose and goal setting is one, it takes place both at the management level and at the team level. If managers have a purpose for a team, we call it an extrinsic goal, it is assigned to the team and for good reason because the team is there in the first place to satisfy some business goal. On the other hand there is also an emergent goal that teams can come up with. On the last team that I worked on more than a year ago, we had this goal of trying to be the best Agile team in the organization as an example to all the others.
That was a goal that we came up with ourselves, no manager had handed that goal to us, and is like with parents and children, the parents may have an idea for what the children have to become later, but the children have their own ideas of what they want to become later, and somehow we have to reconcile those purposes. Same in the organizations, managers and teams might have ideas of what teams are for, but they have to reconcile those ideas, the extrinsic ones and the emergent ones, make sure that they go hand in hand, and that may sometimes need a bit of counseling perhaps.
So that is one message, the other message brief is to use visualized goal setting, stop creating mission statements. I even see it in Agile communities that the product owners write mission statements or vision statements for teams or products for example and let’s not do that anymore. We should have more visual way, more metaphorical way of defining goals, there are plenty of examples of that available, they are much more compelling and people tell a great story on something that happened in the past with a certain customer and you give that as an example of what we want to happen on the next project, that feels much better for teams.
Peter's full question: Another thing that you talked about is once you have a system in place ongoing change, ongoing improvement, I think something that is interesting, is there a challenge these days where organizations are becoming more and more data driven. They are running A/B split tests, so they are running feature toggles with analytics, on a very regular basis. But there is something that you talk about and you call linear versus nonlinear improvement, and is this challenge of local optimas. When we’re working in a constrained amount of time and we’re A/B testing every text change and every color change, how can you still create space for the nonlinear improvements to get substantial improvements in the systems that you are building?
Well, that’s a great point that you have there, quite often you see that people attempt progress or improvement by small step change, continuous improvement is the main message you see behind Kanban, you see this is the main message behind The Lean Startup Movement with A/B testing as you refer to. And this is all good, this is fine, so you are trying to be better and better, but then indeed in a complex system you might end up at local optimum in a fitness landscape that has higher peaks elsewhere, and then you are stuck at this local optimum, because each individual single change will not help you anymore, you have to do a big change. Well that is why the Japanese talk about Kaizen and Kaikaku, small change and big change, continuous improvement and radical improvement.
So sometimes you have to do something rigorous, something that totally destroys your current process or totally reorganizes the way you do things right now and do something different and this is being addressed in the Lean Startup Movement because they call that a pivot. Then you do something completely different, you realize we are going in the wrong direction, with our small changes this is not leading us anywhere useful. Let’s take a significant number of steps back and go in another direction, see if that leads us to a higher peak, so the Lean Startup Movement has addressed this precisely that the small changes and the big radical things.
We persevere with A/B testing or we pivot into another direction. And you have to do that with Scrum, product development and any of the others as well, otherwise, as you said, you end up at a local peak and there is nothing to optimize anymore, if you just do small step continuous change.
Well that is ironical because this question is frequently asked and then I say that the first quote in my book is by Mencken who said:” For every complex problem there is a simple answer that is clear and wrong” and often managers are looking for those simple answers, but if you understand that you work with a complex system then there are no simple answers. It is complex, that is what we need to understand, but now I realize this is the simple answer to the question, so perhaps that satisfies the question after all: there are no simple shortcuts to managing human systems, it is more complex than that.