#0013 - Visualizing your workflow with Mark Jørgensen Chaudhry

This is the no Nonsense Agile Podcast. Join us for discussions on agile product development and leadership with world class experts who provide valuable insights and practical advice to industry professionals. Subscribe now to learn the latest trends and best ideas in the field.

In this episode, we talk to Mark Jorgens and Chowdhury about visualizing your work so you can identify bottlenecks and remove them. We emphasise the need to work together to map out your process and identify delays and waste. We discuss work in progress, touch time, wait time and process efficiency. And we identify the root cause of waste and inefficiency in large organizations. Join us for lots of examples, challenges and recommended resources for improving your workflow.

Welcome to the no Nonsense Agile Podcast. I'm Shane Gibson.

And I'm Murray Robinson.

Hey. And I'm Mark Jaudry.

How are you, Mark?

I'm very good, thank you, Murray. Yeah. You want to hear a bit about myself?

Tell us a bit about yourself.

Yeah. Okay. So I am currently in a role as Agile coach in a big bank. I've been in this agile space since I discovered Scrum. And then as I've moved along, I've used other things than Scrum in increasingly larger and more complex environments. And today I'm playing the role of solution manager. And that's a reference to the safe framework. So I'm doing portfolio management and solution management for one of the business areas.

Good. We thought we would talk about the visualizing the way you work so that you can create change. So what's the problem we're trying to solve?

If we go back in time, a lot of the stuff done in organizations was physical products like cars. And when you're developing and producing physical products in a factory, you can see the work flow. We have a problem when we're doing knowledge work because we can't see the work we're doing.

Yeah, we can't see it. But also, we're not a factory. When you're producing cars, you're producing standard variations of the same thing over and over again en masse with a lot of automation. What we're doing in product development and software development is different all the time. I think of it as codified learning. In order to write code or produce a product, you've got to learn a whole lot of stuff in order to make something that works. There's a lot of uncertainty and trial and error.

Is it really? There should be a standard set of steps to create a website, but there aren't. We pretend it's harder than it is. I agree that there is Often problems to be solved that haven't been solved and we can't have a set of factory steps. But a lot of the times now there should be factory steps for some of the stuff we build, shouldn't there?

I don't mean that it's never been solved by anybody, Shane. I mean that you personally, as a software developer, haven't solved this particular problem before, so you have to do some learning. Whereas if you're a factory worker putting wheels on a car, it doesn't take you long to learn that and then that's all you're doing. With websites, there can be a lot of uncertainty about what the user wants or how they're going to behave. And if you're trying to do things like get a 5% increase in leads, for example, you got lots of ideas, but you don't really know which ones are going to work until you've tried it. I mean, obviously what's happening in our industry is that we're developing powerful software tools that make it quicker for us. We don't have to write an assembler anymore, so that does help. But there's still a lot of uncertainty in learning.

I think when we start looking at the work being done and visualizing that amongst our teams, we then see where the bottlenecks are and then we can focus on removing that blocker. So I agree we shouldn't be factories, but I think we should adopt some of the things that have been put into factories to help us work in better ways.

Look, I think that there's a system development life cycle that you go through for everything. When I visualize the workflow with the Scrum team, I put up columns that say backlog, analysis, design, build, test, deploy, because that part of the process is pretty standard.

What about you, Mark?

When you're visualizing the work, what techniques do you use?

So the context I'm in is not a. It's not one team, it's a team of teams. So you have four levels. Portfolio, solution, program, and then an agile team. This is a huge organization. To deliver that solution to the customers. We need at least six release trains. And each of those lead strains have their own process steps which are in my mind exactly the same. In safe, it's analyzing, then it's backlog, and then it is implementing and then we have a validating. And then it says on staging before you deploy to production and then there needs to be a feedback loop. Whatever it is we put to them, we need to get feedback. So these are the same process steps on a High level of abstraction for each of those entities. You could see those at, like, conveyor belts and feature factories because they are there to produce stuff and they cannot do this alone. We all have to do it together because else there's no product at the end of the line. You need both the tires and the chassis of the car and the engine. So this is the system how I see it. And you need to visualize that somehow, for instance, with Kanbans, via some tooling.

Do you have any other examples of visualizing the work outside of safe?

