Learning about flow efficiency with Tina Dankwart-EN

Table of Contents

Netmind Talks | Flow efficiency with Tina Dankwart

What does a Value Stream Architect do?

Tina Dankwart is a Senior Value Stream Architect at Tasktop, a Value Stream Management platform, where she works with traditional businesses helping them make some real changes in how they deliver technology by implementing flow efficiency techniques.

We would like to ask you to tell us about your background and what you are doing with flow management and optimizing the work of the teams

In my current role, I work with traditional businesses helping them make some real changes in how they deliver technology.

So mostly software, we have hardware elements, we work with banks and automotives, as well. So, the whole combination of it. We are helping companies to make some true changes and optimizing how they deliver.

I’m particularly passionate about aligning everything to outcomes. There’s far too much going on about whether we measure things by activities or output. All those are important, of course, but I’m really passionate about getting people to think about what does success look like. What is the outcome that we are aiming for? And that goes into a lot of the work I do on a daily basis. 

And how did you end up doing this?

I used to work for a very large software company, software and hardware, for Hewlett-Packard, and I built solutions for some of their largest SaaS clients, reporting across the board, across different projects.

So, I spent 10 years of my life building data lakes and then trying to get the information out. I experienced firsthand what it is like to be that poor person who has to try and extract some of the information.

And then, at some point, I used integration, for example, to solve some of those problems, which is kind of Tasktops’ foundation. It is integrating and bridging those silos that we have in companies, and I just love the vision of the CEO.

I actually moved there before he wrote his best-selling book Project to Product, but I just love the vision. And I love the work atmosphere there as well. That’s kind of how I ended up there.

How was your first contact with Agile? What were your feelings about it? The very first impression you had

I come from a complete waterfall background. I mean, don’t we all, in a way? But I went to university when that was still the methodology taught. It was all about defining requirements and how important it is that we understand that and then go from one step to another.

I then moved into a company where I supported and later was a Solutions Consultant for one of their biggest ALM products, which is very much about waterfall. That’s sort of my background, and then obviously, all this talk started that it should be done differently, and I was intrigued.

I started to understand what our problems were within that company that I was working for, the problems, one about the silos and the lack of agility, and nothing being aligned by product.

I, at that point, though, it was kind of very odd that nobody seemed to own the overall thing, we’re all in our little bubble, and we’re making decisions. It’s difficult to make those decisions, but I’ll be honest with you, my first thought was, “oh, there goes our customer base.”

This is going to take off, and it doesn’t fit with what we do. So, either we’re going to change here and do something very differently… And we did see that it eroded the customer base. People were jumping off onto the Atlassian stack,  and various other products as well started taking the market share because they were much more aligned to that way of working right.

Whereas the traditional ALM products, definitely not so much. They base everything on the step-by-step, making it through that waterfall. So, the honest answer is I just thought, “oh, this does not bode well,” but I was intrigued by it, for sure.

So, your methodology has evolved in the same way that your view of managing all this has evolved too.

It definitely has. So, for one, is that I now see it as absolutely essential (agile and DevOps). And I also think it’s not enough.

It’s not just the Agile transformations. It is not enough. We need to start to pay attention to flow. We need to measure the right things. There’s my outcome topic again. We also need to measure, in order to optimize, to deliver faster, better software and technology. So that’s a big thing.

We need to know whether the Agile transformation is successful. We see so much of this rebranding exercise. It’s the same thing. People just go and take something. They take a team and say, “You’re now a value stream,” but we’re changing absolutely nothing.

We’re not changing, and it’s everywhere. You get this with the Agile thing as well. Let’s just have some agility, maybe. Let’s celebrate that everybody now works in JIRA, right?

But the most common thing we actually see is that people think they are agile and they’re really not. You get this little scrum sandwich, is what I like to call it.

So you have the dev team, and they’re really agile. But then the overall thing is run by an 18-month funding model, where I’m going to decide now what we’re going to build in 18 months. Well, that is not agile, right?

And so, there are companies that know they’re not agile, and they admit to it, and they think, “Oh, we’re so far behind.”

But then there are the ones that actually think they’re really agile and give themselves a pat on the back. And when you look at it, it’s a watermelon: on the outside looks green, and the inside, completely red, is not agile at all.

