Clinton Bonner: Don’t mistake activity for progress.

Danny Presten: Right.

Clinton: Right? So, when you describe that organization that is a mile wide but an inch deep, that just screams to me, yeah, they can do lots of activity, but they suffer to get things done.

[CATALYST INTRO MUSIC]

Clinton: Welcome to Catalyst, the Launch by NTT Data podcast. I’m your host Clinton Bonner. Remember to, of course, get out there and subscribe wherever you got yours… it’s on every platform, we know these things already. Catalyst is an ongoing discussion for digital leaders dissatisfied with the status quo, and yet very optimistic about what’s possible through smart technology and really great people. Today we’ve got a great guest, who is… he has an acute understanding of, why do these digital leaders, why are they so dissatisfied? Where, on the enterprise level, you know, the go-to-market schemes and motions - where do things break down? Why do they break down? And most importantly, how do we fix it? So, I’m joined by Danny Presten. He is the chief methodologist of value stream management and project-to-product transformation for our team at Launch by NTT Data. He has many, many years of expertise in this particular topic. A very engaging gentleman, Mr. Danny Presten. Welcome to the studio, how are you doing today?

Danny: Hey, doing great! Thanks so much for the invitation, great to be here.

Clinton: Yeah, no, we’re going to have some fun. And this is a fun topic. What I like about it is that, it’s like an ogre, which is like an onion, there’s lots of layers to peel through. So let us, let us dive right into it. So, you’ve got a lot, a lot of experience with Agile methodologies. Agile itself now has been, what, 22, 23 years in the making? It’s been around the block for a while. And, over time, things have changed. So, what are you seeing in terms of the changing of Agile, how it’s seen? And what are the problems that Agile is kind of being used for? Like, what’s happening now with Agile?

Danny: Yeah, so, um… so just maybe, a little bit about, about myself, there, kind of some background. I’ve been in, doing Agile transformations since around 2007, right around in there. And prior to that, I was an industrial engineer, I worked a lot in manufacturing, distribution, places like that, helping to improve flow through the organization. So when I found Agile in the software world, it was like I was coming back home. There was some very familiar stuff there as far as lean process improvements. Through the years I’ve had a chance to work at a variety of companies. Digital.AI, who does the State of Agile survey, I’ve had a chance to contribute to that for several years, as well as Tasktop. Mik Kirsten is, was the CEO of Tasktop, who wrote the book Project to Product, so I’ve been on the front lines of a lot of these big changes coming in over the past 20-plus years. And the interesting thing is that, the goals that people set out to achieve in 2010 are the same goals that they’re trying to achieve today. As a matter of fact, one of the challenges on the State of Agile survey that we ran annually was that oftentimes, things didn’t change on that survey. There wasn’t, you know, a new story to tell year over year. It was like, “Hey, we’re still trying to get these goals, these are still the blockers to those goals.” So yeah. As a whole, the goals have been the same, I think, since the early days. Trying to improve flow through the organization and speed to market, basically trying to keep employees happy, have an environment that inspires creativity and is a solid culture that can kind of unlock people’s intrinsic motivation. All those things have been desires for a number of years. The way that we’ve gone about achieving them has changed over time, and I think that’s the part that’s begun to morph, maybe the more interesting story there. So, you know, rewinding all the way back to 2001, you know, we’ve got team-level Agile. You know, let’s do scrum, there’s a single product owner with a team that can deliver, you know, working-tested software, independent. You know, a small group of seven to ten people. Over the years, they realized, “Hey, you know, we’re able to produce good software quickly, but we can’t get it into production.” And so, shortly after you see the Agile Manifesto, 2001. Around 2009 you see DevOps emerge, where, you know, we need tighter collaboration between development and operations, we’ve gotta really get faster, and keep those operations. As that began to see benefits, you see a focus on scaling emerge, so a lot of scaling frameworks came up through that time. Scaled Agile Framework, the most popular of those, introduced in 2011. There’s others. Nexus, Scrum@Scale, Less, etc. So a lot of these scaling methodologies. And what they realized was, you know, yes, we can produce working-tested software quickly when it’s a single team with no dependencies and we have operations involved, but at bigger companies that were adopting Agile methodology at that time, they truly didn’t have a single team that could produce that software. So, they realized, we’ve gotta figure out some ways to scale. As that began to take shape, you see the conversation emerge even further. So, instead of just many development teams and operations, now we have DevSecOps as a term…

