Frenesí vs. flujo: lecciones sobre transformaciones basadas en valores

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: ... una transformación de producto, ya sabe, cualquier tipo de transformación de DevOps. He encontrado mucho más éxito en la resolución de problemas en lugar de hacer enormes transformaciones, ya sabes, impactemos todo. Vamos a conseguir algunos datos, cualitativos, cuantitativos, sin embargo podemos obtenerlo. Identifiquemos un problema, pongamos a las personas adecuadas para intercambiar ideas sobre soluciones, ejecutar algunos experimentos, recopilar más datos, ¿lo resolvimos? ¿Cuál es el siguiente problema? ¿Tenemos que seguir trabajando en este. Y eso tiende a crear un tirón para todos estos cambios. Si involucras a la gente en, podemos identificar, sí, esto es un problema, todos queremos resolverlo, ¿cómo podemos hacer eso? La gente se pone tirando del cambio, y no es empujado sobre ellos, y por lo tanto generalmente se mantiene más tiempo, y menos fatiga de transformación para que se ponga ahí también.

Clinton: Entonces, lo que se me viene a la mente es, quién en la empresa... porque de nuevo, tus conversaciones están de plano en conversaciones empresariales. Y si aún no es del todo un emprendimiento, es una empresa en crecimiento en una trayectoria para ser, para ser a nivel empresarial, por así decirlo. Entonces, a ese tipo de escala. Sin embargo, ¿quién es el dueño de esto? Porque tienes todos estos feudos de los que estamos hablando, ¿verdad? Es posible que tenga un director de producto, el CIO que se ocupa de todo Agile, ya sabe, DevSecOps. Y tal vez un Chief Technology Officer, está obteniendo su CSO Suite. Es esto, ¿esto comienza a crear nuevas vías para, como, lo que un Chief Operating Officer debería estar haciendo? O, ¿lo estás viendo en tus conversaciones, hay otros líderes gravitando hacia este dicho “Ooh, esto es importante, tengo que sortear esto y tomar posesión de esto?”

Danny: Entonces, de nuevo, soy bastante pragmático, y soy un gran fan de empezar en algún lugar e ir a todas partes. ¿Verdad? Entonces, hay un... no creo, en la mayoría de las empresas, hay alguien que ya tiene esta visión y están tratando de conseguirlo. En general, esta es una visión que está surgiendo en el mercado. Cada compañía está averiguando su propia manera de hacerlo. Si vuelvo a mi ejemplo de fabricación, si todo lo que puedo ver es parte de ese proceso, déjeme hacerlo lo más eficiente posible e intente detectar en sentido ascendente y descendente dónde podrían estar los problemas y, ya sabe, puede que tenga datos, puede que no tenga datos, pero puede ir a obtener datos. Puedes caminar río arriba y abajo y hablar con la gente a través de eso. Y así, lo que veré a menudo, Clinton, es que generalmente alguien, un Chief Digital Officer, Chief Information Officer, está sintiendo presión para mejorar, pero también sabe que han hecho mejoras, han mejorado las cosas y ya no son el principal cuello de botella. Y entonces están comenzando a tratar de construir un caso para mejorar las cosas antes o aguas abajo de su función particular. Y entonces, eso es básicamente una conversación que se desarrolla, comencemos a mirar el flujo a través, obtengamos datos donde podamos. Y comenzar a tener esas conversaciones con nuestros socios de la organización. Ahora, en última instancia, creo que la persona más adecuada para poseer este tipo de flujo, este tipo de discusión, es la persona que posee las P&L para ese negocio en particular, o si no tienes líneas de negocio es solo una compañía, esa compañía. Entonces, en general, idealmente, alguien como un gerente general, o tal vez un CFO o CEO, alguien así, que esté en apuros para entregar valor. Están en el mejor lugar para decir: “Oye”, ya sabes, “puedo ayudar a ser dueño de la inversión, sé cuál es mi sobre para eso, cuánto tengo para hacer inversiones en esto, y quiero sacar el mayor valor que pueda de ello”. Entonces, ahora déjame... déjame realmente hacer eso. Entonces, similar a nuestro ejemplo de cafetería, la mejor persona para mejorar el flujo ahí es el dueño de la cafetería, ¿verdad? Como que, en última instancia, son responsables de eso. Y creo que veremos en los años venideros que esa mentalidad comienza a permear cada vez más esos roles. Estoy empezando a ver ese cambio en la industria, donde más CFO, más CEOs están pensando en el flujo de valor, pensando menos en las partes dispares. Y entonces yo... creo que esa será una capacidad en la que veremos crecer a nuestros líderes en los años venideros.