Because you have your funding model on the one side, and on the other side, the release management. It is a really common thing there where, because of the funding model, you have these huge chunks of work that have to be completed before the customer can have it in their hands.

So, you optimize the building of it, and maybe the testing and everything, but then you have to wait for all this other stuff to finish before you get it. And this is a really important part of this, of measuring end to end.

If we just optimize the little bit in the middle, we achieve nothing at all. And then, of course, the whole thing of what does success look like? Let’s make sure that we align it to that, and that’s the bit that we need to add to Agile transformation.

Otherwise, we find that we don’t even know whether we’re getting anywhere or not. We’re doing the routines. We’re calling everybody Scrum Masters, but actually, have we changed something? And if so, how do we know? What are we aiming for, and how do we know that we’re getting there?

Optimizing the flow of work

In our case, we talk to banks or insurance companies, as our customers here at Netmind, we are still seeing the managers trying to optimize the resource utilization to ensure that everybody is extremely busy. So, what are your tips when moving the discussion towards optimizing the flow of work?

I would say the two are completely linked. How am I going to optimize and utilize perfectly if I don’t measure end to end?

I’ll give an example of that. We worked with a large insurance company, an American Insurance Company, and they knew they took 120 days end to end to deliver something, but they didn’t know exactly where the work was at any point. And what they were doing is they were throwing developers at the problem: “Surely, if I throw lots of developers, I hire loads of them, that will surely solve our problem.”

When we dug into where is the work getting stuck, they realized that it took two and a half days out of 120. And you can optimize that out of your value stream completely. And you’ve made no difference at all.

It is so important that when we want to optimize our resources, we start caring about flow so that we can put the right people in the right place and align it with what we want to achieve. Do we want to be faster? We want to make sure everybody’s busy and working on the right things. But ultimately, that’s what we need to focus on. And if that is what we want, we need to know where’s the bottleneck and then put the right people in place.

You’re talking a lot about flow efficiency. What is your definition of flow efficiency? And most importantly, how can we measure it?

First of all, let’s think about flow time. And because the two are linked, of course, when we’re talking end to end, we need to understand, first of all, how long does something take to get through my value stream.

The beginning is when the customer is asking. The clock starts ticking when the customer asks for it. It’s not when it makes it into the backlog. It’s not when the developers have finished it and job-done sort of thing. It is really when the customer has it in their hands. So we need to think about this truly end to end.

And then efficiency is, of that time, how much of the time, is it waiting and how much is it actively being worked on.

All wait is waste. Always, no exception. If we want to become cheaper, drop costs, use resource utilization, optimize, get faster, and so on, we want to cut out the waste.

So we need to measure it, but it’s not that simple. Usually, what people think is for efficiency: “yeah, I have a blocked state in JIRA.” So, I can tell you exactly how much time it’s stuck.

Unfortunately, the block status has two major issues with it. The first one is it is not very granular. It doesn’t tell me where stuff is getting stuck. It could be waiting for testing, waiting for devs, waiting for some sort of approval. Ideally, you would want far more granular states.

But the bigger issue is actually when you look at states, done should be my favorite state because done could be anything. Done is the most common wait state you will find and the most overlooked.

The really important thing is we need to make that stuff visible. And it’s not easy, but it’s so important that we consider it. And it’s not the same for every team. It’s not that it’s not one size fits all.

So, me, the poor engineer who had to go and try and get something out of a data lake, it’s tough to do. Because you need to be able to model it, depending on how that team works. So done for one team might actually mean the customer has it in their hand. That’s it. It’s done. And I keep hearing people referring to it’s done, it’s done-done, and it’s actually done.

Of course, we can’t just go and align everything in JIRA, or as your DevOps or whichever tools we’re using. Because all the teams work differently. And that’s important, Agile, power to the teams and all that is important. We need to find ways to make visible what is going on instead of what we think is going on.

The other state that is hardly ever accurate is work in progress. Are we waiting on something? Are there different ways we can look at that we can say, “Okay, work in progress assigned to a testing team?” They may be waiting on it, waiting for the testers. Are they actively doing stuff?