Clinton: Mhm.

Danny: …pop up in, like, 2015, you start hearing that term. And you start to realize, this is a bigger organizational collaboration. We’ve got a lot of different people that are part of this value stream. And so, an old, old industrial engineering concept, value-stream management, they’ve been using that in auto manufacturing since the ‘40s, they began to say “Well, software’s kind of like that.” We’re not manufacturing hard stuff, we’re manufacturing code, but it still flows through a value stream, and there’s a path from concept to productive use. So, value-stream management really came on the scene… you start hearing mentions of it in 2013, but much more as you roll past 2015, 2017. And it becomes a key focus, a lot of organizations looking at that. Gartner Forrester picked up that on their wave and magic quadrant, you start seeing value-stream management tools emerge. And as you look at value-stream management, it’s really telling you how stuff’s flowing in your org. Where the bottlenecks might be, what’s our… what are the very slow metrics, you know, or flow of loss to efficiency, etc.? People said, okay, well now we need to address these system issues. And that’s where business agility, project-to-product, those kinds of disciplines say, let’s actually look beyond just development, entire concept to cash. How do we organize to inspire flow, to allow flow? So that’s… that’s, again, same kind of problem we’re solving for way back in 2001, we want to be faster, we want to be able to pivot to the highest-value things. But now we’re… we’re exploring even bigger parts of the organization more comprehensively to get there. So a lot of good stuff happening in that. And then, I think, real recently, kind of very very beginnings, is we’re starting to see AI be able to inform not only more insights on where my bottlenecks in the organization are, but even better, where my opportunities are to get the higher-value stuff to market. Of all the things in my backlog, what has the greatest potential to generate value to my customers? And so, that’ll be a really cool thing to watch grow over time. And hopefully, again… all these are, they’re solving for the same problems, right? I want speed to value, I want to increase value for customers, I want to do it in a way that unlocks the intrinsic motivation of my employees, and we’re just having different, different tools in the toolkit to solve that same problem.

Clinton: Yeah, and I think it’s a great history you ran through there, Danny. And of course, ending, if you will, with the advent of AI, what it can do. And I love, I love that… the part of AI you focused on was, hey, it can help you go focus on the most valuable things to go do. So it’s not just about, “Hey, use AI to, or use automations and AI to do the low-value things.” Like, no no no. AI can help us go detect the high-value things. And then figure out ways that, to value-stream to them, right? So you get, you get more of the good stuff, right? Which is really interesting. And I think the history you gave, too, was, it’s like, hey. It started, it started at a, maybe, whatever, a 5,000-foot level. Then it was like, ooh, the bottlenecks might actually need to be seen at 20,000 feet. Like, ooh, the bottlenecks might be even, a little bit, a smidgen higher, actually, at 50,000 feet, because the bottlenecks could actually happen in different parts of the organization, maybe not just… maybe not just in I.T. So if you have a team that is, you know, they’re truly doing Agile well, they’re doing DevOps… like, specifically, why isn’t that enough?

Danny: Yeah. Well, I think that’s a great, a great question. And again, there’s a lot of orgs that are making significant investments and, you know, how can… how can we be more agile in our software delivery? How can we automate various parts of our delivery pipeline to get code to production faster? But I’m starting to see where we’ve been working at that for a number of years, and so it’s not really necessarily the primary bottleneck anymore.

Clinton: Mhm.

