Jabe Bloom on Systems Thinking at Lean UX 14

1. Hi, everybody. My name is Todd Charon, an Agile editor here at InfoQ and we are at the Lean UX Conference and today I am joined by Jabe Bloom. Hi, Jabe.

Hey. Nice to see you guys.

Todd: To get started, just tell us a little bit about yourself.

Sure. So my name is Jabe Bloom and I am an independent consultant. I have my own company, which I currently call Coherent Insight. I am also a visiting scientist at a company called PraxisFlow with Kevin Behr who co-authored the Phoenix project. And finally, just to round out my not busy schedule, I am starting a PhD in design at CMU in the fall, so I have a full plate of stuff to do.

2. That is a lot. So, with all that on the go, what makes you want to be at the Lean UX conference giving Lean sessions?

Yes. So about three years ago, right after the first version of this conference, which was called the Agile UX Conference, I was working at a company – TLC Labs – and we hired Will to come in and help us think about design issues.

Todd: Will is the organizer of the conference.

Will is the organizer of the conference. Will and I got really thick into design thinking. I professionally grew up in New York and in a lot of the boutique firms down here. My job really was always to be the guy between the creative department and the technology department. So, I am actually a CTO at my primary role, but I did the CTO role more like a product developer. I was helping people initiate new things. At some point I kind of got sick of being the guy who had to come up with all the ideas and started trying to convince other people that there was a process that we could have to help co-develop or co-create these ideas and share the responsibility.

So, Will and I have worked on that extensively for the last couple of years. Last year, we threw this conference - Lean UX and we had a great time and so we did it again this year. This year I am an independent consultant that is supposed to work at the same company Will is at, but he invited me back and I worked with him at shaping the program a little bit. So, it has been great a couple days, a ton of fun, I feel a little spoiled getting to have Alicia Juarrero was here, who is a personal intellectual hero of mine, so it was amazing to have her contribute her ideas to the conference and some other people. So, it has been great.

3. One of the things you were talking about in your first talk, you were talking a lot about systems thinking. Tell us a little bit about system thinking but also, more importantly, how does that tie into Lean UX and why is that important for Lean UX?

I talked a lot yesterday about Ackoff’s ideas about system thinking and really for me, one of the reasons I wanted to bring Ackoff into the conference because he is, for me, the tie between traditional systems thinking and complexity thinking. The complexity obviously has a lot to do with systems thinking in that we have parts and interactions of parts causing emergent behavior. So that is all based on the concept of a system in itself. So, I wanted to bring Ackoff in to start having a conversation about complexity theory within the realm of systems theory. The reason why I think it is so critical for us right now to really start reengaging with systems thinking is that we were getting more and more people to understand that the mechanistic metaphors of how human systems work, does not work very well. So treating businesses like machines, like clocks, is really problematic and most people are starting to understand that, but they are not moving far enough forward in their thinking.

They just start really understanding the implications of what it means to be in a social system. So we go into a lot of businesses right now. I tend to think of it like three sections of a business that we see when we look at most software developer shops: we have Lean UX, we have Agile and we have DevOps. So, most companies that I go into right now, who I am working with – they have an Agile implementation which has highly optimized the development of software and they actually tend to be pretty effective at it. We spent about 20 years trying to figure out how to be good at developing software and I think that in fact we are probably pretty good at it right now.

The problem is that either side - Lean UX side meaning the design side and the operations side – the DevOps side – these people haven’t spent the same time and energy to really examine the way their way of working. If we take a systems thinking metaphor, so we take Ackoff’s really basic idea that if you optimize a part of this system, it may or may not optimize the whole system and we apply that concept very simply to what we see in most of these organizations – the Agile implementations are breaking the holistic system. They are not making this company better, they are probably sub-optimize the companies. So, a lot of people hear about this sub-optimization that I am talking about and they think I'm saying Agile is bad or that people are intentionally breaking things and doing bad things.

I am not saying that at all. In fact, I think that the ideas of Agile could be brought out further and taken on a systemic level. So, I think when we look at the manifesto, it is clearly a manifesto about software engineering. It is not about design and it is not about operations. So, we need to re-examine both of those sides. I am trying to convince people to re-examine their companies at systemic level, to understand where the work is coming from and where it is going to and to not simply try to optimize the system to work best for their local perspective. I think there are different techniques and ideas we have used for that, but I said earlier in one of my workshops – Lean UX to me is the DevOps of the front end and DevOps is the Lean UX of the back end. You keep seeing it in the balanced team people as well, right? It is this idea that we really need to start having a better understanding, a better empathy, a wider empathy to the people who work upstream from us and the people who work downstream from us and how their work is affected by the way we do our work.

