00:00:13

Good afternoon, everybody. And welcome to the DevOps Europe conference, which this year, of course, virtual conference. So I'm the virtual Adrian Jones, and I'm 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're looking to align, uh, software delivery with business value and the building on much of the experience that Justin has gained and is going through at the moment. So Justin, thanks very much for joining us, and I hope that with this format, with the, with the virtual format, you know, part of me is kind of wistfully harking back to the days of bad coffee and even worse costs on avoiding eye contact for two or three days. But, but mostly I'm actually in all at the ingenuity, the creativity and the adaptability of that, the speed with which these types of conferences now work.

00:01:09

And I really do hope that you get some value from, um, from this, despite the fact that physically we're in we're in different places. So, um, just briefly my name's Adrian and I run the Tasktop team here in EMEA. I've been with Tasktop for about five or six years. Um, and, uh, I've been in the industry for many more than that. Uh, I've been fortunate to be involved with some of the leading thinking as agile, the agile movement got into the mainstream and likewise also with many of the key founders and, uh, thought leaders in the devil's movement. So I'm particularly pleased and feel, feel 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, his book, project to product. Um, I have to pluck him by the way, cause he's my boss, but also with people like don't know, like, like, uh, like Dustin, just, um, leading the challenge at, uh, organizations like Lloyd's banking group are hugely important in defining the direction for this, uh, for, for value stream thinking. So, uh, Justin, would you like to introduce yourself?

00:02:18

Yeah, thanks very much. Um, so I'm just in Watts and, uh, I haven't been around this type of stuff as long as Adrian. Um, no, um, I have been involved in similar activity when we think about value stream management, if you like, or value stream improvement for a lot longer, uh, in different industries. Or I started looking at these types of problems in manufacturing, probably 20 years of bono actually, which is quite surprising. Um, and, uh, I fortunately actually landed in, um, service environment, uh, in lights 10 years ago and eventually made my way into, um, software delivery and where he's a work in an agile and dev ops and scrum and whatever else you want to throw in the mix release. So, uh, but I'm in a nice, I would say very fortunate, um, privileged position actually to be quite, uh, you know, lead in wherever you want to call it a big portion of our transformation in lights. And I'm, I'm responsible for that to change methodologies and our focus on, um, improving the value stream delivery, where as you pointed out the connection between our business and our software delivery and actually making sure that you make it it's as effective as it could be.

00:03:46

Right. Yeah. That's, that's interesting. So when you move from, from manufacturing to services, that must've been quite a, quite a move and, and, and I guess if everybody was talking agile and early days of dev ops in there in that, how did you square that particular circle with your background in, in system thinking?

00:04:06

Right. It was, um, it was, it came quite naturally because of my background in manufacturing, because when I was, when I was in manufacturing, I was dedicated in most of the roles to improve him flow. Um, lots of, lots of people were talking about lean and lean manufacturing, but that was quite lucky in my role at, we kind of got over the, uh, the, the, the stack of thinking about lean manufacturing as a set of tools to actually bring back to first principles in terms of the, you know, the relentless reduction, if you like of waste in a system and improvement in flow. And you, you mentioned there is, um, you know, the, the, the, the value stream architect for life, but the original value stream architect and all of this was tied. You're not right. I mean, that's the guy you, uh, will really start to look at the difference between mass production thinking and flow thinking.

00:05:02

And you came up with the total production system. So I think my background in manufacturing and the focus on flow set me up really well for the job I'm currently doing it, but it didn't set me up very well for the job I started in August, which is looking at frontline services. And, um, a lot of the mistakes in the service industry about a lean manufacturing, the service industry was something I was studying through Cardiff university and a major, um, lean program at the time, the masters in lean enterprise. And I bumped into physically, uh, a guy called John Seddon was one of the teachers at the time. And obviously it's virtually in, in terms of his work. And what I was learning from John was whatever you do do not implement the tools and lean in a service environment because they don't work and you do not work.

00:05:53

They do not work. And I learned a lot about his method really, and the types of things, failure demand is a massive concept that, you know, most of our demanded service environments, traditional ones like call center as a cause you couldn't, you shouldn't even be getting in any way because of the way the system responds to customers. You have a standardization of services, for example. So I went through massive learning curve, too. I learned the things I learned around applying lean to also service environment and thinking about it completely different predominantly from a customer's perspective, I know design services that worked for the customer. So while you went through a real process of learning a lot of things from John and Noah currently, the thing that I CA counter-intuitive thing I learned most from John was actually walling was really about, even though he told me it was rubbish from a service perspective,