Danny: It might be the one thing that you’re measuring, so it’s the only thing you can see, but they’re… the real bottleneck might be upstream or downstream of that. And I love… Gene Kim in Phoenix Project, you know, he writes that if you’re improving something that’s not the bottleneck, your improvement’s an illusion. And it’s like, you know, it’s almost like, wow, if I… if I’m trying to, you know, do something simple. Get a cup of coffee at my local coffee shop. And I want to make that process faster, so I, you know, dig in, I’m going to make the cash register experience faster and faster and faster so it goes from, you know, a minute counting cash to now, you can just tap your card, and 15 seconds later I’m done with my transaction… I’m only looking at part of that value stream. And if the barista, which is generally the bottleneck at my local coffee shop, if they’re… if they’re still, you know, not getting improvements in their area, or not even looking at that area, it might actually mean that I’m ringing up people at a rate much, much faster than I used to, and I’m making my issue on the barista even worse. And so, while improving one part of the value stream without a view to the whole, I might actually slow myself down. And so, that’s where I think Agile and DevOps is a great place to start, you know, software… development software manufacturing and software delivery in the form of DevOps, great place to start, but I’ve seen some things… like, here’s an example, Clinton, where I was working with a company, and they were able to produce working-tested software, toggled off, in production, in two to four weeks. You know, a spread or two, they can get something cool into production. But they had to wait on the marketing department to do cool, you know, all the materials and the campaign and all that kind of stuff before they were allowed to toggle it on. So, you’d have working-tested code that could be deployed very, you know, decently rapidly.

Clinton: Yeah.

‍Danny: Every couple weeks. But it would wait three months-plus, toggled off in production, before it could ever see productive use, because the marketing department needed to kind of weigh in on their stuff. So, as a whole, nothing wrong with Agile DevOps, I love it. But you also need to look upstream and downstream of that to see, am I really improving the thing that matters the most? 

Clinton: Danny, that’s a great example. I love, I love the simplification. I love the barista, potentially, as the bottleneck. We love our baristas, and yet, hey, if they’re getting more and more orders and they just can’t facilitate them all, well, then you get a different type of log jam. So…

Danny: Right.

Clinton: And, like you said, it could be worse. In that world, it could end up in more errors and more frustration and more burnout, and then your whole system actually suffers. Meanwhile, you actually optimized the crap out of one part, but you really suffered… but the system suffered, because you weren’t listening, looking at it holistically. And then you gave the great example of the marketing team that just wasn’t ready to go to market when code was flowing out in a really efficient way. So, these things feel like common-sense discussions, but what’s the big obstacle? Why are they so hard to implement and improve at an organizational level?

Danny: Yeah. You know, that’s a great, that’s a great question. I think in most organizations that I’ve worked with, there’s kind of just a gravity toward the status quo.

Clinton: Hm.

Danny: And in general, just a, a resistance to change. And I see a lot of organizations, they change their vernacular. You know, they’ll start using new terms, you know, project-to-product, or different Agile terms, you know, we’re now doing squads and tribes and guilds or whatever it might be. But they don’t change the underlying things that matter most. So in that example, you would need a tighter coupling between your development org and your marketing org. You know, let’s actually, you know, plan stuff together, and make sure that we’re both prepared to deliver it. Maybe couple tighter through the, through the development cycle so the marketing groups looking at demos are able to, to kind of anticipate code being released. But it’s just like, wow, you know, we’ve always done it this way, why do we really need to change? And so, um… there seems to be a worker, you know, people closest to the work, they know what these issues are, they’re struggling with it. But it’s just hard to convince, you know, more strategic leaders in the organization of how significant the issues are, how great the benefits could be if you could change in such a way that they actually make that change.

Clinton: Yeah. Makes sense. So, but then, you know, systemically, what are some examples or the types of issues that you do see quite a bit of? Is, are there patterns that emerge? Are there ones that, like, “Oh yeah, I could call out a couple that I, these happen kind of all the time?” What do you see as systemic issues?

Danny: Yeah. So, almost universally… And, you know, have had the chance to work with companies around the world, so not just localized to our Western culture. But almost universally, I see companies that are organizing for the goal of high utilization, not necessarily high-value delivery. And so, the natural way that that surfaces is through loads and loads of work in process. So, a lot of times organizations are spread a mile wide and an inch deep. They’ve got many, many things in process, so that at any point in time, if there’s a specialized capability that becomes available, they start work on the next new thing and everybody’s busy all the time. But when you look at what they’re actually delivering into productive use, it’s almost a trickle. So, you know, we’re having to run uphill on an icy slope, you know? We’re running very, very fast, and hardly getting progress towards the goal. And I think organizations know that. You know, there’s a general sense of, like, “Yeah, that’s us,” but… but it’s hard to get traction to actually change. And so, one of the things that I’ve seen that has been extremely helpful, just the past two, three years, there’s a new category of tools that’s emerged called value-stream management tools. And they’re approximating what I used to be able to do when I was an industrial engineer. Right? You know, back in those days I’d come into a manufacturing plant, you can kinda picture it in your head, you know, there’s all kinds of unassembled things coming in the front of the manufacturing plant, you know, screws, whatever it takes to develop the thing you’re developing. Those get pieced together bit by bit on an assembly line, and eventually they exit, you know, in a box onto a tractor-trailer outside that. When I used to walk into those and, you know, “Hey, we’ve gotta improve flow, we’ve gotta improve efficiency,” I could kinda walk around and see where stuff was piling up. It didn’t take a lot of intuition to understand where the issues were.