We need to break that down more and more and get a clearer picture. To begin with, you get a blurry picture of what’s going on. And the more you dig into it, the better a view you will get.

That’s where you can start optimizing and showing the improvement of cutting out all that waste, and it will increase your velocity as in the amount of things you put through, and hopefully decrease your time to value.

In those cases, to track all those states that you are mentioning, you need information there. I guess that the testers or the developers need to register the changes somewhere. How much information should they provide without overloading them with extra work? Because they are already busy.

There are two answers to that. So, any improvement takes effort, right? The gains will massively outweigh, and the important bit there is we need to consider why: why are we doing this at all.

People don’t like putting things perfectly into JIRA because they see no return on it. “It is just some stupid admin thing.”

Well, we’ve all been there. Starting tracking your time, it’s everybody’s worst nightmare. So first of all, we need to create a compelling why because, in the end, change happens in the teams if they want something to change and if they see they can make changes to their more significant headaches. Like, “I’m constantly waiting for testing, or I’m overloaded all the time, or I just can’t get around to the real stuff I want to do because I’m constantly distracted by all this other incoming stuff.”

Once you get the real why there is an answer to them, they will be like, “Okay, well, now I see a point of putting that in there because I can use that data to make a strong business case to have something changed.”

The other option, of course, is there are tools available in the market that can help you with that. You want to model that, but the big thing is, and I think it’s really important to set the right expectations for these transformations.

There is some work involved, even in tools, and you need to model it because obviously, every team works differently. If you want to give a clear picture of what’s going on, we do need that effort. And so, it’s really up to the coaches and everybody to create the environment to motivate people and help people understand why we are doing this. What’s in it for me? And that it’s really critical in all of the work right now.

The impediments of implenting flow efficiency

We wanted to ask about the significant impediments you have found with flow efficiency? How can we identify and try to mitigate these impediments in a company?

Unfortunately, there is no one size fits all answer. There are so many different things.
I guess, when we start to measure, we come across lots of different things that could be and the most common one that we find, actually, and I’ll use that as an example, is the work in progress.

Too much work in progress. That is the big one that you will see across the board everywhere.

Why is work in progress a problem? First of all, in overloaded teams, employee happiness will plummet immediately. It is the biggest killer of employee happiness and the highest driver of staff turnover whether they go off sick, which by the way, it’s a great measure.

I’ve seen companies use that as a measure to see what are the sick days are doing because if we overload them and they’re unhappy, people go off more often, it’s just a side, but they also change jobs.

So employee happiness is critically essential. Unhappy people are not as efficient.

Second bit. When you overload the teams, the velocity will drop. It’s context switching, but you can even see it on a motorway. The more cars I put on the motorway, the less stuff will get through.

We ran an experiment, we took 10% of the load of a team, and we got a 600% increase in productivity. It’s incredible the difference it makes. So it is really important.

And finally, the unstable system. Thinking of that motorway, I can’t predict at all how long it’s going to take a car to get through the system.

So I can’t tell you what’s happening with that, in terms of the average time.

And if I can’t do that, I can’t predict when it comes to resource allocation; when it comes to predicting when something’s going to go live, I’m not going to be able to do that.

Or worse, I might be patting myself on the back because things are getting faster. And I’m only measuring ambulances because they can get through. Whereas 80% of my stuff is still on the road.

What do we do about that? I use that as an example. Just because it is the most important one, people don’t realize the big issue with overloading our teams. We need to take some of these cars off the road.

Now, this is where the coaches come in. And you need to look at it and, if possible, implement a pull operation. You’ll find that teams are their own worst enemy because we’re always praised for being busy. It’s the team still doing it, even when we say stop?. On the contrary, they will be like, “But then I will sit here idle, you know, what am I going to do?”

It is particularly bad when you’re working with contractors. Because they’re like, “Oh, I must show that I’m busy.” The Agile Manifesto gives us a lot of advice on this and what you can do.

A lot of that is, back to my outcomes, what is it we’re trying to achieve? And let’s go and throw out all the stuff that wasn’t actually critical. Say no more often to the things that are not critical. Let’s be clear on our outcomes, and then go and drop the things that don’t matter, that aren’t relevant.