Clinton: Me encanta. Y mencionaste antes, también, la frase de, como, fatiga de transformación, ¿verdad? Y creo que eso es, gente, escuchas eso, sientes eso, es... lo sabes cuando lo sientes, lo sabes cuando ves... como, es solo, puede deprimir el cuerpo muy rápido, ¿verdad? Es como, estás de vuelta dentro de algo enorme, alguien viene con una nueva carta. Vamos a hacerlo de otra manera. La promesa para todos los... la olla de oro al final del arcoíris, y hay fatiga legítima a nivel empresarial, porque... sobre todo, ya sabes, metodologías Agile. Ahora estamos viendo empresas que, que están en su tercera o cuarta transformación Agile, y están comenzando otra transformación de producto, iniciando otro esfuerzo a gran escala de esa manera. Y tienes a alguien que podría haber estado con la organización, ya sabes, diez años, doce años, es casi como conseguir otro, si es una analogía o metáfora futbolística, conseguir un nuevo coordinador ofensivo. “Vamos a ejecutar un nuevo libro de jugadas, esta vez va a ser mejor, te lo prometo”. Bien, eso no funcionó. Dos años después, despedir a alguien, traer un nuevo coordinador ofensivo. “¡Vamos a ejecutar un nuevo libro de jugadas! Te prometo que va a ser mejor”. Y los resultados netos son, en la metáfora, que no están ganando Super Bowls, y tal vez son un equipo intermedio. Y hay muchas frustraciones, pierden a su mejor gente. Entonces, cómo... si tienes a la empresa a punto de hacer la quinta transformación, si estamos diciendo que hicieron la tercera o cuarta, ¿qué les estás diciendo? ¿Cómo van a evitar esa quinta transformación, y evitar eso, la fatiga de la que estamos hablando? Y en cambio, ¿hacer algunas cosas de manera diferente? ¿Por qué esa fatiga ocurre tan a menudo?