‍Clinton: Right.

Danny: I could kinda be there for a day or two and figure it out. Software world that’s always been a challenge. Until recently. We’re starting to begin to get some of those same views as we sit on top of the Agile life-cycle management tools, the DevOps tools. So we’re able to begin to see the whole story of what it took to develop that code, and… you know, if we start to pull in similar, the marketing tools, Asana or whatever it might be. Now we can start to see an end-to-end picture of where work is flowing, where it’s living, and where it might be piling up. And I’ve seen, Clint, I’ve seen progress for the first time in a long time. We’re now, when we show, hey, you’ve got too much WIP and you’re also impacting your ability to deliver, just having that visual has finally started to uncork some of these things and make progress where there’s just been systemic issues for, for decades, really. So, so a lot of cool stuff coming in market now.

Clinton: That reminds me, so, Nate Spillson, who is the VP of engineering at Launch by NTT Data, he gave a great talk at our Nexus event, which is our flagship event, when we hosted it in late April of this year, 2023. And one of his kind of big bullets was, don’t mistake activity for progress. 

Danny: Right.

Clinton: Right? So, when you describe that organization that is a mile wide but an inch deep, that just screams to me, yeah, they’ve got… they can do lots of activity, but they suffer to get things done. Things do not get across the finish line, and you might get 90% of the way there, or you might get done eventually, but you didn’t do it holistically, and you didn’t do it with the, the effectiveness that you thought… that we of course all want to when we’re mapping it out in some PowerPoint or some… you know, just some napkin sketch of, what are we going to go try and do? So, that… that definitely rings home for me there, Danny. The pieces that I think are really interesting are, you know, I run a marketing org. I ran UX for a bit in my life as well. And I feel like the individual functions… they can get really good at their stack. Obviously there’s a whole stack of MarTech stack, where you could have your Slack talking to Asana that maybe hooks up to your, if it’s Pardot, into SFDC world. And you could create all these beautiful automations in your own workflows. But again, if you’re not taking that next macro jump up to say, cool, now how does that tie to I.T. and how they’re… their deployment cadence? You’re, again, it’s… you’re shifting bottlenecks, is what you end up doing, right? So, when we look at this from a more macro perspective, how far does it go out, organizationally? ‘Cause it’s clearly more than just I.T.?

Danny: Yeah. Yeah, and I think, just kind of riffing off the first part of that, if you… so often, we, you know, you can’t help but look at the world through your own perspective. Right? My own department, my own team, my function in the organization. And we try to make our part of it very, very efficient. I think a, maybe a more powerful way to look at that is from the unit of values perspective. Like, what’s life like for the story? What’s life like for the epic or the feature that we’re delivering into production? And what you’ll often see in, you know, when I’m looking at it from my perspective, I’m a piece of the value stream, I’m busy all the time, I’m doing good stuff, I’m out there hammering away and I’m making my stuff very efficient. Where there’s problems it’s not on my team. Like, generally you’ll see organizations that have been doing scrum or Kanban for a handful of months, they’ll get to that place where their biggest problems are outside of themselves. If we start to look at it from the vantage point of that story, you know, what is this unit of value and how is it getting to the customer? You start to see a lot of gaps. It’s very common in organizations to have a very low efficiency, if you compare the value-add time, like the time someone’s actively working on that story or that feature, compared to the time the story’s waiting for a dependent team to pick up that work, or something. You’ll see things like, 20% flow efficiency’s very common. Maybe as good as 40% flow efficiency at other orgs. So there’s a lot of opportunity to improve the flow of value of that thing. Now, in manufacturing, we would never measure a workstation’s efficiency, right?