So those are some things but unfortunately, there is no one size fits all because it depends very much on what we’re finding. If we find a bottleneck and want to optimize flow, it depends on the bottleneck.

But the first thing is always to start the conversation. Why is it there? What is the problem? A lot of the time, the teams know, they know really well what the problem is. Let’s pull some of the testing into the developers, into development to optimize, because they can’t cope, and we’re waiting for ages, you know. There are so many different optimizations that you can do.

But this is where good coaching comes in, to help them because often you can’t, you know, sometimes they know. But, facilitating change is much easier, getting people in from the outside to help identify and make changes. Maybe we can add there that a really important factor for creating change is creating the environment for change to happen, that psychological safety.

We often find that we have all these insights, and now we’re going to do something about it.

We need to be careful to separate out that there is a problem, but you are not the problem. The problem is the problem—really important bits of the coaching there.

Now that you have mentioned this metaphor of traffic, there is a simulation about creating bottlenecks from the Deutsche Bank from the German government that is fantastic and very graphic. Nothing happens when you try to add additional lines—only by reducing WIP.

I think that the stability of a system is such an essential piece of everything. Because the minute we have too much WIP, the whole thing becomes unpredictable. We don’t know anymore. We can’t see when it’s going to be done. We’re switching priorities. And that’s the other big thing that comes up everywhere, priorities change all the time, but it is so difficult.

And exactly, you’re right, stopping the flow of new cars entering that system that you’re referring to there, that’s simulation, that is the only way to really improve, and then you can start measuring.

And obviously, we need to remove the bottlenecks or the roadworks along the way. But ultimately, the first thing we need to focus on is, do we have a stable system? And only when we have that can we really make a change in the delivery, and it has so many other positive side effects.

Are you still getting dissenting feedback from people who disagree with you in this flow optimization fever? What opposing or contradictory views are you getting related to these flow metrics? Because it is not that easy to implement these changes in big and traditional organizations.

I think the biggest thing that we hear repeatedly is, “Oh, no, here we go. Another one. Here’s another metric they’re going to hit me over the head with”.

That’s the first bit. Very little according to the metrics themselves and much more like, what is the point? It’s not going to change anything. Great. We have another metric. We’re going to sit down analysis paralysis. We have some more insights, but it’s going to do precisely nothing.

So that is the biggest thing is actually, we’re too busy to do anything. So those are the typical things and the opposition to them. And so, I think it’s really important that we consider that there’s the executive level and they’re really excited about it, they want the metrics, but the change happens on the team level, and so we need to be clear that for one, without action, it is meaningless. If we don’t do anything with the data, it’s a complete waste of time.

But more importantly, getting back to that psychological safety, we need to get to the point where people don’t fear the metrics but use them to make a strong case for things they want to change.

In the end, everybody normally goes to work because they want to do a good job. So it’s really important to carve out what people are hoping to get out of it. What are the changes and why. And what we find is once you implement it on a small scale, other people want a slice of the action because things are improving.

I mean, nobody hates it if you take 50% of their workload off them, and they can finally breathe. They finally understand, “I’ve got this big vision painted somewhere on the executive level. How does that even translate to what I’m doing? So I’m not interested, and I’m going to be measured on story points and how many epics we’ve turned out. But I have no idea actually what I’m aiming for.”

And when you change that to, okay, here’s what we want to do. Let’s all think about how we’re going to optimize that, how we’re going to make that better.

You create that atmosphere of, “Okay, we want to take action, and we have to create the safety as well to take action because they are experiments.” In the end, it’s quite a difficult one to put your head on the line and say, “Okay, we’re going to bring in the testing into development, we’re going to try that out and see how it works” Because it could fail.

So that’s why we must have data to back that up. We have identified a bottleneck here. Let’s come up with some ideas and how we can fix that.

And then let’s measure whether it has changed. And as you go, you can start addressing some of the bigger things. You’re not going to start with a funding model. Nobody will put their head on the line and say, “Yeah, let’s just change the funding model there and then.” But when you run small experiments and then widen that out, you get the buy-in from other teams. You get the buy-in to make bigger changes because you will be able to show its impact.

So those are definitely the most common resistances, do nothing, basically carry on with the status quo.