I think that we can start doing that, we can produce much better work, much more effective work and we could start having companies reconsider the concept of speed and efficiency, being the most important thing. I don’t think any of the words in the Agile Manifesto actually mean anything about speed. They do not need speed. Speed could be a result, but it is not the starting point. It is no bleak end point. So, I think we could get people to reconsider the entire company, as a system. Potentially, if you look at, for instance, Lean Startup, that maybe the system actually extends into your customer base. The system is your company, your product and your customers interacting together at a systemic level. If you start looking at that, then I think we can produce some real value that we can’t capture right now in most businesses.

4. [...] I mean there is obviously a lot of written material on the subject, but for someone who is really new to this, who is hearing it for the first time from you here today, where would they find a good starting point?

Todd's full question: So, one of the things you mentioned was getting these groups into the idea of things like systems thinking. Where would they get started? I mean there is obviously a lot of written material on the subject, but for someone who is really new to this, who is hearing it for the first time from you here today, where would they find a good starting point?

One of the reasons why I bring in Ackoff is because I like – I love Ackoff. Ackoff has a gamut of different ways of expressing these ideas. He goes from some of his first books which are “On purposeful systems” - which is a 300 page philosophy paper with equations for what purposefulness is in a systems thinking manner - to really light-weight white papers that help people to start thinking about this. My favorite thing to do with people is just to get them to look up on You Tube and watch – there are like three Ackoff lectures that are available on You Tube, all three of which will show you that he is this jovial, puckish guy who likes to play with these ideas and really engage audiences in understanding that there is some humor in it. That is part of the reason I think he is very approachable. So, his F-law books are really quite good, which are a series of brief statements about the problems of management and some elucidation on how to think about those things – so that might be an excellent place for somebody. Again, the Ackoff lectures – there are two or three, about an hour long, an hour of your time to start getting an idea about his concept of systems thinking.

If you are here at the conference, Johanna Kollmann is having an excellent workshop tomorrow about systems thinking and she has some excellent ideas from Chessman and a couple of other systems thinkers. It is more difficult to think about things at a systemic level. It is not as easy. It requires us to really step back and reconsider a lot of things. You heard it from Alicia yesterday and from Dave Snowden to some extent. One of the things that we are asking people to be comfortable with is ambiguity and messiness. This idea that you can have predictability and guarantees has to some extent be accepted that it is not really part of what we do. You can make it look like that, but you will be frequently surprised by the results, in very negative ways. Instead, if we retake these ideas as ways of increasing our probabilities of success, increasing the likelihood that something might happen as opposed to guaranteeing a result and really re-examining how we think about work in that light, that ends up starting to get us from mechanistic starting systems to looking for its complexity. I think that is quite exciting and we are getting there.

5. [...] Should you start with systems and then move to complexity, or dive right in to complexity or how do you really get your head around these concepts?

Todd's full question: So that was another thing I was going to ask you about as well. You mentioned complexity as well. For somebody just getting started Should you start with systems and then move to complexity, or dive right in to complexity or how do you really get your head around these concepts?

I think in a lot of the Agile community the obvious place to start would be with David Snowden’s – it is called the “The Children Story”. It is on You Tube and it is a very fun elucidation of these basic ideas in a narrative form which kind of fits your ideas. So, I would start there for sure and the Cynefin model in general is useful to begin the thing with. But I think that you can’t really get the whole of the idea without having some concept of what we mean by systems thinking. I am not sure Dave would always agree with me on that, but I think that to start from understanding that really a system is an interaction of parts that causes some greater properties.

If the parts were missing, those properties would also be missing. So, the sum of the system is greater than the whole. So, that is the easiest way to put it. Then a slightly more complex one, would be if you measured the system and you measured the parts individually, that some of the measurements of the parts would be greater than the measurement of the system and then finally, Alicia Juarrero would say a system is where the parts are greater than the whole, but not other than the whole. So there is an interaction where you would get emergent behavior which we see in a lot of Agile literature. So we get this upwards emergence from small systems, small ideas up. But also, when you emerge, it stabilizes and causes a downward causality as well. So, the system stabilizes the parts and the parts create the system. You can think about this interaction like if you are at high school, if the was a clique, it formed somehow and then once it is formed, it emerged from the social group.