Yeah. So maybe there is an existing process, and then we're trying to improve that process, or we're trying to create something totally new. So you can draw that together, a bunch of people. You can facilitate that. In a place I was in, it took one month to send out an email. Okay, why does it take one month to send an email? So I actually brought 30 people into the room and I say, I think we have a problem. And then I say, okay, who starts the process? Somebody raised their hand. Yellow sticky note up here. Okay, you're doing this part now. Who's next? So first I had the whole process there, and then afterwards we took all the IT applications involved below. So that's a way of visualizing an existing process. And then we could actually look at it and say, why are we doing that stuff or that stuff? Can we actually remove some stuff together? And maybe we can even eliminate a. An application, because it doesn't actually make sense to have that there, or we need to get the data from somewhere else. So that's just a way of coming to a common understanding, doing that together.

As you were doing that, were you able to find out where the bottlenecks were?

Yes, and that was not me doing it. I was basically just facilitating. I didn't know the full process myself. So, yes, as a group of people, we were actually able to point to a couple of things where we say, this is not so good because this takes a long time and it requires a lot of effort and the quality is not really good here. So we identified as a group of 30 people in the room for two hours, and we then could actually agree, let's do something about A and B to improve. Because before nobody knew the whole process. We just know bits and pieces in our own little bubble. Which is a problem, I would say, in general.

Yeah, it's a problem of functional silos and people blaming other people for problems. I've done the similar sort of thing in a digital agency where the problem was that it Took a long time to recruit people and they wanted to reduce the time. The COO and the program managers thought it was because the HR people were slow and the HR people thought it was cause the COO and the program managers couldn't make up their minds. So I got people together and we visualized it with sticky notes on a wall like you did with decision points. And as we went I asked people how long did this take and how long did that take? And two one hour meetings. Really easy actually. We were able to map out the whole thing and we discovered that it was the COO who was causing all the problems, the one who was complaining about it because we wouldn't sign off a brief for recruitment. And then he insisted on all these extra review points to say is this really needed? So once we're able to map it out, we were able to see that and put in place a process where if you agreed on the brief then you went ahead right up until the end, you didn't have to keep stopping and going to review meetings and so on. So we managed to cut about 40% out of the recruitment time by doing that.

Taking this systems view and trying to get common mental models by drawing them together. I think that's key because that can take away the whole blaming thing, which I definitely do not like. And I also observe that painting the picture together helps. And you say where do you want to move together?

Yeah, that's a balance between systems thinking and some process giving the teams the freedom to identify how they want to change the way they work. If we don't put in a framework that tells them every step and they have no control of, of success. But we also don't let them into chaos. There's a really good website called how to Make Toast. It comes with a video. I typically use that to explain how visualizing the work helps you understand where the bottlenecks are. But I mean, pick up your point, Murray. I think you mentioned that once you had visualized the work done, it was identified that the COO was the blocker, that they were putting a bunch of processes in that were slowing things down. And it would be interesting whether they would remove those tasks because they're not valuable. Do we need all that process? Is it valuable? Can we remove some of it to make it simpler?

I mean, as you're going through this, it's a process of asking do you need to do this or not? Or is there an easier or faster way to do it? And also where is the bottleneck? Like how long does it take to do this approval step. It's often the approval steps where everything stops.

Yes, I agree. I've been in a large organization in retail and then I was part of exchange approval board. It was nonsensical because there was all these change requests and I would say on a few it makes sense that we were there because those were like major changes. But most it was like why? Why do we even need to look at the teams know their application is just like one application. Let them do this stuff. It's not needed that we sit here and approve stuff.

I went through through CAB approval boards in Atelco and you would have to wait three weeks to get anything.

We were sitting on top of customer facing applications and points of sales systems and we did this on a cadence every two weeks.

What's interesting is that the people involved in the approval process don't realize how long it takes for the other people who are seeking their approval. What I'm trying to get too is that there's a lot of unintended consequences of management decisions. So management thinks we need to have a control board for high risk things. But then everything goes through it, including low risk things. And then there's too much to talk about so they don't get discussed. And then takes four weeks because you've got to go through two meetings.

So I can see cumulative flow diagrams and you're going to visually see where there might be bottlenecks. One of the things which I've seen a lot is bottlenecks flowing to production. So here the whole DevOps thing is definitely not working.

