Visualizing your workflow with Mark Jorgensen Chaudhry

Read along you will

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

Murray: And I’m Murray Robinson.

Mark: Hey, and I’m Mark Jorgensen Chaudhry. 

Murray: How are you, mark? 

Mark: I’m very good. Thank you, Marie. Yeah, you want to hear a bit about myself? 

Murray: Tell us a bit about yourself. 

Mark: 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.

Murray: Good. 

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

Mark: 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.

Murray: 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 on mass 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. 

Shane: 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? 

Murray: 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’s 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 percent increase in leads, for example, you’ve 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 in assembler anymore. So that does help, but there’s still a lot of uncertainty and learning.

Shane: 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. 

Murray: Look, I think that there’s a system development life cycle that you go through for everything. When I visualize the workflow with a Scrum team, I put up columns that say, Backlog, Analysis, Design, Build, Test, Deploy because that part of the process is pretty standard. 

Shane: What about you, Mark? When you’re visualizing the work what techniques do you use? 

Mark: So, the context I’m in is not a one team. It’s a team of teams. So you have four levels, a 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 release trains, 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 validating and then it says on staging, before you deploy it 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 bells 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.

Murray: Do you have any other examples of visualizing the work outside of SAFe? 

Mark: 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 said, I think we have a problem And Then I said, 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 can 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 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.

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

Mark: 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’re 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.

Murray: 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 because 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 he 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 were 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 percent out of the recruitment time by doing that.

Mark: 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 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.

Shane: Yeah, it’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. We don’t put in a framework that tells them every step and they have no control of success, but we also don’t let them into chaos. There’s a really good website called How to Make Toast that 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? 

Murray: 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. 

Mark: Yes, I agree. I’ve been in, a large organization in retail And then, I was part of a change 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 do we even need to look at it. The teams know their application. It’s just like one application. Let them do this stuff. It’s not needed that we sit here and approve stuff.

Murray: I went through cab approval boards in a telco and you would have to wait three weeks to get anything. 

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

Murray: 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 to is that there’s a lot of unintended consequences of management decisions. So management think 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 it takes four weeks because you’ve got to go through two meetings.

Mark: So I can see cumulative flow diagrams and you can visually see where that might be bottlenecks. One of the things which I’ve seen a lot is bottlenecks deploying to production. So here, the whole DevOps thing is definitely not working. 

Shane: So what’s interesting for me is when you get data and you overlay with a 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. 

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

Shane: 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. 

Murray: 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 dollars. Now if you’ve ever seen anybody do a firewall rule change, it really only takes five minutes to actually do. You’ve got to 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 request it, it goes to a specialised 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’re 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 percent 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 siloes 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. 

Mark: 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 percent touch time, which is not very efficient. If you look at any process there’s the dimension 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 release train 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 Agile release train in process. And what do you think about that? And they said yeah, no, I didn’t know. 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. 

Murray: 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. Which meant that they couldn’t continue the things that they were doing. They were trying to stick ten hamburgers in your mouth at the same time. 

Mark: I think that is a fundamental problem that we have.

Shane: It’s also about focus. The number of times a developer with the 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?

Mark: 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. 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. 

Murray: 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. And we can see this in the organizations we work for that, things are ridiculously slow and expensive. 

The beauty of an Agile team is that you’re taking people from all of those different 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. 

Mark: I agree with everything you said. What you’re talking about is 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. 

Murray: So they could be an internal customer as well. 

Mark: 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 you want to say internal customer, you could say colleague instead. That would be way better. 

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

Mark: 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 saying, but I really do not like the word internal customer.

Murray: We can call them users, 

Mark: Yeah, users. That’s fine. 

Shane: 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 and 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?

Murray: 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 books people should read. There’s The Goal by Eli goldrat and then there’s a book called the Phoenix Project, which is the same idea as the goal, but applied to a software ops team.

Shane: 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. 

Murray: So, as agile people, we are bringing in ideas from a lot of other different areas to help solve the problems that 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’re working by looking at all of this stuff and then taking it and designing a solution that works in our context, which is s not the same as rolling out a standard playbook.

Mark: 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.

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

Murray: 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 murray at evolve. co. That’s evolve with a zero. Thanks for listening.