Then there were rules that the clique made up that said who was in the clique and that is what stabilized the clique. It is a very simple way of thinking the system. It is an emergent social group that creates rules by its emergence, then it enforces that the social group is stable. So, if you start from systems so that you understand the parts and you can start thinking about the inter-relationships of parts and the inter-relationships creating the system, then you can start looking at complexity because complexity just ends up being how temporality and dynamics modulate the parts and make them stabilize into coherent patterns, which are a lot of fancy words for saying companies form out of people doing things together and they stabilize when they do things together well and what we want to do with systems thinking and we want to do with complexity thinking is to say: “If you allow to stabilize to such an extent, then it starts being immune to its local environment, things go bad”.

So how can we re-open the system so that it re-stabilizes constantly to an ever-changing environment? So you can think about that at team levels, like if you create stable teams that do not interact well with the teams upstream and downstream from them and they create policy walls between your development team and your ops team, this is the classic one, right? You have a development team and an ops team. The ops team is supposed to keep the server stable and the dev team is supposed to put new stuff on the servers that is likely to make the servers non-stable. The ops team makes more and more rules to keep less and less stuff of the devs getting on the boxes and this becomes a policy war until you get so much policy to get anything into production, that it does not matter how Agile you development team is at all. So, how do we step back from that? How do we look at a systemic level and re-stabilize the system so we can actually serve the customer?

Todd: You kind of touched on it a bit there, but I'm going to put you on the spot with a hypothetical to play with. Let’s say that in a hypothetical organization that is maybe a traditional, waterfall development shop. Suddenly they go Agile, development shop, gets trained, gets a coach, gets in the field, they start doing it and you mentioned earlier in your talk that it may actually negatively impact the system as a whole. So, give me a systemic view of what you think, in this hypothetical example, might happen or what might they see that reflects something in the system.

Do you want me to give you a hypothetical for how it sub-optimizes or how they could implement Agile without sub-optimizing?

Todd: That might be a good one too. Let us start with – I just want to see the impact on that. What would the impact of that be on a system? Something you might have seen, or heard about, or seen a few times because there is probably a lot of commonality across those things

The most common thing we see when we look at any organization that has separate teams with any form of silo between them. In general, the way I would define the silo is when you have a manager on one team and other people and a manager on another team and those managers report up somewhere else. So, in order to get information from one team to the other, if it goes bad, this manager is going to go to his boss and they go over. So there is a silo, there is a wall here. Anytime I see that, the sub-optimization is that that when you look at the flow of knowledge work, when you look at how knowledge flows through a system, the touch time, the amount of time people spend working and the flow time, the time it takes to start the work and get it done, all the way through the system, 95% of it is wait time. Time when work is in queues. 5% of the time is in touch time, so people actually doing the work. What we see when we look at these systems, the first sub-optimization you see is that this system outputs into an invisible queue. Nobody notices it is there.

Then this system consumes the invisible queue. So, the first thing you do when you come in with an Agile implementation is you say: “Make these people faster” – the dev people - which just means that they fill this infinite queue faster. So, very simple queue theory that says: “Queues work like this - fine fine fine fine – exponential collapse of infinite of the queue state”. In other words: these guys can consume a certain amount of information at a queue and when that queue goes over tipping point, these people collapse. They can’t consume it fast enough, so you do an Agile implementation and you don’t see these queues and you don’t interact with the ops people, people downstream from you. You actually significantly increase the chance that you destabilize your system by flooding infinite queues with too much work to be consumed by the downstream system.

That is what we see when we look around a lot of the organizations. So the non-theoretical, like the narrative version of that is the CIO knows that the ops people are furious because things keep breaking and ops people just absolutely want the Agile development people to stop developing software: “You are going too fast. Stop!” And of course the CIO is conflicted now because he goes to the Agile people and they say “This is great! We are developing software so much better. We are so much faster. We really increased our cycle time” And so they are confused. The CIOs are deeply confused by this because they say: “I got what I expected to get out of Agile. They told me I would increase my cycle times, I would develop more software, I would crush the amount of time it takes to deliver software to the market. I took my two-year cycle and I made into six weeks and then I made it into two weeks in six months. Awsome! And then my support people and my ops people were in my office every day, telling me to stop it.

They said “”You have to stop. You are crushing us.” So the only way to actually make it work was to actually take developers out of the development cycles that were doing products development and give them to the IT departments and our support departments so that they could explain how we were developing software and develop the appropriate downstream processes and systems to allow those invisible queues not to get out of control. Then, what we actually did was to visualize the entire value stream so that we could see those invisible queues and put WiP limits on the invisible queues so that these people can’t over-produce. And when they stop over-producing here, we create slack in the Agile teams so they can’t develop new product features, but what they can do is to increase code-coverage, do personal development, read books, do refactorings that they'd like to do and the result of this was a really significant increase in code quality when we could actually explain to managers that there is a queue here that we can’t fill up too much so that developers should not be developing features, they should be developing capabilities. And when you refocus teams on capability development and code quality improvement. This improved the quality so that when we actually did releases we had less defects in the field and we increased the flow of the entire system significantly and then your support people and your ops people are perfectly happy.