So what's interesting for me is when you get data and you overlay it with the visualization of the work being done. Let's look at the CAB as an example, looking at data about how many releases failed that were approved because that shows that gate isn't actually helping if the impact of the release is negative. The CAB should have picked that up. So overlaying data against your visualization helps you understand where the problems are.

I find that if you visualize this data, it's much easier to detect issues. I think our brains work better that way.

Yeah, because our brains are trained to look at patterns. So when something looks like a weird pattern, our brains say there's something not quite right here. We need to investigate more.

I was going to give an example from a telco I worked for where because of their process, it took 12 weeks to make a firewall rule change and it cost about $80,000. Now, if you've ever seen anybody do A firewall rule change. It really only takes five minutes to actually do. You gotta know what to hook up. The rules are, but it hardly takes any time. But this was causing a lot of problems. In all of our projects the process was you requested. It goes to a specialized group, that group appoints somebody to look after it. Then there's investigation and design. Those people have to be brought in to do the work and then it goes to a group to do the work and then they get it wrong and then you fix it. So the work actually happens in the last two weeks when you were fixing the problem. The first 10 weeks is almost always a wash. I mapped out the percentage of time that people spent doing value work divided by the elapsed time to see what the process efficiency was. And out of that 12 weeks, only about 1% of the time was actually spent doing useful work. I find that's quite an interesting thing to do with people to work out what is the percentage of elapsed time is spent on value adding work. If you have silos, it's always extremely low. However, if you do it inside a cross functional agile team, it's actually really high percentage of value adding work compared to elapsed time.

I have done similar stuff. So if you think about a doctor, there's a whole lot of wait time, not so much touch time. In many processes it's probably 95% wait time and 5% touch time, which is not very efficient. If you look at any process, there's the mention of operational flow, which is what we've been talking about here, and you can visualize that. There's also informational flow, information going up and down and you're actually seeing the same thing. So you could make informed decisions at various levels. And then there's financial flow and then lastly psychological flow, which is are we happy? So you asked me, have I done that? Yes, I was engaged with management for one, agile restraint. Then I said that we have 68 features in process right now, meaning from implementing and not being done. So we have one feature per colleague in the Azure release train in process. And what do you think about that? And they said, yeah. Then I say, I think that's a fucking disaster, because that is the reason why nothing is coming out of the process. So actually your job is to help limit the WIP in the start of that process. Those two numbers say nothing is coming out. I'm not saying what the solution is, but there's something wrong here.

I've definitely seen this problem where a program manager was complaining Bitterly that his team wasn't getting things done. After I spent some time with the team, I found that he was trying to shove more stuff into the front end of every team. So they couldn't get things done because they were constantly trying to start new things that were poorly defined.

Yes.

Which meant that they couldn't continue the things that they were doing. They were trying to stick 10 hamburgers in your mouth at the same time.

I think that is a fundamental problem that we have.

It's also about focus. A number of times a developer with a headset on, they're in their flow and then somebody will come up and tap them on their shoulder and just completely break the flow and we lose hours. So right near the beginning, you talked about four layers. You talked about portfolio, solution, release train and team and release train being around about 125 people. I get visualizing work at a team level. But when I start getting up to those other levels where I take work from 10 or 20 teams and visualize it at a release train level, how do you visualize that?

I struggle with that. I would say it depends on what it is we want to see. If it is a problem that we don't go fast enough to market, then you can use Kanban for that. You can count how many things moves from the start of the process to the end of the process. And you can also visualize that on a Kanban using different tools. Right now I'm playing the role of a solution manager and if I look at the Kanban, it's a mess. There's a lot of stuff there and I actually need to bring that number down because there's way too many work items in the funnel state right now. And there's no flow. What I could do is help sequence stuff. Try to work at one capability at a time across those arts. They all need to do stuff at the same point in time. If they don't do that, they get stuck. And then you're missing the one little piece that is sitting inside the engine. If that thing is missing, there's no car. So I think it's difficult to do that and visualize that as a system on the different levels. And the higher you go up, the more abstract. Okay, I have X amount of features or epics or whatever. Yes. But that doesn't show the process. And it's very difficult to say what should the flow be there. It's easier to do that on the team level while they're part of a bigger system. So I'm struggling. I Don't have a good answer. Rather than I can tell we have a problem there.