00:06:48

The way that he then articulated what needed to be done from a service perspective from those principles was very much going back to the principles that owner was trying to achieve in manufacturing. So it was a full loop and I was like confused for a long time, but then I really understood, understood it from John's work in service environment, which was like, you know, quite mindblowing in terms of what I was learning at the time. So then when I have to go to, to the way, what I'm looking at now, the focus on flow, I kind of learned a lot learned a lot. And I was, I thought I was in a, in a, in, um, in a much better position to understand agile from a flow perspective than from a perspective of combined scrum tools, um, ceremonies, et cetera, et cetera. You know, we just 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, of flow. And that's when we bumped into, um, you know, some of mixed stuff as well, by doing some research on flow. So full circle from manufacturing to one learning why you couldn't apply those principles to frontline services, but actually then learning how to apply those principles really well to software. So that's the journey I've been on it for like ha

00:08:21

Okay. Okay. Interesting. Was there a particular moment where you suddenly realized that the things that you thought would not work actually could be applied and with some changes, or how did that happen? Was it over a period of time? Was there an epiphany moment?

00:08:38

Uh, I think there was an epiphany moment when I looked at, um, lots of the things that were being done under the guise of agile, which were making no difference at all. And

00:08:51

You can difference to lots of difference in terms of the ways that people were organized. And, uh, everybody was putting grass down in the open areas in the, in, in the offices. And, uh, the post-its sales were going through the roof. There was lots of difference going on there,

00:09:06

Time to market that thing up, man. So different, no reduction in waste. Um, and the thing that I learned the most was moving from activity, thinking to flow, thinking, understanding the economies of flow versus economies of scale. And now companies are fixated on productivity, actually increase their costs and make it worse. That's the stuff I learned from John. When I looked software systems, I could see all the same problems, so many agile transformations, because we don't really pick away at the fundamental assumptions. We've been kind around about how the organization should work and how it should be measured. Nothing was checked in because we hadn't changed those assumptions. So when we were looking at our agile delivery, we were still measuring things like, you know, lightens P like the code, you know, product per person, cost per story, et cetera, et cetera, which never going to shift the dial on the end to end system identifying, you know, systemic improvement or, or where we can actually improve the flow of the work from the time it starts, when it finishes.

00:10:18

So again, like when we talk about flow in loads, we're talking very, very in, in very similar terms as Teo, it described it in terms of compressing the time it takes the war from order to delivery, uh, and from idea to the cash, if you like. So that's the most important thing about all of this. And that's 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's it, but to get transformational improvements in tying in a highly functionalized, specialized organization has been put together. We're thinking it's been around for 200 years. It's very difficult to do unless you actually start the attack, those assumptions. If you do an odd job in a system with also some assumptions are still the assumptions you carry around. You're only going to get a really small improvement because you're not changing the thinking in the organization. The organizational design is still the same. The measures are still the same, the way therefore, when lots of people are struggling with my agile transformation, don't really work. And it's because we haven't changed the system.

00:11:33

Yes. And when you say changing the system, you're thinking really true end to end from, from concept to cash or idea to production or whatever, whatever it is, but for any particular, any given product, okay. Because people focus on the agile components of debt that the up dev complete and the dev ops parts, they have complete into production and pushing that through your pipelines and the rest of that stuff. But you've not got, you've not thought about it at all. End to end.

00:12:05

No one can see it.

00:12:06

Yeah. Okay.

00:12:08

No one can see it. Nobody really cares. And I don't mean it from a point of view, they don't care, but because the concert is not in their frame of reference, but everybody's doing their thing really well from their old frame of reference, then you don't get through end to end performance improvement in fact, make it worse. So

00:12:31

Lean theory certainly says that. Yeah, for sure. Okay.

00:12:34

Yeah. I mean, I remember watching a video of racks laid off and he kinda like called it out. And it was one of my epiphany moments that, you know, if you don't think systemically, you can actually make the improvement of the whole worse. And you'll see it generally quite a lot in organizations where, and a classic example that we see quite a lot is teams running isolation that actually start to build a queue for somebody else, the queue increases. And as the queue increases, and we get all of the kind of, uh, behaviors that go with context switching and multitasking and productivity going down. So that, that siloed nature of an organization built on specialization of privatization. If you still try to watch out enough, enough frame of reference, if you're citing the improvement of the whole is going to be very, um, limited. But the other point around systemically is not just thinking about this system, but it's thinking about the whole system of the organization.

00:13:36