Clinton: Hm.

Danny: We’re measuring the efficiency of manufacturing the product. We’re generally looking at it from that view - what, how are we doing at building my product? But in software, you know, I, we… I think it’s easy just to stay a little bit more siloed because it’s harder to get that view. So again, that’s where some of those things will go. So, how far do you go? Well, I tell you, it’s… it’s an organizational transformation. So you start somewhere, but you eventually go everywhere. One of the first things that you’ll see organizations bump into as you’re beginning to improve your ability to deliver software - the funding models and things like that become your primary blockers. So, so that your… you know, if you’re funding projects or funding little discrete pieces of scope, I see it oftentimes taking 40% of that scope’s life cycle just getting funding approved for it. 

Clinton: Mm.

Danny: So, from an end-to-end, you know, taking it from that perspective, there’s a lot of improvements to be made there. Changing PMOs to value management offices. And I think there’s still value in that oversight function, but we’re providing oversight to delivering value instead of just the execution of scope. Basically, what you’ll find is that the whole, it requires an organizational shift. You can’t do that all on day one, right? This is a gradual progression. And to me, the way I like to do that is, getting as much visibility as I can into the overall delivery chain, whether that’s automated through some of these value-stream management tools, or manually collected through interviews, surveys, other means of collecting data. Pulling that picture together, solving for the primary bottleneck, seeing what it does to your flow, find the next bottleneck and do that, solve for that. So you don’t have to change everything at once. Change the things that you need to to make your flow better at that point in time, a little bit more pragmatic, helps you out. And then that also helps out with transformation fatigue. How many different transformations are going on at any org? There’s usually an Agile transformation…

Clinton: Yeah. Too many, yes.

Danny: …a product transformation, you know, any kind of DevOps transformation. I’ve found a lot more success in solving problems rather than doing huge, you know, let’s-impact-everything transformations. Let’s go get some data, qualitative, quantitative, however we can get it. Let’s identify a problem, let’s get the right people around to brainstorm solutions, to run some experiments, collect more data, did we solve it? What’s the next problem? Do we need to keep working on this one. And that tends to create a pull for all these changes. If you involve people in, we can identify, yes, this is a problem, we all want to solve it, how can we do that? People get pulling the change, and it’s not pushed on them, and therefore it’s generally sustained longer, and less transformation fatigue to get it put in there as well. 

Clinton: So, what’s coming up for me is, who at the enterprise… ‘cause again, your conversations are squarely in enterprise conversations. And if it’s not quite an enterprise yet, it’s a growth company on a trajectory to be, to be enterprise-level, if you will. So, at that kind of scale. Who is owning this, though? Because you have all these fiefdoms we’re talking about, right? You might have a chief product officer, the CIO looking after the whole Agile, you know, DevSecOps. And maybe a Chief Technology Officer, you’re getting your CSO-suite. Is this, does this start to create new avenues for, like, what a Chief Operating Officer ought to be doing? Or, are you seeing it from your conversations, are there other leaders gravitating toward this saying “Ooh, this is important, I’ve gotta get around this and take ownership of this?”

Danny: So, again, I’m pretty pragmatic, and I’m a big fan of start somewhere and go everywhere. Right? So, there’s a… I don’t think, at most companies, there’s somebody who already has this view and they’re trying to get it. Generally, this is a view that’s emerging in the market. Each company’s figuring out their own way to go about doing it. If I go back to my manufacturing example, if all I can see is part of that process, let me make that as efficient as possible, and try to detect upstream and downstream where problems might be, and, you know, you may have data, you may not have data, but you can go get data. You can walk up- and downstream and talk to people through that. And so, what I’ll often see, Clinton, is that generally someone, a Chief Digital Officer, Chief Information Officer, is feeling pressure to improve, but also knows they’ve made improvements, they’ve made things better, and they’re not the primary bottleneck anymore. And so they’re starting to try to build a case for improving things upstream or downstream of their particular role. And so, that’s basically a conversation unfolds, let’s start to look at flow across, let’s get data where we can. And begin to have those conversations with our partners in the organization. Now, ultimately, I think the person best-suited to own this kind of flow, this kind of discussion, is the person who owns the P&L for that particular business, or if you don’t have lines of business it’s just one company, that company. So generally, ideally, someone like a general manager, or maybe CFO or CEO, someone like that, that’s on the hook for delivering value. They’re in the best place to say, “Hey,” you know, “I can help own the investment, I know what my envelope is for that, how much I’ve got to make investments in this, and I want to get the most value out of it that I can.” So, now let me… let me actually go about doing that. So, similar to our coffee shop example, the best person to improve flow there is the owner of the coffee shop, right? Like, they’re ultimately accountable for that. And I think we’ll see in the years to come that that mindset begins to permeate those roles more and more. I’m starting to see that shift in industry, where more CFOs, more CEOs are thinking about the flow of value, thinking less about the disparate parts. And so I… I think that’ll be a capability we’ll see our leaders grow into in the years to come.

