Adrian Jones

Adrian Jones: Good afternoon, everybody, and welcome to the DevOps Europe conference, which this year, of course, is a virtual conference. I am the virtual Adrian Jones, and I am joined by the virtual Justin Watts.

I hope over the next 20 minutes we will be able to provide some insights that will help you as you are looking to align software delivery with business value, and we are building on much of the experience that Justin has gained and is going through at the moment. Justin, thanks very much for joining us.

Justin Watts: Of course.

Adrian Jones: With this virtual format, part of me is wistfully harking back to the days of bad coffee and even worse croissants, avoiding eye contact for two or three days. But mostly I am actually in awe at the ingenuity, the creativity, and the adaptability of the speed with which these types of conferences now work. I really do hope that you will get some value from this, despite the fact that physically we are in different places.

Briefly, my name is Adrian, and I run the Tasktop team here in EMEA. I have been with Tasktop for about five or six years, and I have been in the industry for many more than that. I have been fortunate to be involved with some of the leading thinking as the Agile movement got into the mainstream, and likewise with many of the key founders and thought leaders in the DevOps movement. I am particularly pleased and honored to be a part of what is now the value stream management movement, where much of the thinking from people like Dr. Mik Kersten in his book Project to Product, and also with people like Justin leading the charge at organizations like Lloyds Banking Group, are hugely important in defining the direction for value stream thinking.

Justin, would you like to introduce yourself?

Justin Watts

Justin Watts: Thanks very much. I am Justin Watts, and I have not been around this type of stuff as long as Adrian.

Adrian Jones: Not many people have.

Justin Watts: No. I have been involved in similar activity, when we think about value stream management or value stream improvement, for a lot longer in different industries. I started looking at these types of problems in manufacturing probably 20 years ago now. I fortunately landed in a service environment in Lloyds 10 years ago, and eventually made my way into software delivery and ways of working and Agile and DevOps and Scrum and whatever else you want to throw in the mix.

I am in a very fortunate, privileged position to be leading a big portion of our transformation in Lloyds. I am responsible for the change methodologies and our focus on improving the value stream delivery, where, as you pointed out, the connection between our business and our software delivery, and actually making sure that it is as effective as it could be.

Adrian Jones and Justin Watts

Adrian Jones: When you moved from manufacturing to services, that must have been quite a move. Everybody was talking Agile and early days of DevOps. How did you square that particular circle with your background in systems thinking?

Justin Watts: It came quite naturally because of my background in manufacturing. When I was in manufacturing, I was dedicated in most of the roles to improving flow. Lots of people were talking about lean and lean manufacturing, but I was quite lucky in my role that we got over the step of thinking about lean manufacturing as a set of tools and went back to first principles: the relentless reduction of waste in a system and improvement in flow.

You mentioned Mik there as the value stream architect, if you like. But the original value stream architect in all of this was Taiichi Ohno. He was the guy who really started to look at the difference between mass production thinking and flow thinking and came up with the Toyota Production System.

My background in manufacturing and the focus on flow set me up really well for the job I am currently doing, but it did not set me up very well for the job I started in Lloyds, which was looking at frontline services. A lot of the mistakes in the service industry about applying lean manufacturing to service industry was something I was studying through Cardiff University and their lean program at the time, the Master's in Lean Enterprise.

I bumped into, physically, a guy called John Seddon, who was one of the teachers at the time, and obviously virtually in terms of his work. What I was learning from John was: whatever you do, do not implement the tools of lean in a service environment because they do not work.

Adrian Jones: Oh, really? Okay.

Justin Watts: They do not work. I learned a lot about his method, and things like failure demand as a massive concept. In service environments, traditional ones like call centers, they are the calls you should not even be getting because of the way the system responds to customers, the over-standardization of services, for example.

I went through a massive learning curve to unlearn the things I had learned around applying the lean tools to a service environment and thinking about it completely differently, predominantly from the customer's perspective, and how to design services that worked for the customer.

Counterintuitively, the thing I learned most from John was actually what lean was really about, even though he told me it was rubbish from a service perspective. The way he articulated what needed to be done from a service perspective, from those principles, was very much going back to the principles that Ohno was trying to achieve in manufacturing. So it was a full loop, and I was confused for a long time, but then I really understood Taiichi Ohno. I bet I never understood it from John's work in service environment, which was quite mind-blowing at the time.

When I had to go to what I am looking at now, the focus on flow, I had unlearned a lot and learned a lot. I thought I was in a much better position to understand Agile from a flow perspective than from a perspective of Kanban, Scrum tools, ceremonies, et cetera. We looked at quite a lot of work that had been done on the transformation up to that point and said we need to simplify our strategy right back down to the basics of flow. That is when we bumped into some of Mik's stuff as well by doing research on flow.