Danny: Si. Entonces, tal vez rebobinando un poco, voy a decir algo un tanto polémico. Pero, creo, con solo haber visto esto durante décadas, creo que en algún lugar alrededor del 2015, más o menos un par de años, siento que Agile perdió el rumbo. Y se convirtió mucho más en implementar un proceso que en resolver problemas. Sabes, creo que en los primeros días, la infancia de Agile, era como, vamos a resolver problemas, aquí hay algunos patrones que hemos visto que son exitosos, ¿qué ideas tienes? ¿Cómo los mordearía y aplicaría esos en un nuevo contexto? Y en algún lugar... para mí, lo noté alrededor del 2015. Se volvió mucho más sobre a qué tanto me adhiero, ¿elegir tu metodología favorita? Surgieron evaluaciones de madurez, todo se trataba de medir tu adherencia a una metodología. Y la gente, la gente perdió de vista los problemas que intentaban resolver, y simplemente asumió, al implementar una metodología, ya sabes, eso tiene que ayudar de alguna manera, ¿verdad? Creo que eso es lo que creó gran parte de la fatiga de transformación asociada a Agile. Por eso la gente está en su segunda o tercera o cuarta transformación. Porque están pasando por una metodologías diferentes, diferentes, ¿verdad? Empezamos con Spotify, ahora vamos a probar Safe. Y, ya sabes, he escuchado cosas buenas sobre Scrum-at-scale, hagamos esta. Ya sabes, haremos ese para nuestro tercer intento. Creo que hay una tentación para que las organizaciones consultoras simplemente vayan de acuerdo con eso. Es mucho más fácil capacitar a un miembro del personal para, ya sabes, obtener la certificación en una metodología en particular, y simplemente ir a seguir un libro de jugadas e implementarlo. Es mucho más fácil simplemente implementar la metodología sin tener en cuenta que resolver problemas comerciales. Entonces, cuando vayas a hacer eso, elige cualquier metodología, ya sabes, si tuviéramos que anunciar, ya sabes, a todo el grupo Launch mañana, “Hola chicos, ¿adivinen qué? Ahora vamos a hacer lo que sea, ya sabes, escala X, y, ya sabes, tenemos los consultores de escala X que; estarán aquí la próxima semana, y te dirán sobre tu nuevo rol”. Creo que, aunque sea una gran cosa, todo el mundo va a poner los ojos en rollo y decir “¿Por qué me estás forzando esto por la garganta?” Pero en vez de eso, lo que hacemos es decir, oye, queremos mejorar X Y o Z. Vamos a obtener datos sobre eso, hagamos pragmáticamente algunas de esas mejoras, hagamos que las personas adecuadas estén presentes para hacer una lluvia de ideas. Y luego hacemos experimentos. ¿El nuevo proceso que intentamos realmente hizo una mejora o no lo hizo? ¿Qué tanto de una mejora? Y entonces podemos demostrarlo con el tiempo. Y genera impulso, porque la gente ve, ya sabes, no solo estamos implementando sin pensar un marco de trabajo pesado. En realidad estamos resolviendo problemas, los empleados pueden ver que sus vidas mejoran, las cosas fluyen, tengo menos obstrucciones. Y eso es, eso es lo contrario de la fatiga de transformación, ¿verdad? Eso crea un tirón para la transformación y el cambio. Um, entonces, creo, alrededor de 2015, y aún hasta el día de hoy en un grado mayor de lo que me gustaría, muchas de estas transformaciones tienen que ver con la adopción de procesos. No se trata de resolver problemas. Si podemos cambiar esa conversación, aclarar los problemas que estamos tratando de resolver, obtener datos sobre esos problemas, ¿qué tan sistémicos son? Consiga el grupo adecuado de personas para intercambiar ideas sobre soluciones. Y luego me gusta tratar las mejoras como experimentos. Ya sabes, a ver si va a funcionar. Eso deja la puerta abierta para que no sea el cambio final jamás. Podemos, podemos hacer pequeñas mejoras, ver cómo les va. Y luego pivote sobre eso. Es mucho menos fatiga de transformación, y mucho más sostenible, también.

Clinton: Me parece similar a algunas de las cosas donde, la educación ha tenido algunos éxitos en los últimos, digamos, 20, 30 años, donde las cosas se han vuelto así, “enseñar a la prueba”.

Danny: Si.

Clinton: Tenemos estas pruebas estandarizadas, ellos gobiernan todas, tenemos que enseñarles a estas pruebas. Mientras tanto, potencialmente, lo mejor que se puede hacer es enseñar y facilitar el pensamiento crítico para que las personas puedan ser pensadores independientes, realmente entender la resolución de problemas, ya sea en TI o simplemente en general en la educación. Pero en lugar de eso, realmente nos hemos centrado en: “Tenemos que conseguir X cantidad de personas por encima de algún nivel arbitrario para que llegue un mecanismo de financiamiento”. Y es perverso. No es la manera correcta, en mi opinión, de darle a la gente las habilidades críticas, a los jóvenes las habilidades críticas, de realmente desafiarse a sí mismos, y adaptarse, y luego crecer de cierta manera, versus memorizar a una prueba. Entonces, todo de lo que estás hablando, a partir de 2015, casi se siente así. Como, oye, si puedes demostrar que haces estas cosas didácticamente de la manera en que decimos que las hacemos, entonces por golly, estás certificado de esta manera, de esta manera y de esta manera, y por lo tanto eres un experto. Versus la aplicación real de la mentalidad para ir a resolver problemas de negocios. Y por qué en primer lugar fue una buena idea, allá por el 2001, porque era más eficiente. Entonces, sería genial invertir eso, y creo que la mentalidad de VSM y de proyecto a producto vuelve a, fundamentalmente, creo, cuál era el propósito, lo cual es bastante genial. Así que es una bonita historia de regreso de esa manera, ¿verdad? Entonces, todo esto parece bastante lógico. Sin embargo, las organizaciones pueden dudar mucho en abordarlo. Así que más o menos, ¿qué da?