I wanted to touch on why you get all of these problems with flow in the work we do. I think it's because we work in silos and each silo is focused on achieving their targets and their service levels. But very few, if anybody looks at the system from beginning to end, and when you look at the system from the customer's point of view, or from the point of view of a product manager or a project manager trying to get something through the system, you find that there are enormous delays and enormous waste as you hand work off from one silo to another. In Waterfall, you hand off from a product team to a requirements team, to an architecture team, to a dev team, to a test team, to an integration test team, then to an ops team. Every time you move the work from one group to another, there's a lot of delays and waste added. And management rarely look at the total cycle time of work because their role is to optimize performance of their narrow area as much as possible. There's this basic assumption in management that if you divide the work up into small parts and do each small part as efficiently as possible, then when you add it all back together again, the whole thing will be very efficient. But I think we've learned from systems thinking and the theory of constraints that it's not true at all. We can see this in the organizations we work for. Things are ridiculously slow and expensive. The beauty of an agile team is that you're taking people from all of those different functions, functional areas, and putting them together in the same team where they're focused on the end goal. And that removes most of those handover costs and handover delays and things become a lot faster and more effective.

I agree with everything you said. What you're talking about is a typical way of organizing in big organizations. And I think that mental model is totally flawed and broken. I try to always take a customer perspective and when I say customer, I mean whoever the organization is there to serve. So that's the ones who are using the services and products of the customer.

So they could be an internal customer as well.

No, I think that's a total anti pattern. There's no such thing. There's only customers. And by definition it's those outside the organization which we're there to serve. Now if, if you want to say internal customer, you could say colleague instead, that would be way better.

But if, if you're an infrastructure team, you're providing an internal service to internal customers, aren't you?

To your colleagues. I don't like it because the second you say customer, you actually forget the customers on the outside. Now you're beginning to align towards the internal customer. You're actually not seeing the whole system. We all need to serve the customer on the outside. And I do understand what you're. I really do not like the word internal customer.

We can call them users.

Ah, users. That's fine.

So we're almost at the end. So what I think I'll do is I'll do my wrap up of the things that I picked up, then hand over to Murray for your thoughts. For me, visualizing the work being done is one of the most valuable things you can do. Visualize it. Look for the blockers, look for the hotspots, do something about them. As a leader, you're one of the few people that actually can stand on the gantry. You have the ability to look at the entire system if it's visualized. And therefore you have a responsibility to figure out where it's going wrong and help people understand that, because nobody else has that view. Murray, what did you have?

Yeah, I think that it's very valuable to visualize your work so that you can identify your bottlenecks, delays and waste. You can make actually really dramatic improvements to how quickly you can get things done by removing the bottlenecks. I really like your idea, Mark, of doing it together so that the people doing the work can see what the work looks like. That encourages them to take responsibility for fixing it. We're talking about a lot of things from the lean community and there's some good book people should read. There's the Goal by Eli Goldrath and then there's a book called the Phoenix Project which is the same idea as the Goal, but applied to Software Ops team.

I've read it, recommend it highly. It's an entertaining book that teaches you things versus a university manual. So it's a joy to read.

So as agile people, we are bringing in ideas from a lot of other different areas to help solve the problems we're dealing with, which is the problem of developing products and services that provide value to our customers. And we bring in lean systems thinking, design thinking, DevOps scrum. If we're doing agile properly, we're always thinking, talking and improving the way we are working by looking at all of this stuff and then taking it and designing a solution that works in our context, which is not the same as rolling out a standard playbook.

I definitely agree and I think that what often goes wrong is that we don't take this systems thinking perspective, and if we don't take that perspective, then we're sitting in functional silos and we should understand how we are a part of the system. I can't change the formal hierarchy, but I can influence colleagues on the mental models by doing some of the things that we're talking about here.

Yep, I agree. On that note, I'd like to thank you. It's been awesome and we'll catch you all later.

That was the no Nonsense Agile podcast from Murray Robinson and Shane Gibson. If you'd like help to create high value digital products and services, contact murrayvolve. Co. That's evolve with a zero. Thanks for listening.