You mentioned this idea where it is tough to implement these changes. So, in those organizations, in your experience, what do you think are the most apparent impediments that you see when the companies have to implement this mindset.

You do need the executive buy-in, absolutely. Without it, you’re not going to get anywhere because you’re not going to be able to remove those obstacles.

If we’re thinking about the team itself and implementing their changes, they can make changes on their team level. But then, if we’re thinking about that little slice of my value stream, if I want to make an impact, there will be bigger impediments that will need to be removed to show success and to create the safety and time we discussed earlier.

We need the executive buy-in. And we do need for them also to encourage. We want to make changes, identify the problems, create that atmosphere, and we need that.

But also, that’s a big problem. The biggest thing is probably the whole analysis-paralysis, but everybody’s like, “Yeah, great. We’re seeing all this stuff. Oh, now we need to make a change.”

Change is hard. Let’s be clear. And so, that is probably one of the biggest impediments to implementing. Showing metrics is great, and it’s not easy.

But really, making real changes requires everybody to be aligned and think about why we are doing this. We need to come up with creative ideas on how to improve flow. And not taking action is the biggest impediment I would see when rolling this out.

Because getting the metrics is great, we can connect to tools. There are all sorts of ways of getting those insights, but then once we have them, what we’re going to do about it.

What you often find, especially in big traditional companies, is that people are resigned to the status quo as nothing will ever change anyway.

“We now have the data to back up what I already knew. Great, but I just don’t believe anything will ever change.”

It’s that sort of situation. And that can be tackled on all kinds of different levels. So on the team level, creating that. On the executive level, we need the buy-in across the board. And the ones in the middle, of course, as well.

How to implement a transformation

Before, you were talking about this way of implementing this transformation through a small experiment. So, it’s a kind of incremental way of approaching this. How long does it take to see the benefits?

It really depends on how small or how large you start. The most common approach is to start on a fairly small scale, on a couple of value streams that have, ideally, big problems. We don’t want one that has easy problems.

We want a big tangible problem, and visible enough for the company, to be a beacon, if you like, to show “Hey, we can make some real changes here.”

We’ve seen in the past, “Hey, let’s use the guys that are already super agile.” They’re great. But we’re not going to be able to show much there.

So if we want to effect change, ideally, we want to start with teams with an open mind and a growth mindset. That’s great if we can have it. If not, that is also fine.

But how long does it take, is kind of how long is a piece of string, so you would want to show some real changes within those value streams within sort of four or five months. You want to get the data together, that should be fairly quick, then you form your hypotheses, but it’s the change bit that takes longer.

The data and understanding it and getting insights should be four or six weeks. But the really important thing there is to make a change on the team level. Some changes can be implemented quickly; others take a much longer time.

And then you get into this region of dependencies with other teams. And so what happens quite often naturally, we might start with three, but actually, we find that there are dependencies on three other teams. So we bring them in as well. Because in the end, the value streams are not linear. There’s often this concept of a waterfall value stream, which is unfortunately not how values work. There are interdependencies and so on.

It is possible to do it on a huge scale, make everything visible, and optimize it. But really, the recommended way of doing it is to start small, make those a success, and then roll it out further and further.

The other thing is also making a whole value stream visible is not always easy, and sometimes not even possible. But what you’ll find is as you move to the left side of the value stream, they use PowerPoint.

Well, good luck with that one because you can’t actually pull it. There are no states in PowerPoint. There’s nothing to tell me how long it stayed in this particular state. It’s just not there.

It’s an ongoing process. There’s also not a point where we say, “Hey, now we’re done great perfect,” because, of course, once I move a bottleneck, it’s going to shift elsewhere.

If I want to optimize it, it gets smaller and smaller, of course, but my bottleneck is going to start shifting. Paying attention to flow is an ongoing process. But really, we would want to start seeing real measurable changes within a few months.

And someone like you, as a flow architect, your idea is probably to go with a team coach to have the team correctly identify the value streams. Do you need to be there all the time with them, or is your intervention something particular, and then the teams are expected to be more autonomous?

The second option. So, we find that a lot of coaching is needed in the initial stages. It’s really important because often, it’s a complete mindset change. And we need help to create that atmosphere to get people thinking about it and encouraging. And also all these things we spoke about earlier as well. “Now what? I’ve got the insight, how to change it?”