‍Danny: Si. Entonces, creo, ya sabes, de lo que hablabas, incluso con la educación. Enseñar a alguien a pensar es mucho más difícil que enseñarle cuál es la respuesta que necesita producir en una prueba.

Clinton: Derecha.

Danny: Enseñar a alguien a pensar, como, eso va a requerir un trasfondo bastante amplio. Ya sabes, has visto algunas situaciones similares, y has visto lo que funciona y lo que no funciona, tienes algo de experiencia. Y la experiencia realmente se gana a lo largo de los años. Y así, no es tan rápido fabricar entidades facturables en forma de consultores para venir a hacer la cosa, ¿verdad? Es como, estas cosas tienen que ser acuñadas con el tiempo. No solo vas a cuatro días de entrenamiento y boom, ahora te decretan certificado y te vas a empezar a facturar.

Clinton: Derecha.

Danny: Entonces, entonces creo... muchos de los grupos de consultoría por ahí están manteniendo el status quo y puedes rampar muy rápido. En consecuencia, creo que muchos esfuerzos de marketing son para ese fin. Ya sabes, implementa, llena tu metodología en blanco y consigue estas victorias. Y así la metodología se convierte en el foco, y entonces los clientes están pidiendo la metodología. Y así, entonces en realidad se necesita un poco de esfuerzo para no solo decir que sí a lo que están pidiendo. Ya sabes, para redirigirlos y decir “Oye, podemos implementar la metodología, elige la que más te guste. Pero en realidad podríamos resolver sus problemas de negocio con esa metodología, o partes de ella. ¿Consideraría eso?” Entonces es un poco más fácil decir que sí a la solicitud de los clientes de hacer, ya sabes, algo mecánico que se pueda entregar con un alto margen de ganancia, que realmente redirigir y decir “Oye, déjame... déjame hacer algo que sea aún más valioso para ti, va a producir un cambio más sostenido”. Entonces, en su conjunto, creo que, a medida que más y más organizaciones están en su tercera o cuarta transformación Agile, se van a quedar sin metodologías en algún momento de todos modos y simplemente se van a poner pragmáticas y empezar a resolver problemas. Lo cual, tal vez esa es la forma en que esto se marca el comienzo de la nueva era. Pero también pienso, la gente está empezando a reconocer eso. Ya sabes, tal vez, tal vez... lo han reconocido y ahora están empezando a ser más vocales. Pero estamos viendo este cambio de la implementación de la metodología a la entrega de valor, y de hecho, empecemos por algo mucho más valioso para nuestra organización que la simple adherencia o adopción de procesos. Entonces, creo que va a pasar, pero hay... hay toda una economía alrededor de esto, creo que 60 millones de dólares al año se vertieron en transformaciones Agile en todo el mundo. Así que definitivamente hay una gravedad en: “No estropees mis ganancias”.

Clinton: Si. Y creo que cuando teníamos ideas más grandes, de trazo más grande como esta que estamos discutiendo, puede ser difícil para... la gente puede decir “Ooh, realmente me gusta lo que se está discutiendo”, y el sentido de la espiga podría ser hormigueo, como “Ooh, ese soy yo. Están describiendo mi organización o problemas que estoy teniendo”. Y sin embargo, siempre hay ese deseo de, el deseo de entender, bien, bueno, pero, sí, pero, yo no... ¿qué puedo hacer? Como, ¿qué es una primera cosa realmente formidable que no es todo el elefante sino que hace rodar la pelota potencial, o une a la gente, para pensar críticamente sobre este problema de una manera nueva? Entonces, si alguien está en ese estado, ese estado emocionado, ¿qué recomendaría que hicieran para comenzar realmente?