Clinton: Love it. And you mentioned earlier, too, the phrase of, like, transformation fatigue, right? And I think that’s, people, you hear that, you feel that, it’s… you know it when you feel it, you know it when you see… like, it’s just, it can depress the body real quickly, right? It’s like, you’re back inside something huge, somebody’s coming in with a new charter. We’re going to do it differently. The promise for all the… the pot of gold at the end of the rainbow, and there is legitimate fatigue at the enterprise level, because… especially, you know, Agile methodologies. Now we’re seeing companies that, that are on their third or their fourth Agile transformation, and they’re starting another product transformation, starting another large-scale effort that way. And you’ve got someone who might have been with the organization, you know, ten years, twelve years, it’s almost like getting another, if it’s a football analogy or metaphor, getting a new offensive coordinator. “We’re going to run a new playbook, it’ll be better this time, I promise you.” Okay, that didn’t work. Two years later, fire somebody, bring in a new offensive coordinator. “We’re going to run a new playbook! I promise it’ll be better.” And the net results are, in the metaphor, they’re not winning Super Bowls, and maybe they’re a middling team. And there’s lots of frustrations, they lose their best people. So, how… if you’ve got the company on the verge of doing the fifth transformation, if we’re saying they did the third or fourth, what are you saying to them? How are they going to avoid that fifth transformation, and avoid that, the fatigue we’re talking about? And instead, do some things differently? Why is that fatigue happening so often?

Danny: Yeah. So, maybe rewinding a little bit, I’m going to say something somewhat controversial. But, I think, just having watched this for decades, I think somewhere around 2015, give or take a couple years, I feel like Agile lost its way. And it became much more about implementing a process than it was about solving problems. You know, I think in the early days, the infancy of Agile, it was like, let’s solve problems, here are some patterns we’ve seen that are successful, what ideas do you have? How would you morph those and apply those in new context? And somewhere… to me, I noticed it around 2015. It became much more about how much do I adhere to, pick your favorite methodology? Maturity assessments emerged, they were all about measuring your adherence to a methodology. And people, people kinda lost sight of the problems they were trying to solve, and just assumed, by implementing a methodology, you know, that’s gotta help somehow, right? I think that’s what created a lot of the transformation fatigue associated with Agile. That’s why people are on their second or third or fourth transformation. Because they’re going through a different, different methodologies, right? We started out with Spotify, now we’re going to try Safe. And, you know, I’ve heard good things about Scrum-at-Scale, let’s do this one. You know, we’ll do that one for our third try. I think there’s a temptation for consulting organizations to just go along with that. It’s way easier to train a staff member to, you know, get certified in a particular methodology, and just go follow a playbook, and implement that. It’s way easier to just mindlessly implement methodology than it is to solve business problems. So when you go about doing that, pick any methodology, you know, if we were to announce, you know, to all of Launch group tomorrow, “Hey guys, guess what? We’re now going to do, whatever, you know, X scale, and, you know, we’ve got the X scale consultants that;ll be here next week, and they’ll tell you about your new role.” I think, even if it’s a great thing, everybody’s gonna roll their eyes and be like “Why are you forcing this down my throat?” But instead, like, what we do is we say, hey, we want to improve X Y or Z. Let’s get data around that, let’s pragmatically make some of those improvements, let’s get the right people around to brainstorm. And then we run experiments. Did the new process we tried actually make an improvement or did it not? How much of an improvement? And then we can demonstrate that over time. And it builds momentum, ‘cause people see, you know, we’re not just mindlessly implementing a heavy-duty framework. We’re actually solving problems, employees can see their lives getting better, things are flowing, I have less obstructions. And that’s, that’s the opposite of transformation fatigue, right? That creates a pull for transformation and change. Um, so, I think, around 2015, and still to this day to a larger degree than I’d like, a lot of these transformations are about process adoption. They’re not about problem-solving. If we can change that conversation, get clear on the problems we’re trying to solve, get data on those problems, how systemic are they? Get the right group of people around to brainstorm solutions. And then I like to treat the improvements like experiments. You know, let’s see if it’s going to work. That leaves the door open for it not to be the final change ever. We can, we can do small improvements, see how they do. And then pivot on that. It’s a lot less transformation fatigue, and a lot more sustainable, as well.