This is, to some extent, the classic continuous development story, the continuous deployment story, it seems to work very well when you actually figure it out. But what it means is extending the view of the Agile team downstream and upstream and that is why I think we get in to ideas like Lean UX and DevOps, so that we are talking about how to allow teams to see across these artificial boundaries that were put there to make teams more efficient, as opposed to the company more effective.

6. [...] Is there an approach where you could introduce these things and not create the problems I have to solve later?

Todd's full question: We talked a little bit about the other example. In that example we we saw the problems arise which was a good thing because they were resolved and things went well. So, I suppose that is one approach. Is there an approach where you could introduce these things and not create the problems I have to solve later?

Yes. My first theory is that often, when we talk about cross-functional teams and the first problem we see when we talk about cross-functional teams is “What do you mean by cross-functional?” In moderately sophisticated shops we see that they say “That means that the developers and QA work together”. That is cross-functional. They have broke down that one silo that used to be Dev and QA And they say “Oh, we found some magic thing!”. And they have found some magic thing which is to break down the silos and allow people to work together and figure out how to work better together. But I think cross-functional teams that you are introducing with your Agile implementation, cross-functional teams means that the developers understand how the software is operated and develop the software to be operated.

That means that instead of thinking of Ops as the people who do stuff with the thing I make or “we make this stuff and they deploy it”, it is “we need to understand how to make this deployable”. So Ops, instead of becoming a destination, becomes a service or a client so that they can make demands on the developers and they can inform the developers “Listen, this is how we operate the system. These are the logging levels that we need, these are the service levels that we need. You need to understand the impact of performance and cycle time on how things work” So now, instead of just looking at features coming down this way, we are looking at capabilities coming up and we are balancing the development of new features and the development of capabilities so that we are constantly keeping these things in balance.

I think that looks roughly like people understanding again: I have a Lean UX team that is tying my designers and my developers together in a relatively effective way and these guys are looking at what we call the fuzzy front end in Lean, the very abstract exploratory, experimental side of the work and trying to grab hold of something that will provide value by doing experiments and by poking and prodding customers in trying to figure these things out, moving it through an Agile production cycle where instead of creativity we talk about craftsmanship maybe, like creating beautiful code, creating clean code, but we do not need all this clean beautiful code for just doing experiments, right? Then finally taking clean code and beautiful code which, to me, means code optimized for maintenance and optimized for refactoring or reliability at the development team level so I want to make sure my code is clean so my fellow developers can have good code and then extending it just one more time to say “What would it mean if the developers also were taking into consideration in manufacturing this would be design for manufacture” So this would be – how do we make software designed to be operated as opposed to just throw it over a wall and they can figure out how to operate what we designed? How would we start the process?

Looking at DevOps as not just a new team that figures out how developer and ops people work together, but a way that developers and ops people then start creating code that is designed to be operated, that inherently is designed to be operated. The customer view, the operations view and we get the developer’s view. You have three different looks at the exact same code base and they are just performing for different people: one is performing for a customer, one is performing for the developer and one is performing for operations. If we can balance those three, I think you will get an amazing experience for everybody involved and that is a systemic view. All of the different views on those are just different social technical systems looking at the same code base. And if you can get that to happen, then we can start having this amazing process that we do which is we take a bunch of text.

I often describe it as - imagine trying to get 30 authors to write a book where nobody who knows who any of the characters are, there is no plot line yet and they all have to make it coherent all the way through. The experience has to be coherent and then say “Oh, and if you are a developer, you read it this way. If you are a customer, you read it this way and if you are an operating person, you read it this way.” So, it is like a multifactor problem that is a narrative problem about telling stories and happy experiences. How do you balance those three? And if we can figure how to get that stuff to balance out, I think we will get to a really interesting place.

7. So if somebody wanted to learn more about the things you are up to today, where might they get that information?

The easiest place to find me is jabe.co. That will take you to my blog. You can find my information on the left hand side. I tweet a lot. I speak probably more than it is good for me. Next I will be at Lean Kanban North America in San Francisco then I will be in Sweden and Italy for Stop Starting Stop Start Finishing and Lean Kanban Southern Europe. I will be in Paris. I will be at the Cloud Expo in New York talking. So, you can find all my speaking engagements at the bottom of my blog.

Todd: Great. Thank you very much.

Cool. Thank you.