Because if everything think about what we just said there, um, the systemic nature of it in chopped up by specialization above that each one of each one of those silos, you're going to get a management factory talking about the measures that hold that part of the system to account. And if the measurement system is wrong, it's going to drive a lot of the behaviors, which says, it's fine. Carry on in isolation doing your thing well, because that's what you're measured on. So when I talk about the system, I'm also talking about the things that set up on top of the system like measurement and the way that we budget annually, et cetera, et cetera, what was the system conditions need to change to really support end to end?

00:14:20

Yes. Interesting, because you talk about, and I see it every day, there's kind of a local optimization within somebody's department, within somebody's group, whatever scrum tribes or guilds or whatever they've got, but fundamentally you've got silos in there and you're optimizing at that level generally governed by a whole set of proxy metrics that are not helping to either inform about how work is really flowing or to know where to start and improving it is that you see.

00:14:52

Yeah. I mean, that's what I talked about most measures and, um, yeah, we do refer to them as proxy measures because they proxy measures when it comes to real improvement in floats. So you do see this pattern over and over again, and, um, logs are being enough to like, do, I've seen it in past experience to show that the measures that you think about, about your own performance of proxy measures, when you think about what it really takes to go from concept to cash or idea to liable or fall into, and because those measures in isolation and not an indication of how the whole system's working, and then the key thing is actually understanding how the systems work in end to end, you need the right measures of flow and all the related things that allow you to improve your flow. And in, for us, some of the things that are really important in that system are the difference between needing a login managers.

00:15:47

And even though, even though timed market is a really important measure is still a lagging measure because, so say for example, a really good, um, really good leading measure in a, in a, in an end to end system of which you're looking at, um, the states of, um, progression is age time in that part of the system. And as soon as you start, when indicate, well, this thing is now stagnate, and then it would tend to, um, tend to make you look at why it stopped or why you're stuck in a system not concentrating on a proxy measure, which says I'm finding because I bit, my story points target, for example. So proxy measures like points praises.

00:16:42

There's a, there's another point about proximity, proximity amazes don't win prizes. Okay. I'm going to, I've got to make a note of that one. Um, but just, just picking up on that, because it is an important point, and not only does it not help you systematically, but I think it was Jeff Bezos made the, made the point that, um, if you're not focused on the customer, but you're focused on a proxy for the customer either, you know, customer surveys or particular internal metrics or whatever, after a while the process becomes the thing. So it's not only that it's not informing you on how you can improve, which is presumably one of the key rationales behind using any pro any metrics of any sort, but it's also actually distancing you from the customer because you're focused on the wrong thing. So it's, it's a dangerous thing.

00:17:28

Absolutely.

00:17:30

Okay. So, so brilliant. I mean, if, if, if that's, and, and that's a key, anti-pattern that I think, think I see, uh, as well, what are the other anti-patterns that you, that you've seen over the time as you've been pushing forward with the systems thinking and, uh, introducing it into the service service industry here? What, what do you see?

00:17:49

There's a couple of things I'd say, um, let's just hold onto the value point and talk about that separately in a stack. And, um, I know it may upset a lot of people with these, these comments, right. But let's just think back to what we talked about, the various functional, specialized nature and organization, right? One of the partners, believe it or not implement Instagram in our organizational design.

00:18:21

And what I mean by that is just think about what we've talked, talked about. Let's just say that you've got some highly productive scrum teams that represent a part of the system. Don't get me wrong. There's nothing wrong with scrum when you've designed the organization to support it prop properly. So if you have all the way back to the original article, um, the new, new product development game, yes. The way they described scrum in that article was the team. I taught autonomy to move the product development through its total cycle to the end, right? What, what people have done where they're the, the translation of, of scrum is I'll take the ceremonies and I'll take all the activities and I'll do them well, but I'll do them in a team that does not have the autonomy to deliver the thing end to end. And what you tend to see in, in, in instances like that is lots of teams work 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 then put them in the queue. And then somebody else has got to work out all the bits go together. And so for my, from my point of view, it is an anti-pattern to flow. If you do it in an organization, which is still set up as a functional, specialized design.

00:19:48

Okay, I get you. I was a little bit worried that I was thinking you're now challenging the most widely by a long way, agile approach in, in the world, it's used, practiced everywhere. I will know what are you going to say? But actually, um, w what you're saying makes total sense and the emphasis on, on ceremonies, we w we see it, you know, we're doing it. Therefore we are, it is, um, is, is flawed. Absolutely. Um, I had to look actually it's okay, because this is not an agile conference cause they don't do agile conferences anymore. Uh, and thank God you haven't, you haven't said anything negative about dev ops. So, uh,