Danny: Si. Entonces, creo que lo primero es que estás identificando algún tipo de problema que ves en tu mundo, algo que necesita cambiar. ¿Verdad? Y todos los tenemos. Están al alcance de las armas. “Si yo fuera el líder, cambiaría esto o aquello”, ¿verdad? Entonces comienzas a identificar eso, y luego necesitas recopilar información sobre eso. Ya sea que se trate solo de datos que está recopilando manualmente, o que esté teniendo conversaciones, entrevistas o que pueda recopilar datos automáticamente sobre, ya sabe, este proceso, aquí está la línea de base actual, aquí es donde están los problemas, déjeme obtener transparencia en torno a eso. Y luego, sea lo que sea que quieras mejorar, basta con atarlo a tus metas organizacionales. Ya sabes, si tu organización es, ya sabes, lo que sea, queremos mejorar la rentabilidad, o disminuir el costo por función, ya sabes, correr de manera más eficiente, mostrar cómo lo que sea que quieras mejorar va a estar ligado a sus objetivos, y luego simplemente, ya sabes, tratar de obtener permiso para hacer una pequeña mejora. Creo que ahí es donde nosotros, vemos que empezar en alguna parte e ir a todas partes. Encuentra una pequeña victoria, ya sabes, incluso si solo es rodar un guijarro cuesta abajo de todas las cosas que necesitan cambiar. Encuentra esa pequeña victoria que está dentro de tu área de control y comienza a generar impulso. Pon a tus sentimientos fuera por otros problemas que podrían ser un problema mayor, y luego toma esa misma victoria que has tenido y construye sobre ella. Continuar generando impulso. Y creo que así es como terminas pasando y terminando en tu organización a tiempo.

Clinton: Sí, creo que la... la capacidad de continuar, seguir pintando una visión audaz de lo que puede suceder, y ser pragmático sobre “Bien, hay un paso que podemos dar para que ese impulso se ponga en marcha”. Hablamos, digo mucho, digo, hablo bastante en este podcast, de que la gente siempre dice que quiere actuar como una startup, quiere actuar como una startup. Y es como, genial. Hay ciertas cosas que son realmente geniales en una startup que todos envidiamos y queremos hacer, en cuanto a la velocidad. Y luego, para efectuar un cambio significativo dentro de una empresa, hay... tienes, tienes que construir ese impulso, tienes que conseguir la gravedad a tu favor. Y como, entonces el guijarro rodando cuesta abajo es la gran metáfora de eso. Entonces, entonces, un gran consejo durante todo el camino, Danny. Es un lindo, me encanta, me encanta cómo evolucionó la conversación, y es... donde empieza con la historia, y ahora, creo, mentalmente, estamos en este estado a nivel de dron donde estamos viendo todo este paisaje. Y viéndolo como, como un ecosistema que fluye. Y me encanta esa idea de que oye, podrías tener tu función, tu feudo, ser tan bueno como va a ser, ser extremadamente, extremadamente eficiente. Eso es genial, y es para celebrarlo. Y si lo haces, si estás ahí o estás cerca de ahí, pues entonces creo que ese es el codazo para que digas, bien. Es el sistema de alguien más que yo no controlo de manera innata, si quieres, ahora mismo. Pero tengo que ir a llamar a las puertas y juntar a todos. Como, bien. Tenemos sistemas siloados bastante buenos, ese es un estado bastante maduro para la empresa moderna. Ahora bien, ¿cómo los unimos para que realmente actúen como un solo sistema? Ahí es donde podemos ayudar a la gente a esforzarse. Entonces, Danny, fue realmente un placer tenerte en Catalyst hoy. Danny, ¿dónde puede encontrarte la gente? ¿LinkedIn es mejor, Twitter es mejor? ¿Cuál es tu, cuál es tu placer?

Danny: Sí, LinkedIn es genial, es Daniel Presten, P-r-e-s-t-e-N, diez como el número diez. Si tecleas eso en LinkedIn y ves a alguien con ese apellido, están relacionados conmigo de alguna manera, soy la versión de Daniel Presten de esa lista.

Clinton: Agradable, bonito. El verdadero Danny Presten. Bien, entonces...

Danny: (Risas)

Clinton: Ese es Danny Presten, el metodólogo jefe de administración de flujo de valor y transformación de proyecto a producto aquí con nosotros en Launch by NTT Data. Y te agradecemos mucho por unirte hoy a nosotros. Porque en este estudio, creemos en el envío de software sobre slideware, que rápido seguirá sin problemas, y apuntar a crear experiencias digitales que muevan millones es una búsqueda muy digna. Únase a nosotros la próxima vez mientras la búsqueda continúa en Catalyst, el podcast Launch by NTT Data.

[CATALIZADOR DE MÚSICA DE OTRO]