Clinton: It feels to me similar to some of the things where, education has taken some hits in the last, let’s say, 20, 30 years, where things have become so, “teach to the test.”

Danny: Yeah.

Clinton: We’ve got these standardized tests, they rule all, we’ve gotta teach to these tests. Meanwhile, potentially, the better thing to do is to teach and facilitate critical thinking so that folks can be independent thinkers, really understand problem-solving, whether that’s in I.T. or just generally in education. But instead, we’ve really, really focused on, “We’ve gotta get X amount of people above some arbitrary level so that a funding mechanism comes through.” And it’s perverse. It’s not the right way, in my opinion, to give people the critical skills, young people the critical skills, to really, really challenge themselves, and adapt, and then grow in a certain way, versus memorizing to a test. So, everything you’re talking about, starting in 2015, almost feels that way. Like, hey, if you can prove you do these things didactically the way we say we do them, then by golly, you’re certified this way, this way and this way, and therefore you’re an expert. Versus the actual application of the mentality to go solve business problems. And why in the first place it was a good idea, back in 2001, ‘cause it was more efficient. So, it’d be really cool to invert that, and I do think the VSM and project-to-product mindset gets kind of back to, foundationally, I think, what the purpose was, which is pretty cool. So it’s a nice comeback story in that way, right? So, this all seems pretty logical. Yet, organizations can be very hesitant to approach it. So kind of, what gives? 

‍Danny: Yeah. So, I think, you know, what you were talking about, even with education. Teaching someone how to think is a lot harder than teaching them what the answer is they need to produce on a test.

Clinton: Right.

Danny: Teaching someone how to think, like, that’s going to require a pretty broad background. You know, you’ve seen some situations similar, and you’ve seen what works and what doesn’t work, you’ve got some experience. And experience is really gained over years. And so, it’s not near as quick to manufacture billable entities in the form of consultants to come do the thing, right? It’s like, these things have to be minted over time. You don’t just go to four days of training and boom, now you’re decreed certified and off you go to start billing.

Clinton: Right.

Danny: So, so I think… a lot of the consulting groups out there are keeping the status quo and you can ramp very quickly. As a result, I think a lot of marketing efforts are to that end. You know, implement, fill in your blank methodology and get these wins. And so the methodology becomes the focus, and then the customers are asking for the methodology. And so, so it actually takes some effort to not just say yes to what they’re asking for. You know, to redirect them and say “Hey, we can implement the methodology, pick any one you like. But we could actually solve your business problems with that methodology, or pieces of it. Would you consider that?” So it’s a little easier just to say yes to the customers’ request to do, you know, something mechanical that can be delivered with a high profit margin, than it is to actually redirect and say “Hey, let me… let me do something that’s even more valuable for you, it’ll produce more sustained change.” So, as a whole, I think, as more and more organizations are on their third or fourth Agile transformation, they’re going to run out of methodologies at some point anyway and just get pragmatic and start solving problems. Which, maybe that’s the way that this is ushered in to the new era. But I also think, people are starting to recognize that. You know, maybe, maybe… they’ve recognized it and are now starting to be more vocal. But we’re seeing this shift over from methodology implementation to value delivery, and let’s actually get on the hook for something much more valuable to our organization than just process adherence or adoption. So, I think it’ll happen, but there’s… there’s a whole economy around this, I think 60 million dollars a year poured into Agile transformations around the globe. So there’s definitely a gravity to, “Don’t mess up my profit.” 

