Thank you. By way of introduction, I'm Jim Tranquill, as Bryon had just stated a few minutes ago. I'm with a company called Planview. I was previously with a company named Tasktop that was acquired by Planview. With me I have... We're going to tag team this today. I've got Dan Feminella, one of our Senior Value Stream Architects. Today, our talk is really around, again, Mission Possible, Accelerating Software Delivery in the Federal Landscape. Really focusing around Value Stream Management and flow and metrics, as Bryon had stated.
With that, I want to talk a little bit of the background. I don't think this is a surprise to anyone when you talk about digital product delivery and the challenges that not only the federal government has, but almost every organization has. We hear these same things over and over again. The time to deliver is too slow. I've heard Bryon talk in the past, about eight to 10 years to get a piece of software from an idea onto an airplane. Delivery is unpredictable. If you talk to the mission or the program or the business, do they really believe IT when they say, "We're going to deliver this software in X amount of time"? There's very little trust, I think, between the two. I think this will be a recurring theme about how there's a disconnect between the business and IT on not only what's being delivered, but when it's being delivered and how it's being delivered.
Bottlenecks are not well understood. There's a lot of times people in IT believe they know where their bottlenecks are, but there's a lot of times there's no visibility into where those bottlenecks may be across the organization. And again, talking again about this disconnect. The mission, the business, the program, they want to invest to speed things up, to make things better, to improve delivery, but they're not really sure how to do that. There's this big disconnect between the two, and it comes down to really getting that visibility and to seeing what value is being delivered for the organization.
I wanted to throw out some statistics, which were, I think, pretty amazing, and really point to a lot of the, I would call it inefficiencies in software delivery across organizations. We've had this move, these transformations over the last 10, 12 years, where people are moving to Agile and they want to be able to do things faster, but yet they're not seeing the results that they expect. We had done an analysis of over 3,000 digital product value streams, and some of the numbers that came back were pretty amazing. It really points, I think, to the inefficiencies or the areas that can be improved for software delivery.
8% of what's planned by Agile teams actually gets delivered. If you think about that, there's a lot of waste that's being done. Again, disconnect between the business or the mission and what's actually being delivered. 20% of features are canceled after the code has been written. Huge amount of waste in the organization. 35% of products have zero capacity for new work. This is a big one. I think anyone who works in software delivery, people keep asking for more and more and more. They keep putting more things on you. There's been study after study that shows that you start thrashing, you end up not really putting out anything new. You actually get less work done when you have more things piled upon you. Getting visibility into that is really, really important. 85% of products under-invest in security and tech debt because that's not the fancy stuff. People want to see new features, but yet they've got these other areas that are really slowing down the delivery across the organization.
And again, the next one is 95% of value streams have no clue what their real efficiency is. What we mean by efficiency is how much time are people actually working on that software product being delivered versus waiting for someone to approve or waiting for something else or waiting for someone else. They have no idea because they really don't have that visibility.
There's a lot of metrics that are out there that people use. And we had a talk yesterday on the DORA metrics, if you were here yesterday morning, which are fantastic for DevOps. There's developer portfolio metrics. But none of them really gave that end-to-end view of the flow of work across that entire... And visibility into that product value stream.
I had an example. I was working with a very large financial organization. If you're familiar with the DORA metrics, one the major metrics that are associated with that is deployment frequency, how many times you deploy. And they said, "We are really good at measuring deployment frequency." But if you talk to their customer or their business, they don't care. They couldn't care less how many times you deploy. That means nothing to me. Am I getting my features? Am I getting the things that I need? Where do I need to invest? Am I getting things faster? That's what they care about. What is the value? Again, we are in this shift from project to product, outputs versus outcomes. Putting outputs means nothing. I need something that shows value to the business.
One more slide that just backs this up with Gartner and McKinsey. 59% of digital initiatives take too long to complete, 40% of effort is wasted due to bottlenecks and overload, and 10-20% of CIO budget is allocated to tech debt. So these are, again, a lot of areas where there's inefficiencies in delivery. How can we improve this? How can we find all these inefficiencies and then make changes in our people, process, and technologies to make this more efficient across the organization?
Are you familiar with this book? Raise of hands. Okay, fantastic. All right. I'm going to talk just real quickly about this. And actually, at the end of our session, we'll give you the opportunity to download this book for free. But as I mentioned, I was with Tasktop, and our CEO, Dr. Mik Kersten, who's now CTO of Planview, I would say his lifelong pursuit was improving organizations to deliver software. He was noticing that all these organizations were doing these digital transformations, but they weren't improving. I think there's a famous one with Barclays out there where they spent $1 billion in moving to Agile and making all their Agile teams, yet they were still delivering software slower.
So Mik did a couple of different things. One, he went to a lot of different organizations and talked to a bunch of CIOs to try to understand where the issues were and why their transformations were failing. And the other thing he did, if you get a chance to read the book, but he went to a BMW plant. There's something in these manufacturing facilities called a Gemba walk, which is literally a walk over the entire manufacturing floor. So you get visibility into the flow of work all through the factory, and he could see how they built the factory to the constraints that they had for the delivery. The whole idea that Mik started looking at is using these ideas of lean manufacturing and lean and flow and applying them to software. They're different because you're not doing the same car over and over again or modified car slightly. Software delivery is different. But the idea was to take those ideas of flow and being able to give visibility into flow so I have better ways to be able to deliver software in more efficient capabilities.
So if we look at end-to-end flow here, there's a lot of steps if you talk about it. We like to say from the idea to actual operate, and it doesn't count unless it's in production and being used and providing value to the organization. So if you look, the Agile revolution was focusing on that dev, right? Everybody moved their dev groups to Agile. And then we got into the DevOps revolution. Okay, let's tie dev and ops together and let's start doing that more efficiently. And we've got the DORA metrics, et cetera. But no one was really looking at that, and it was even mentioned during the DORA talk yesterday, the shift left, or even the shift right to the actual delivery.
But being able to understand, okay, how much time is all this other stuff taking? Really, there's no visibility that people had into these things. And again, if you look at the Agile revolution, that time is not very long. There's usually a lot more time that's involved, and there's typically a lot of wait states and a lot of different things that potentially could be improved if you had visibility into where those wait states were and where their problems were.
Hello? Whoops. Wrong button. Big green button. So again, as Mik went through and introduced the book, key things came out of that. First one was to be able to measure and have those measurements of flow. We'll talk about that and Dan will get more involved into what the flow metrics are all about. Be able to measure your transformation with a common set of metrics that can be understood the business, by the mission, and IT so we have something to work together on. That connection between mission and technology so that you have those conversations of what value is being delivered, right? Not outputs, how many sprints we're doing or how many deliveries we're doing. More about what's the value being delivered to the organization, and allow organizations to try and experiment and see how they can improve that delivery. But you really need that visibility, and without the metrics of being able to see, it makes it very, very difficult to do that. So again, this is all about shifting from a project to a product oriented perspective.
From a raise of hands, are organizations going through that product shift right now? Anyone? Any of your organizations going through that product shift where you're changing from projects to a product oriented approach, a team of teams approach, funding based on a product versus an output, more of an outcome of value being delivered to the customer? That's what this is all about. And again, we're going to give you the opportunity to get your hands on this book.
Again, the movement is Project To Product. The book has sold over 50,000 copies. It's an Amazon bestseller, which is pretty amazing for a technology book. But again, like I say, it's almost like the next generation of DevOps, right? So taking it to the next step. In the book, Mik introduces the methodology called the flow framework, which is a prescriptive way to measure the flow of work through a product value stream. It does a few things. One, it categorizes the type of work that's being done, and it limits it down to four different types of work: features, risks, defect, and tech debt. Dan will talk a little bit more about that. It gives you the type of work being done, and then it gives you a set of metrics that are pretty straightforward to understand. We're going to go through that in a second. And then also then ties that product value stream to the business value that is important for that specific value stream.
So the whole idea here is you baseline the visibility of flow of the work through your product value stream, and then understand what changes we can make to people, process, and technology to improve that. We can understand where our bottlenecks are. Let's try this. Let's do these experiments. It's all about experimenting. And then we can see, do those changes that we make in people, process, and technology improve delivery? The value being delivered. Again, not just outputs, but looking. Do those changes help the value that's important for this specific product value stream? So just on that visibility side. And again, a lot of this is about being able to see, make your work more visible so people can understand what's happening.
I'm going to put another plug in. I'm talking about Mik's book here, but we have Dominica DeGrandis, who wrote a book called Making Work Visible. She's also one of our Planview flow advisors. But she's got a talk tomorrow on making work more visible, and you'll have ability to get her book as well in that. So if you get a chance, it's a really good talk about why it's so important. I think it was even mentioned in a couple of the different talks today, is that transparency. Sometimes people were afraid to show their work or show where delays may be in their product value stream. But making work visible, you need to be able to have that information so that you can make informed decisions versus just throwing darts at a wall and hoping that you're going to improve delivery.
So with that, I'm going to turn it over to Dan. He's going to talk more about the flow framework, the metrics and how they're done. I know. And by the way, he's always saying, "Shut up, Jim."
Seven slides, 15 minutes. I have 51 slides total. There's a lot of repetitive, but, thanks, Jim.
Okay, flow. It's the movement of connected work from one step to another. Easy enough. Value Stream Management. It's the practice of tracking and measuring work artifacts in real time to visualize the flow of value, value is the keyword there, expose bottlenecks, and drive ideas to impact as efficiency as possible. Efficiently. Read, Dan. What's this mean? Ensuring that the teams are working on the right things; using standard practices and metrics to prove productivity; finding and reducing waste, risk, and idle time; quickly incorporating feedback to adjust plans. One of the guys this morning who was talking about ripping up culture, he's like, "Why do something that you always do?" He said, "Always reiterate. Try, experiment, because you don't know if it's going to make you faster, better, cheaper, whatever. So always experiment, always adjust."
It is easy concept, right? The challenge, we want to reduce the time from entering the terminal to boarding the plane. We've all done it. We've all flown. I flew here. I think about it all the time. So what is the value stream? The value stream is the end-to-end movement of connected work, or flow, to deliver value to a customer. So it is your entire path, from walking in the terminal to getting to your gate, and all the steps that you must go through, all of the people you must talk to, everything you want to do. So how long did that take? It takes 45 minutes. Okay, great. That's good, that's bad, unless you're late for the plane like my father always was. One more click. Big green button, Dan. So that's our flow time. The whole value stream is the end-to-end. The flow time is how long it takes from beginning to end. From someone saying "I want" to you giving it to them. From you walking into the airport to you getting to your terminal, to your gate.
How many people do that every day? 100,000 people. So what's that? That's the velocity. That's how many things can you get through that value stream in any given period? It's the rate of people making it all the way through. So we've got value stream, we have flow time, we have flow velocity. I'm getting somewhere with this. 5,000 people. That's everybody still sitting in the terminal while you're at the gate waiting to board. So those 5,000 people are the flow load. That's how much value is in the process of being delivered. That's your WIP, that's your work in progress. That's the things that is happening that you said, "Yes, I'll do it," but it's Sunday night and you've got 1,000 things to do. But that's your WIP. That's something Dominica talks about a lot tomorrow. That's her whole book, Making Work Visible. So making this visible and seeing where the issues are.
10%. What's 10%? 10% of the time is the efficiency. That's when you're physically talking to someone, that's when you're putting your bag through the metal detector, it's when you're sitting at passport control, it's when you're getting your boarding pass. All the rest of the time, you were waiting. Out of that 45 minutes, you were only being efficient 10% of the time.
Number of passengers, number of crew, number of staff. That's the distribution. That's how much work and different types of work is in the airport at any given time. It's a different type of work that you're working on at any given time. We know that passengers take longer to get through the value stream than it does crew or staff. They don't have to do the extra metal detector stuff we have to do. They don't have to do the extra things. So that's something that can go through the process a lot quicker, and it must be tracked.
These are the flow metrics: flow time, flow velocity, flow load, flow efficiency. How long does it take, how much is being produced, how much is in the process, and time creating value. These are the metrics that came out of the book. Mik wrote the book. We're a software company. As soon as Mik wrote the book, all of our customers read the book and say, "We want that." And we go, "We don't have that. It's just a book our CEO wrote." And so we had to make it, but that's what we did.
Here's a quiz. You just had lunch, you're nice, you've been sitting here for four hours. Where should I invest? Any guesses? If I gave you metrics, would that help you in where you would invest?
Yes, Dan, it would.
Oh, quiet, you. You had your 15 minutes of fame. So if I told you that one person a minute is going through passport control... And I guess this back button... There we go. We can 10 persons a minute through check-in, 12 here, seven there, one is where we should invest. Without the metrics, you don't know that passport control is slowing you down. You don't know that people are lining up behind them unless you visually see it. The Gemba walk, we don't have that in software. Wouldn't it be better to put a second person in passport control? That would speed everything up. But without the metric to tell you that, you don't know, you're guessing. We have that a lot with IT customers where they always think the developer is the slow part of the bottleneck. They're usually not the bottleneck.
Think of it as IT now. We've got new, define, secure, develop, test, deploy. This is your value stream. This is what everybody's building every day. There's no difference in the airport. You still want to measure your value stream, your flow time, your flow load.
So how is that possible? "Don't sell software," Bryon said. But then we talked to him a couple weeks and he said, "Well, maybe give a demo." We're not giving a demo. We can give you a demo later. But this is Viz, what we're talking about is Planview Viz. These are the same metrics we just talked about. Flow time, how long does it take; flow velocity, how much is produced over time; flow load, your WIP, your work in progress, how much stuff have you said yes to but you haven't finished yet; the flow efficiency; and the flow distribution. Same as the airport. It's funny how that works.
What happens when you start looking at the metrics? If you start looking at the metrics, one of the things that first always pops out is bottlenecks or WIP. They've got 10 months worth of work in this one step, one of the second steps in this process. They've got 10 months worth of work. Another team who's at the far end can go off and do another thing for 10 months because they're not getting any more work done until it gets to them. So knowing your metrics.
The visibility to find the root causes of the slowdowns. Work is slowing down at that group level, but another group is overloaded. Team is the resolution, so we're putting more work there. So without the metrics, you don't know where to spend your time, you don't know how to rearrange your people, you don't know how to add more people, take people away. What happens with this one is before they looked at their metrics, they had a 47 day flow time. 41 or 42 of those days were wait states. That's when waiting for development, waiting for release, waiting for testing, waiting for approval, waiting for Congress to give you money. Whatever it is, you're waiting.
Once they saw where the bottlenecks were, they were able to get rid of some of those bottlenecks, speed up the wait states, and they were able to knock it down from 47 days to an 18 day cycle. If you look, what's really funny is the active time doubled. They spent more time working on it because they were getting more work. So they were able to just focus on it and work on it for five days total instead of 10 days. But the flow time, the overall time for the value stream went down. Same thing. We could go on with these all day. I don't know. I'm going to keep going. Good?
You're good.
We're good. It's small numbers, people. It's really funny. You've got huge projects, lots of people, lots of money going through things. This is saying 10% change. If you make 1% change,, 2%change, if you've got thousands of developers, you've got thousands of things you're working on, a 1% change is going to save you a lot of time and a lot of money. That's exactly what this slide is saying. You don't have to make everything happen in a day. You still have a lot of value going through your process. But if you improve it a little bit. But you can't improve it unless you see the metrics. That was my 40 slides in 10 minutes. I'm going to give Jim the last five minutes.
Thank you, Dan.
Well, any questions? We don't care about him.
Does it all make sense so far? Yes? No? No? Again, I think one of the things that Dan mentioned, it's because just changing some of the processes can make a tremendous amount of value. It could be millions and millions of dollars. It can be, as you just said, this one. These are actual examples of customers who've embraced flow and embraced the flow metrics. They use them in all their PI planning sessions, they use them as they plan on how they're going to do their work. This organization, which is a financial services organization, they were able to improve their throughput seven to 20 features per month. These are real numbers. These make differences. When you talk about taking forever, a new threat comes out for the Air Force and they need to get something out quicker. If you can do these things 185% faster than you were doing them before, they make really, really measurable differences. These aren't just little numbers that we're talking about, especially when we talk about 85% of wait time is spent wasted. 103% efficiency improvement; time-to-market, 26 to 15 days.
These are really strong. We see these again and again with different organizations. This is rebuilding trust between business and technology. This one specifically was about, we don't believe you when you say you're going to deliver that in two months. Once they started working together and be able to look at the information and share the information with the business, and we've got the metrics that Dan talked about, they're very basic and straightforward, they can be understood. They agree on the value that they're going to deliver for that. Now we can start to see, okay, we can work with you. We know where we want to invest to improve this. 70% decrease in flow time, the time it takes to deliver something. 15% flow velocity, how much stuff we're saving, and big cost savings. Again, that's only for one product value stream that they were saving that $6 million on. Imagine if you have 10, 20, 30, 50 digital product value streams.
Again, we could go through a couple of more. We're just about running out of time. But again, the point of these to show is it's not just small numbers that you're looking to improve. It can make a transformational difference in your business.
I had mentioned earlier the book Project To Product. As Dan had mentioned, we then went and built the product, so we have a product that helps you be able to have that analytics to measure flow, give you those metrics, give you insights into how to do that. For the DOD, we have it hosted with our partner, Second Front. If you get a chance, Second Front has a booth here. Our solution is hosted there, so you have the ability to use our solution to measure flow. You can scan it if you can get it here, but at the booth, there's a little placard, I guess, that has the barcode. And if you go there, you have the opportunity to download and get a copy of the book Project To Product if you get a chance. We got one minute. Any questions? All right. Thank you very much.
Thank you.