00:20:23

That's my next point. So the next time,

00:20:28

The next time you partnered, I, I do see is that generally we, because we don't wanna, cause we forget about the system and the total time it takes to own the total journey that work has to go through. We become very, um, I say focused on the technology, which, you know, in some occasions is a bottleneck. It is at the end of the system, but dev ops is, is necessary in those conditions, but it's not sufficient. So if you take a lot of, okay, let's say let's take flow efficiency as a measure, right? And then you look at a hundred percent flow efficiency, which is like, you know, would never be achieved because you'll always get some kind of weekend time in a system. But if you look at the majority of the time that, uh, the negative time lost in an end to end system, most of it has to do with your organizational design and most of it's to do with waiting for somebody else.

00:21:29

So in our context, from a dev ops perspective, the amount of time in that equation of a hundred percent, that dev ops has an effect on is only very small. So it's, it's it's necessary, but it's not sufficient because the sufficiency, if you like the amount of waste in a system can only be normally taken out by changing the organizational design, put it in lip limits in et cetera, et cetera. So that's what I mean. It's not that it's a bad thing, but become over reliant on dev ops as a thing that's focused on a very small part of the total waste.

00:22:09

I get you now, of course, if you're bottlenecked on your, on your pipelines or your path to production, or you need to be releasing more frequently than you're able to, if, if that's where your bottleneck actually is, then of course, there's fantastic way to automate, uh, all this and then improve. But I guess what you're saying is if the, if the issue is somewhere else,

00:22:31

It's not the biggest yeah. If it's not your bottleneck, then what's the point. Yeah. And the other thing, as well, as what we got think about with that statement around, you know, being a bottleneck in the technology might not be the bottleneck. It may be governance. It might be or authority to proceed. It may be that working in a very risk averse organization, which means that everybody has to have a say on whether the thing go live or not. Anyway. So, you know, there's a lot of, there's a lot of systemic waste and this is what I mean by not only ends when, but the system around it, you could have the best dev ops pipeline in the world, but you could have procedures that don't allow it to flourish. You don't, you may have procedures in your organization where it says, we know that we can do automated everything, but actually we need a manual check.

00:23:21

Yeah. And so this is where some of the flow metrics become really important. So, you know, um, the, the flow of extra X based on the key units of, of features and defects and debt and risk, and as you say, that's something business and software engineers can collaborate on. And what's the, what's the right mix for this particular one. Where are we, where are we got at the moment? Are we delivering with the right priorities? Yeah. Okay. Okay. Um, I think we probably got away with that. One on a dev ops company

00:23:55

Is necessary, but not sufficient,

00:23:58

Not good at anything else that, um, that, that strikes you, that you see sort of,

00:24:03

Yeah. 1, 1, 1, 1 last and department is doing the wrong thing right there. So, you know, they know my words, I borrowed them from a golf and Peter Drucker before I think, but, and this is where I really learned a lot from, um, John Seddon around service environments and the over-reliance on it first, not lost. And, um, I'll try and bring that to life. I mean, best just go back to the front, end, the service, right? Because ultimately be taught, ready to get into me around business value and software delivery. They should tag. Right. They should be one. And the same thing. Why would you build anything that it's not really solving a problem for the customer? Right. So I w well, we, and this is not just, you know, it's, it's an industry wide problem. You still see on some of the agile, um, the reports about the state of our job, you know, still lots of efforts and code and things being produced that actually never really make a dent in the marketplace by customers never really deliver revenue generation, for example, you know, um, at the scale required to, to really make, um, you know, a case for the return on investment.

00:25:23

And what we tend to find is the only partners technology first, the last, and I try and make, try and make, um, a tangible example for that. So this thing about, uh, a big service environment call center, which is where I spent a lot of time. And we talked about the concept of, um, failure demand, right? So that's demand by a customer saying, you know, I can't understand my statement, or, you know, you haven't come back to me or blah, blah, blah, blah, blah, or they never turn into complaints, but they, they, they, they take up capacity a deal with it. Then you said a source of dissatisfaction or technology first, uh, there were the world might say, Hmm, what about this voice to speech technology? What about AI? You know, how can we start to use these technologies to service our customers? So you might have lots of activity in a software delivery system looking at using technology to serve customers when you shouldn't even have the demand at all.

00:26:24

Right. You should just understand why customers don't understand, for example, the thing that they talking about and switch it off at source. So, you know, the improvement effort would never be software. And I guess first it would be last. And another good example would be saying something like, you know, that let's, you know, in that example, what you should say is let's think about how maybe technology could serve the customer when it's value demand, when it's the things they really want from us. Right. Because why would you put any effort into building an it solution for something that you'd never exist in the first place? And a lot of that was on.