So full circle: from manufacturing, to unlearning why you could not apply those principles to frontline services, but actually then learning how to apply those principles really well to software. That is the journey I have been on.

Adrian Jones: Was there a particular moment where you suddenly realized that the things you thought would not work actually could be applied, with some changes? Was it over a period of time, or was there an epiphany moment?

Justin Watts: I think there was an epiphany moment when I looked at lots of the things that were being done under the guise of Agile which were making no difference at all.

Adrian Jones: Difference to?

Justin Watts: Lots of difference in terms of the ways people were organized, and everybody was putting grass down in the open areas in the offices, and Post-it sales were going through the roof. There was lots of difference going on there. Time to market? Nothing happening. No different. No reduction in waste.

The thing I learned the most was moving from activity thinking to flow thinking, understanding the economies of flow versus economies of scale, and how companies fixated on productivity actually increase their costs and make it worse. That is the stuff I learned from John.

When I looked at software systems, I could see all the same problems. In many Agile transformations, because we do not really pick away at the fundamental assumptions we have been carrying around about how the organization should work and how it should be measured, nothing was changing because we had not changed those assumptions.

When we were looking at our Agile delivery, we were still measuring things like lines of code, productivity per person, cost per story, et cetera, which were never going to shift the dial on the end-to-end system, identify systemic improvement, or show where we can actually improve the flow of the work from the time it starts to when it finishes.

When we talk about flow in Lloyds, we are talking in very similar terms as Taiichi Ohno described it: compressing the time it takes to go from order to delivery, and from idea to cash. That is the most important thing about all of this. That is where we started to turn our Agile strategy to fit simply two things: compression of time, which allows you to respond to feedback, and, in a nutshell, that is it.

But to get transformational improvements in time in a highly functionalized, specialized organization that has been put together with thinking that has been around for 200 years, it is very difficult unless you start to attack those assumptions. If you are doing Agile in a system where those assumptions are still the assumptions you carry around, you are only going to get a really small improvement because you are not changing the thinking in the organization. The organizational design is still the same. The measures are still the same.

Therefore, when lots of people are struggling with, "Well, my Agile transformation is not really working," it is because we have not changed the system.

Adrian Jones: When you say changing the system, are you thinking true end to end from concept to cash or idea to production, for any given product?

Justin Watts: Yeah. People focus on the Agile components up to dev complete and the DevOps parts, dev complete into production, pushing through pipelines and the rest of that stuff, but they have not thought about it all end to end.

There are two things. One: no one can see it. Nobody really cares. I do not mean they do not care, but because they cannot see it, it is not in their frame of reference. But if everybody is doing their thing really well from their own frame of reference, then you do not get true end-to-end performance improvement. In fact, you can make it worse.

Adrian Jones: Lean theory certainly says that.

Justin Watts: Absolutely. I remember watching a video of Russell Ackoff, and he called it out. It was one of my epiphany moments that if you do not think systemically, you can actually make the improvement of the whole worse. You see it quite a lot in organizations. A classic example is teams run in isolation that actually start to build a queue for somebody else. The queue increases, and as the queue increases, then we get all the behaviors that go with context switching, multitasking, and productivity going down.

That siloed nature of an organization built on specialization, on functionalization, if you are still trying to do Agile in that frame of reference, the improvement of the whole is going to be very limited.

The other point around systemically is not just thinking about this system, but thinking about the whole system of the organization. Above each one of those silos, you are going to get a management factory talking about the measures that hold that part of the system to account. If the measurement system is wrong, it is going to drive a lot of the behaviors which say it is fine to carry on in isolation doing your thing well because that is what you are measured on.

When I talk about the system, I am also talking about the things that sit on top of the system, like measurement and the way we budget annually. Those system conditions need to change to really support end-to-end flow.

Adrian Jones: I see this every day, local optimization within somebody's department, groups, scrum tribes, guilds, or whatever they have got. Fundamentally, you have silos, and you are optimizing at that level, generally governed by a whole set of proxy metrics that are not helping to inform how work is really flowing or where to start improving it. Do you see the same things?

Justin Watts: Yeah. We refer to them as proxy measures because they are proxy measures when it comes to real improvement in flow. You see this pattern over and over again. Lloyds is big enough to have seen it in past experience, to show that the measures you think about for your own performance are proxy measures when you think about what it really takes to go from concept to cash, idea to live, or full end to end.

Those measures in isolation are not an indication of how the whole system is working. The key thing is understanding how the system is working end to end. You need the right measures of flow and all the related things that allow you to improve your flow.