Clinton: Yeah. And I think when we had bigger, bigger-stroke ideas like this that we’re discussing, it can be difficult for… people can say “Ooh, I really like what’s being discussed,” and the spidey-sense might be tingling, like “Ooh, that’s me. They’re describing my organization or problems I’m having.” And yet, there’s always that desire to, the desire to understand, okay, well, but, yeah, but, I don’t… what can I do? Like, what’s an actual formidable first thing that isn’t the entire elephant but gets the potential ball rolling, or brings people together, to critically think about this problem in a new way? So, if someone’s kind of in that, that excited state, what would you recommend they do to actually start?

Danny: Yeah. So, I think the first thing is, you’re identifying some kind of a problem that you see in your world, something that needs to change. Right? And we’ve all got those. They’re within arms’ reach. “If I were the leader, I’d change this or that,” right? So you begin to identify that, and then you need to collect information on that. Whether that is just data that you’re collecting manually, or you’re having conversations, interviews, or you can automatically collect data on, you know, this process, here’s the current baseline, here’s where the issues are, let me get transparency around that. And then, whatever it is you want to improve, just tie it to your organizational goals. You know, if your organization is, you know, whatever, we want to improve profitability, or decrease cost per feature, you know, run more efficiently, show how whatever it is you want to improve is going to tie into their goals, and then just, you know, try to get permission to make one small improvement. I think that’s where we, we see that start somewhere and go everywhere. Find a small win, you know, even if it’s just rolling a pebble down the hill of all the things that need to change. Find that small win that’s within your area of control, and begin to build momentum. Put your feelers out for other issues that might be a bigger issue, and then take that same win that you’ve had and build on it. Continue to build momentum. And I think that’s how you end up going through and end on your organization in time. 

Clinton: Yeah, I think the… the ability to continue to, continue to paint a bold vision for what can happen, and be pragmatic about “Okay, there’s a step we can take to get that momentum going.” We talk about, I say a lot, I say, I talk about quite a bit on this podcast, that folks always say they want to act like a startup, they want to act like a startup. And it’s like, cool. There’s certain things that are really great about a startup that we all envy and want to do, velocity-wise. And then, to effect meaningful change within an enterprise, there’s… you’ve got, you’ve gotta build that momentum, you have to get the gravity in your favor. And like, so the pebble rolling downhill is the great metaphor for that. So, so, great advice the whole way through there, Danny. It’s a nice, I love, I love how the conversation evolved, and it… where it starts with the history, and now, I think, mentally, we’re at this like drone-level state where we’re looking at this entire landscape. And seeing it as, as a flowing ecosystem. And I love that idea that hey, you could have your function, your fiefdom, be as good as it’s gonna get, be extremely, extremely efficient. That’s cool, and it’s to be celebrated. And if you do, if you’re there or you’re close to there, well then I think that’s the nudge for you to say, okay. It’s somebody else’s system that I don’t innately control, if you will, right now. But I’ve gotta go knock on the doors and get everybody together. Like, okay. We have pretty good siloed systems, that’s a pretty mature state for the modern enterprise. Now how do we string them together so they actually act as one system? That’s where we can help folks strive through. So, Danny, it was really a pleasure to have you on Catalyst today. Danny, where can folks find you? Is LinkedIn best, is Twitter best? What’s your, what’s your pleasure? 

Danny: Yeah, LinkedIn’s great, it’s Daniel Presten, P-r-e-s-t-e-n, ten like the number ten. If you type that in LinkedIn and you see someone with that last name, they’re related to me somehow, I’m the Daniel Presten version of that list.

Clinton: Nice, nice. The real Danny Presten. Alright, so…

Danny: (Laughs)

Clinton: That is Danny Presten, the chief methodologist of value stream management and project-to-product transformation here with us at Launch by NTT Data. And we thank you very much for joining us today. because in this studio, we believe in shipping software over slideware, that fast will follow smooth, and aiming to create digital experiences that move millions is a very worthy pursuit. Join us next time as the pursuit continues on Catalyst, the Launch by NTT Data podcast. 

[CATALYST OUTRO MUSIC]