00:27:09

So actually avoiding, avoiding some of this stuff is as important as doing some of this stuff.

00:27:16

Absolutely. And that's where, that's where we seem to get ourselves in quite a pickle with software delivery is a lots of occasions with building things without context, or the problem is trying to solve from the customer perspective. And or even if the problem should exist before we start building anything. And that's what I do get a problem with, again, the sprint goal from scrum, the sprint goal, we're doing the wrong thing right there. It could all be wasted effort.

00:27:46

Yes, yes. So your folk, you focus very much on the outcome that we want to achieve as a business, or I take it back to the business, to the business goals. Are this your analogy with the, um, with the help center help desk absolutely will hit home to anybody that's, uh, used any of the help desk, uh, facilities. Yeah.

00:28:08

I mean, I mean, from a, let's just think back to a dev ops world. If we could ask a question to the audience, really, you know, if we were, if we weren't virtual, but it's like, how many of the people who are brilliant engineers actually get any idea of the context of the problem you're trying to solve from the customer's perspective in a service environment? One of the things you've really tried to do in life just to try, and it's not always easy and it's not always achievable is to connect our engineering capability with the actual customer need because gen, gen, gen generally the engineers are the last person. If you like to work on a thing before it's gone. So what is design stages? I mean, you normally got people doing design work at this end, connect disconnected from the people who are doing the actual coding, and you see that pattern quite a lot in an organization. We never really tend to, and let's go all the way back to the original principles that scrum were built on. The whole team moves the product through the system together. And we just generally, again, because we think about an organization in terms of specialization and functionalization, that's one of the reasons why there's always a separation between when the code is built and the problem from a customer's perspective.

00:29:28

So much of what you've talked about it. And by the way, thank you. This, this has been really, really interesting. So much of what you've talked about has been cutting away that basic approach and focusing more on that approach, focusing on the customer, focusing to end focusing on the systems and really, uh, driving efficiency and effectiveness through that rather than localized, siloed approaches that we see, we see every day. Okay. We've got just very, very quickly. Um, and we haven't talked about happiness at all, and we'd, we're kind of out of time on it, but I just want to pick your brain on this one. Your, your team has to be one of the, one of the most positive teams to work with. And we we've been working together now for a number of months, but, uh, w w what's the secret in this? They, they, they feel empowered. They're positive. They're looking for all the way, all the time for solutions, how you just got lucky with the team or, or what, what, what what's going on.

00:30:23

Um, I'd like to say that is a bit of academic reasoning for it. So, um, I've been highly influenced since I dunno, 10 last 10 years, maybe more in terms of Devin's work. And, you know, the, you know, that the outcomes that we see in an organization are due to the system and, uh, you know, people are always, they do a good job and I'm very fortunate to have the people in the team. Um, I've also been influenced. So I kind of thinking, and we, we generally ignore hierarchy. We generally ignore chains of command in traditional sense. We're all professionals. We know what we try to do. We have a clear purpose and we just treat each other with respect. And, um, and I love a lot of, and all of the agile kind of work is built around, um, you know, people over process, et cetera, et cetera.

00:31:17

I got my mind is very much split on that because of what I talked about earlier in organizations and them being designed like they normally designed, um, unless you change the system, things like measurement, et cetera, et cetera, you can do all the work you want to do on things like psychological safety and culture and those kinds of things, but they don't work unless you change the system, you may get a very short term effect, but eventually, you know, in rule based systems, the behavior will go back to what it was before, because all the way the system generates behavior, I think in my team, I'm lucky we understand that and we tend to ignore the system conditions or behavior and write it off because we know it's effect on us. So I think we quite like you understand its effect and we try and ignore it.

00:32:07

Um, it's, it's definitely working. It's noticeable. So, um, there's, there's been some stuff in here, but I hope that, um, uh, everybody, uh, tuning into this we'll have got some, got some value and some pointers, some things to take away. And certainly your, your points about activity thinking, moving towards flow, thinking, um, getting away from the cost fixation, challenging assumptions within, within organizations, making sure that work is visible so that you can see end to end concentrating on leading rather than lagging, um, would be aware of overuse of scrum was it was another one. And we used use dev ops. We recognize it's necessary, but not sufficient. And don't fall into the trap of doing the wrong things, the wrong things, right. Or real quicker. Fantastic. Justin, thank you very much. Wish everybody and goodbye from us.