For us, some of the things that are really important in that system are the difference between leading and lagging measures. Even though time-to-market is a really important measure, it is still a lagging measure. A really good leading measure in an end-to-end system, where you are looking at states of progression, is age: time in that part of the system. As soon as you start to indicate that this thing is now stagnating, it tends to make you look at why it has stopped or why it is stuck in the system, not concentrate on a proxy measure which says, "I am fine because I have hit my story-points target," for example.

Proxy measures like points do not win prizes. Proxy measures do not win prizes.

Adrian Jones: I have got to make a note of that one. Piggybacking off that, Jeff Bezos made the point that if you are not focused on the customer but you are focused on a proxy for the customer, either customer surveys or internal metrics, after a while the process becomes the thing. It is not only that it is not informing you on how you can improve, which is presumably one of the key rationales behind using any metrics, but it is also distancing you from the customer because you are focused on the wrong thing. It is a dangerous thing.

That is a key anti-pattern I see as well. What other anti-patterns have you seen over the time as you have been pushing forward with systems thinking and introducing it into the service industry?

Justin Watts: There are a couple of things. Let us hold onto the value point; we might talk about that separately. I may upset a lot of people with these comments. Think back to what we talked about, the very functional, specialized nature in an organization.

One anti-pattern is, believe it or not, implementing Scrum in that organizational design. What I mean is: say you have some highly productive Scrum teams that represent a part of the system. There is nothing wrong with Scrum when you have designed the organization to support it properly. If you go all the way back to the original article, The New New Product Development Game, the way they described Scrum in that article was that the team had total autonomy to move product development through its total cycle to the end.

What people have done with the translation of Scrum is: I will take the ceremonies, and I will take all the activities, and I will do them well, but I will do them in a team that does not have the autonomy to deliver the thing end to end. What you tend to see is lots of teams working in isolation from each other, basically stacking up work for somebody else to do, or, in the worst case scenario, making bits of things and putting them in the queue, and somebody else has to work out all the bits to go together.

From my point of view, Scrum is an anti-pattern to flow if you are doing it in an organization which is still set up as a functional specialized design.

Adrian Jones: I was a little worried there. You are challenging the most widely practiced Agile approach in the world. But actually what you say makes total sense. The emphasis on ceremonies, "we are doing it, therefore we are it," is flawed. Thank God you have not said anything negative about DevOps.

Justin Watts: That is my next point. The next anti-pattern I see is that generally, because we forget about the system and the total time it takes and the total journey that work has to go through, we become very focused on the technology, which in some occasions is a bottleneck at the end of the system. DevOps is necessary in those conditions, but it is not sufficient.

Take flow efficiency as a measure. If you look at 100% flow efficiency, which would never be achieved because there will always be some waiting time in a system, and then look at the majority of the negative time lost in an end-to-end system, most of it is to do with organizational design, and most of it is to do with waiting for somebody else.

In that context, from a DevOps perspective, the amount of time in that equation of 100% that DevOps has an effect on is only very small. It is necessary, but it is not sufficient, because the amount of waste in a system can normally only be taken out by changing the organizational design, putting WIP limits in, et cetera. It is not that DevOps is a bad thing, but we become over-reliant on DevOps as a thing that is focused on a very small part of the total waste.

Adrian Jones: If you are bottlenecked on your pipelines or path to production, or you need to release more frequently than you are able to, then of course DevOps is a fantastic way to automate all this and improve. But if the issue is somewhere else?

Justin Watts: Yeah. If it is not your bottleneck, then what is the point? The technology might not be the bottleneck. It might be governance. It might be authority to proceed. It may be that you are working in a very risk-averse organization, which means everybody has to have a say on whether the thing can go live or not anyway.

There is a lot of systemic waste, and this is what I mean by not only end to end but the system around it. You could have the best DevOps pipeline in the world, but you could have procedures that do not allow it to flourish. You may have procedures in your organization that say, "We know that we can do automated everything, but actually we need a manual check."

Adrian Jones: That is where some of the flow metrics become really important: the flow metrics based on the key units of features and defects and debt and risk, which business and software engineers can collaborate on. What is the right mix? Where are we blocked? Are we delivering with the right priorities?

I think we probably got away with that one on a DevOps conference.

Justin Watts: It is necessary.

Adrian Jones: Necessary, but not sufficient. Anything else that strikes you?

Justin Watts: One last anti-pattern is doing the wrong thing righter. They are not my words; I borrowed them from Ackoff and Peter Drucker before him, I think. This is where I really learned a lot from John Seddon around service environments and the over-reliance on IT first, not last.