So you need people who have experience with flow and experience with agile to come in and help put things in place. Ultimately, the idea is to teach people to fish so that it gets built into the common routines they have anyway, that flow metrics really just become part of the everyday.

We optimize things, measure them by that, and know our OKRs. We know the desired business outcomes and keep optimizing them and ensuring that we don’t lose track.

We use it within Tasktop as well. We make sure that we keep measuring ourselves because we learn so much as we go. You never finish learning about the different things that you can put in to optimize things and what impacts things like employee happiness.

There is this idea of theme topologies, about using this inverted Conway’s law. He says that the structure of your company is reflected in the structure of your products. And in theme topologies, you need to change the structure of your teams to reflect the most appropriate architecture for your products. Do you think there is something similar that we can do to improve flows? Is there a way to arrange the different layers of the organization to improve flow?

In effect, virtually aligning the teams by the flow of work is at its foundation. I think the interesting bit is that the question I often get is, “Do I need to go away and design all these value streams throughout my company everything so that I can align the teams by those?”

And the most important thing to realize is that value streams exist. You don’t need to design them. They are there because value will be flowing through your company. If not, you would have gone out of business a long time ago.

It’s really about uncovering those value streams and virtually aligning them. But again, the really important thing is to start by measuring what it is now and let’s align and optimize according to what we are finding in the measurements.

So in our bottlenecks, where work is getting stuck. Do we see interdependencies of teams? And all those things, aligning the teams according to that to improve the flow of work.

There is no real design that we can give. After all, it changes because it depends on what you’re building as well. So it’s really important that we measure and then we optimize. We were talking about it; bringing testing into development is a really prime example.

Also, having product owners, of course, for decision making, all these things are really important. But we must look at those value streams and uncover them. They are there. They’re not what a consultant is going to tell you what they are.

We’re not designing them. We’re helping you uncover what they are and how they are interdependent.

Products are interlinked. So a value stream is as short or as long as you say it is. Because I can look at little pieces, let’s think of a car. A car in itself is a value stream. But it consists of about a million other value streams. Because I’ve got my sat-nav, and that’s a value stream. Within that, I have maps, and they’re a value stream.

So it’s important that we look at all the value streams and their interdependencies. And we can do that with those states we talked about earlier, looking at we’re waiting for this bit, and these teams hang together. And sometimes, we can merge those value streams, but they are a lot less fixed than people think they are the individual value streams.

So that’s why I’m saying virtually aligned around the flow of the value because they are not as fixed as we might think.

The future of VSM and final thoughts

How do you envision the future of agility? Where are we going? This idea of value streams, for example, five years ago, was not here yet. At least not with the power that is mentioned nowadays, but do you see some changes already, or something coming?​

Well, I think the big thing actually is Business Agility. Aligning business and technology, and let’s make sure we’re all pulling in the same direction.

That is the big thing. And value stream management has really just added on to Agile and DevOps and all of that. It’s an addition. It complements it.

Aligning everybody, making sure we all speak the same language. So as in, we know what we’re referring to so we can talk about tradeoffs, we can talk about impact, and we are all aligned to business value.

We get this so often in technology. They’re talking about story points, and the “business” go, “what are you talking about? I’m not interested. Tell me about the outcomes.”

And it’s so important that we start getting that right, that we get everybody at the same table. And we know that we’re all pulling at the same time, move away from the whole cost center technology. We need a value creation that is in line with the business. And I think that is the big thing, all of that working together.

Do you have some final words or something you want to share with the audience, tips, or advice?

Yeah, I think it’s, it’s to me, it’s the big things: start measuring. And think about what is success really. What is the outcome that we’re going for here? And that is the real final destination.

That’s what we need to get so clear on. Let’s get away from measuring our success on activities because ultimately, it fails. If we stop there, we will not make any change. And let’s be courageous and really make changes because that is the big thing that I think is missing. That we start measuring things and people get very excited and then they do nothing about it.

And at that point, the whole thing is such a waste of time. So I think the big thing is to start measuring. Let’s make sure we’re all aligned and then be courageous to actually take action and change something for the better.