I will bring that to life. Go back to the front end of the service. We talked at the beginning about business value and software delivery. They should be integral. They should be one and the same thing. Why would you build anything that is not really solving a problem for the customer?

This is an industry-wide problem. You still see in some of the Agile reports lots of effort and code being produced that never really make a dent in the marketplace. They never really get used by customers, never really deliver revenue generation at the scale required to make a case for the return on investment.

The anti-pattern is technology first, not last. Think about a big service environment, a call center, where I spent a lot of time, and the concept of failure demand. That is demand by a customer saying, "I cannot understand my statement," or, "You have not come back to me," or so on. They never turn into complaints, but they take up capacity to deal with, and they are a source of dissatisfaction.

Our technology-first view of the world might say, "What about this voice-to-speech technology? What about AI? How can we start to use these technologies to service our customers?" You might have lots of activity in a software delivery system looking at using technology to serve customers when you should not even have the demand at all. You should understand why customers do not understand the thing they are talking about and switch it off at source. The improvement effort would never be software in that case first. It would be last.

In that example, what we should say is, "Let us think about how maybe technology could serve the customer when it is value demand, when it is the things they really want from us." Why would you put any effort into building an IT solution for something that should never exist in the first place? A lot of that goes on. Avoiding some of this stuff is as important as doing some of the stuff.

That is where we get ourselves in quite a pickle with software delivery. On lots of occasions, we are building things without context of the problem it is trying to solve from the customer perspective, and/or even whether the problem should exist before we start building anything. That is where I have a problem with the sprint goal from Scrum. The sprint goal could be doing the wrong thing righter. It could all be wasted effort.

Adrian Jones: You focus very much on the outcome we want to achieve as a business. Taking it back to business goals, your helpdesk analogy will hit home to anybody that has used helpdesk facilities.

Justin Watts: From a DevOps world, if we could ask a question to the audience, it would be: how many brilliant engineers actually get any idea of the context of the problem they are trying to solve from the customer's perspective in a service environment?

One of the things we have really tried to do in Lloyds, and it is not always easy and not always achievable, is connect our engineering capability with the actual customer need. Generally, the engineers are the last people to work on a thing before it has gone through all its design stages. You have people doing design work at one end, disconnected from the people doing the actual coding, and you see that pattern quite a lot in an organization.

Go back to the original principles that Scrum was built on. The whole team moves the product through the system together. Because we think about an organization in terms of specialization and functionalization, there is always a separation between when the code is built and the problem from a customer's perspective.

Adrian Jones: So much of what you have talked about has been cutting away that basic approach and focusing on the customer, focusing end to end, focusing on systems, and driving efficiency and effectiveness through that rather than localized, siloed approaches.

One last question. We have not talked about happiness and we are out of time, but I want to pick your brain. Your team has to be one of the most positive teams to work with. We have been working together for a number of months. What is the secret? They feel empowered. They are positive. They are looking all the time for solutions. Have you just got lucky with the team?

Justin Watts: I would like to say there is a bit of academic reasoning for it. I have been highly influenced for the last 10 years, maybe more, by Deming's work and his view that the outcomes we see in an organization are due to the system, and people are always there to do a good job.

I am very fortunate that the people in the team have also been influenced by that kind of thinking. We generally ignore hierarchy. We generally ignore chains of command in a traditional sense. We are all professionals. We know what we are trying to do. We have a clear purpose, and we just treat each other with respect.

I know a lot of Agile work is built around people over process. My mind is very split on that because of what I talked about earlier in organizations and them being designed like they are normally designed. Unless you change the system, things like measurement, you can do all the work you want on psychological safety and culture, but they do not work unless you change the system.

You may get a very short-term effect, but eventually in rule-based systems, the behavior will go back to where it was before because of the way the system generates behavior. In my team, I am lucky that we understand that, and we tend to ignore the system conditions that drive behavior and write them off because we know their effect on us. I think we are quite lucky to understand their effect, and we try to ignore it.

Adrian Jones: It is definitely working, and it is noticeable. Justin, thank you. There has been so much stuff in here. I hope that everybody tuning into this will have got some value and some pointers, some things to take away, and certainly your points about activity thinking, moving towards flow thinking, getting away from the cost fixation, challenging assumptions within organizations, making sure that work is visible so that you can see end to end, concentrating on leading rather than lagging indicators.

Beware of overuse of Scrum was another one. Use DevOps, but recognize it is necessary but not sufficient, and do not fall into the trap of doing the wrong things righter or quicker. Fantastic. Justin, thank you very much.

Justin Watts: My pleasure.

Adrian Jones: I wish everybody a good conference, and goodbye from us.