EP77 Interview on Why Agile Transformation Fail

John Byrne [00:00:04]:

Welcome back everyone to Business Breaks. I'm John Bourne and today we'll be doing things a little bit differently in that I'll be interviewing Dante Healey. We're talking today about Agile transformations and why they fail. My experience with Agile is, tends to be just as part of a hybrid project. I'm more of a waterfall project type of person. But Dante has plenty of experience with Agile, though he's the much more informed person for answering the questions here. So Dante, just to give us a bit more about your background and how it ties into Agile transformation and your path to Agile.

Dante Healy [00:00:45]:

Yeah, thanks, John. And sure. So my path for Agile wasn't your typical path. I actually started out in finance, having qualified as an accountant and got into management accounting initially via auditing for a global automotive company. And that's where I first got into transformation, where the company I was working for had acquired a factory in another company and to help support their ambitions they rolled out lean manufacturing in that, in that plant as well as, you know, brownfield site conversion and IT within that transformation. It wasn't just about, it was necessary, it wasn't just about cultural change. It was actual performance. And to the extent of organization change, it was even more fundamental because it was in a former Soviet country where there was so much hierarchy and the organization had to cut out more layers to reduce the level of administrative burden.

Dante Healy [00:01:56]:

And that was my first taste of big changes with real effects on people and how things worked in real life, not just conceptually. And so for that one, that got me started on this whole idea of, you know, setting things up and dealing with the transition from one state to another. And so I got the opportunity to lead a finance change project for their automotive banking division. And it was focused on cutting costs by moving work to low cost countries as well as automating tasks. And this wasn't about Agile, but it taught me about making big changes, which often means getting tough things done fast as well as clean. And after joining that, I worked on a number of projects across Europe effectively as the program manager. And that involved not just work transfers, but also upgrading systems and task automation. So when I saw how important digital was becoming, I learned I decided to start upskilling in software development as well as Agile ways of working and data.

Dante Healy [00:03:08]:

And now I lead digital projects in IT and finance for a global food manufacturer. So I've led transformation from both the money saving side and building new skills. And I've seen where Agile, Agile works and where it falls apart. Agile can be very strong if done right. But it's important to remember that it's not a silver bullet and it doesn't solve every problem, but it's certainly not a one size fits all solution. So in order to make agile work you need clear leadership, good plans, as well as a real desire to change how things get done. So I think that's where I bring, that's what I bring in terms of a different perspective, hopefully real stories, a more broader perspective than just product development and also lessons from transforming from the factory floor to digital. So hopefully that helps.

John Byrne [00:04:13]:

Yeah, definitely. Sounds interesting. So I'll jump straight into it then and as you get get going. So to us, just to set the scene a little bit of context from, you know, the set definitions effectively. So what is an agile transformation and what is it not?

Dante Healy [00:04:32]:

Good question. So an agile transformation is really more strategic. It's an organization wide shift and not just about implementing a methodology, a new set of tools and the related ceremonies. It's actually making sure your business can adapt quickly and continuously. And this means fundamentally changing how decisions are made and how value is delivered, as well as how teams operate, often impacting the business model itself. So it's not about just having JIRA boards or doing daily standups, it's about fostering that speed, that rapid feedback and ownership of those challenges that you face in your business. Often it's about really being transparent, surfacing uncomfortable truths within the organization. And usually what isn't it? When it fails, it's because leaders treat it merely as a delivery upgrade and expect quick wins without making those structural changes.

Dante Healy [00:05:42]:

Or when the focus drifts to the tools and the ceremonies instead of the mindset as well as accountability. So ultimately a real agile transformation is about business issues and it's not just about IT delivery and software. It requires executives to change how they operate and not just how teams deliver.

John Byrne [00:06:07]:

Interesting, you touched on it there at the end, I suppose, with what it is. And then you're mentioning it fails when certain things happen. But you know, why do so many of them fail to deliver results?

Dante Healy [00:06:25]:

Yeah, I mean it's no secret that a lot of times agile transformations fail and it's because they never go deep enough into what truly matters. So organizations typically implement new processes, labels and roles, but the decisions still remain top down and priorities often shift without warning and the underlying culture will still feel fear, failure. But you've got, you don't have any control over the outcomes. So this creates agile theater where the structure stays rigid, but everyone pretends to be flexible. So the core issue is a misalignment leaders talk about agility, but still expect fixed roadmaps and full control. So they'll say if you've got to deliver this fixed scope within this fixed deadline, it's not agile. They also failed to change crucial elements like funding models, governance, performance incentives and reporting structures. So people who take risks should be rewarded if they succeed.

Dante Healy [00:07:35]:

Also people who take risks, but as long as they're intelligent risks, if they fail, then you should understand why it failed rather than punish people. So if, if this environment isn't there, it will just drag everything down and actually make it slower. And I think the main reason is because many businesses lack the culture of trust, safety and learning that agile needs to thrive, leading to a situation where people, you know, where people can take risks and innovate and try things, to try different things. If they don't, then you'll find that your organization will stall. And it's not necessarily because the team delivers or can't deliver, it's probably because the organization won't evolve in its culture.

John Byrne [00:08:35]:

Those then part of how you try to manage things culture, I suppose is a difficult one to manage. But you know, there will be metrics and things like that to measure how they're going. So you know, metrics like velocity and sprint borne down, I suppose two parts to the question here is for those who are familiar with them to define those, those two particular metrics and also you know, with regards to them, are they hiding more than they reveal?

Dante Healy [00:09:07]:

So you've probably seen the burn down chart, which is a chart of the work that needs to be done and then as it gets completed, it goes down over time. Velocity is a measure of how, how fast the team can deliver work. And I find that very often these metrics hide more than they reveal and they often lead to an illusion of progress. And this is because while teams might appear busy with stand ups, retrospectives and JIRA tickets, the big deliverables remain stalled and no real value is being delivered to the business. And you can see teams marking tasks as done, but nothing meaningful lands in terms of value at the end. And often this is happening because work is forced into formats like user stories where, you know, not everything should be a user story. You don't need to say as a user I need to be able to do this to achieve that. It just needs a clear requirement like update the API or this is the table you need to create in order to be populated with data from that system.

Dante Healy [00:10:21]:

But yeah, it starts out you almost feel forced to fit things into like tidy boxes as prescribed. And when work is forced into formats like user stories, even if it's just infrastructure work, people start slicing tickets and trying to probably game the system to make the burn down chart look good and focusing on format rather than outcomes so tasks get marked. There's a temptation to mark tasks as done when they're not completely done and just raise another ticket for the unfinished component. And so velocity is an interesting one because it's a measure of. It's an estimate and it's an estimate of effort, not value. So a team can hit every sprint target and still make no real difference to the business because they might not be moving fast, but also they might be moving in the wrong direction. So if ultimately, if a team isn't solving real problems, testing early, or making actual progress towards delivery, these metrics are just noise because they're not really measuring what matters.

John Byrne [00:11:39]:

But so many things in life, getting the right KPIs or metrics or whatever is very important and making sure that people can't, you know, what gets measured gets done, but also what gets measured becomes the goal. And you don't necessarily want that to be the case for all these things. Careful. And one of the things you mentioned earlier about why so many agile transformations fail as well as they remain top down, but, you know, not going to the very top, gone to the middle manager side of thing. What, what happens when middle managers try to hold on to control instead of adapting an agile transformation?

Dante Healy [00:12:17]:

As someone who's been a middle manager myself and now working independently as a freelancer, I can take the view from both sides and from the outside. Middle managers are often unfairly painted as the problem, as blockers who resist change and cling to control. But more often they're caught in systems that give them immense accountability but very little safety. And they're expected to hit KPIs, keep business as usual running, absorb pressure from the top, protect their team beneath them whilst keeping everything steady. And in that position, not taking risks can actually feel like the only safe option. Especially when executives demand certainty but avoid owning directional shifts. And what's more, most agile frameworks simply ignore them. Taking Scrum as an example, they don't prescribe a role for a middle manager.

Dante Healy [00:13:17]:

They're often excluded from daily ceremony because of psychological safety and transparency. And they're designed the design conversations, they're usually left out in the name of autonomy. Autonomy. So the intent might be good, but the side effect is alienation often. And now they're still accountable but no longer involved in the decision making process. So if there is that gap, it will create friction and some middle managers will respond by tightening control, overriding teams, escalating decisions or creating parallel reporting chains. So doubling the work in terms of communication overhead. And others simply just disengage, leave the teams hanging.

Dante Healy [00:14:09]:

So either way you end up with agile on paper, but waterfall thinking underneath. And the answer isn't to cut them out, but bring them in with purpose. So for the right people, transitioning into a product owner probably can work. So they take the product owner role, make the decisions around what work should be prioritized and sequenced, but only if they have the real authority and access to the end users so that they can control the backlog and the decision making power. So if you simply rebrand them without authority, then it's just cosmetic and you're setting them up to fail. So middle managers can either become the choke point or the change enabler, but they certainly need support, clarity and a new framework for what success looks like. And the danger is if you ignore a sign line this layer, the transformation will stall quietly but completely. And I'm taking that approach in terms of that view because I'm assuming that the middle manager is competent.

Dante Healy [00:15:19]:

So there, there is that element of maybe they're not competent and you want to sign line them, but it's still they have authority and they have accountability. If there is a capability issue then that's some, that's another matter entirely, which I don't want to go into because that be another episode in and of itself.

John Byrne [00:15:42]:

Interesting. And you know you've been touching on it and quite a few things you know about agile transformations and where did they, you know, how they can fail and that, and I suppose one of the big ones is to set expectations from the beginning that sometimes people don't really know they've heard the buzzword but they don't fully understand the consequences on it. So slightly on that, kind of moving over to that bit of a topic, in your opinion, what's the biggest myth or misconception about Agile transformation?

Dante Healy [00:16:15]:

I think from my experience the biggest myth is that Agile transformation is primarily a technical problem or a delivery problem. People think it's about getting new software running different meetings or just being able to deliver faster. And they see it as an IT departments problem, which is something for the technology teams to sort out and in reality which is often hard for leaders to swallow it, that it's fundamentally a business problem as well as a leadership problem. And I've seen countless times where the technical teams are ready, they've adopted the practices, but the business aren't ready to change their behaviors. So for example, I worked on an IT team that was pushing Agile, but the business side couldn't make clear decisions or prioritize effectively and they'd hand over a laundry list of demands and change their minds constantly on how things needed to be delivered. So changing requirements left the tech teams in a perpetual state of rework because of the multiple changes in direction. And another common misconception is that it's about control. Leaders want to control the transformation dictate process and then get predictable fixed outcomes.

Dante Healy [00:17:34]:

Agile by its nature is about embracing that uncertainty and adapting to it. So it requires leaders to let go, trust their teams and focus on outcomes rather than micromanaging outputs. So this shift is deeply uncomfortable for many because it challenges established power structures as well as traditional management styles. And when leaders try to control a agility, they end up with agile theater where people just display all the outward signs of an agile but none of the actual benefits because they just going through the motions without any core behaviors changing. So it's really about changing that very nervous system of new organization and not just teaching new tricks.

John Byrne [00:18:25]:

So does seem to be then.

Dante Healy [00:18:29]:

One.

John Byrne [00:18:29]:

Of the key things is when you go to extremes, Agile can't handle it. The extreme of keeping control and not giving the adaptability will obviously fail. But the other extreme from what you mentioned there, of people constantly changing their mind, constantly pivoting, that they confuse that agile, you're supposed to be able to react quickly, but you know, it still needs a certain amount of structure. It's not a completely unstructured thing. So getting, getting that balance right is one of the key things. And I suppose when it, when an agile transformation fails there's, there are obvious problems, obvious costs and consequences of the failure of the transformation overall. But what are some of the hidden costs or negative consequences of delta agile transformation in your experience?

Dante Healy [00:19:19]:

Interesting. Often the hidden costs of a failed Agile transformation are far more damaging than the initial investment. It's not just the wasted money on consultants and training, although that's certainly a part of it. But first there's a profound loss of trust and engagement and skepticism. So when organizations go through that big initiative, that profit promises a lot, however delivers very little. People then become cynical and I've seen the agile flavor of the month come and go, and now they're just waiting for the next buzzwords to land. I've been in places where after a failed transformation, any future change initiative is met with eye rolls and passive resistance. Everyone goes back to their old ways of working, but with a newfound skepticism around it.

Dante Healy [00:20:13]:

Second, you'll obviously see a brain drain where truly talented people, ones who are naturally adaptable, who do want to innovate and who are frustrated by old waves, often leave because they don't get any opportunities. They seek out companies who actually change what's happening. And what's left are those who are comfortable with the status quo, who are and who can't afford to leave, which makes future change even harder. And then third, there's the entrenchment of bad habits. So if a transformation fails, it often means the underlying systemic issues like siloed thinking, lack of clear ownership, or fear of failure were never addressed. And these problems don't just disappear, they just become more deeply ingrained. And it validates what the cynics say when they say, see, Agile doesn't work. Let's just stick to what we know.

Dante Healy [00:21:08]:

At least that worked, even if it is inefficient or ineffective. And then finally, the missed opportunity cost. When you're busy failing at Agile, your competitors might be genuinely adopting it or adapting it to suit them, and they end up becoming faster, more innovative and more responsive to customer needs. So you end up losing your competitive edge in your business potentially. And the selling point for Agile is adapting to a rapidly changing business environment. So the cost isn't just what you spent, but it's also what you could have achieved but didn't. So it's very damaging to the organizations over time.

John Byrne [00:21:56]:

Given, given your experience. I mean, we're major automobile manufacturer and now, you know, food manufacturer. Not. They're, they're quite traditional industries. They're, you know, from the industrial revolution onwards, they've probably been around since near enough the beginning or variations of them. And they are quite large the ones that you've been doing. So from your experience, what would. What specific challenges do traditional and large organizations face when trying to come Agile?

Dante Healy [00:22:30]:

Yeah, large traditional organizations, they tend to face big challenges because they're built on different ideas. So they grew up on structure, control, scaling. And you can think of them like big supertankers. They're very slow to turn and they've been going in one direction for a long time. So the biggest challenges I guess are first there's the money problem. If it's a big company, everything is usually planned and funded up front before the start of the next year and you've already determined what you're going to do and you'll stick to that plan. Agile wants you to check in often and change what you're building based on new information and that doesn't fit with a yearly budget plan and also setting your objectives for the year. And I've seen situations where a team realizes halfway through the year that their project isn't going to work, but they can't stop because the money was already spent and approved for that specific thing and they're forced to keep going even if it's a bad idea.

Dante Healy [00:23:36]:

And my personal experience with the automotive company was when I had to shift my objectives midway through the year in order to support another business objective. And I was still punished for even though I achieved the additional objective, which was a critical priority versus project priority, I was still penalized at the end of the year for not achieving my project goals and not really recognized for going above and beyond on so effectively managing two departments at once. One was operational, one was project. So that comes back to my next point, which is about leadership itself. And in big companies, leaders usually are used to telling people what to do and not asking for solutions. And they like clear plans and knowing every detail. Agile asks them to trust their teams more and let go of some of that control. And this is a huge shift.

Dante Healy [00:24:31]:

They might say that they want Agile, but they still like acting like the traditional boss I once worked with. Coming back to that senior leader who said he wanted to be agile, but then he got upset because I couldn't give him a fixed date for a product that was still being lord and he was still thinking in that old way, wanting certainty before it was even possible. And we hadn't even done the analysis fully yet. And then also departments are, they're siloed. So think of them like separate islands. Everyone wants to work in their own part of the business and it's hard for them to work collaboratively because it, it messes with their focus. And in Agile teams they need to be able to cross lines and have people who are cross trained in not just finance, but IT marketing and sales and they're all getting together on one product. In big companies, information tends to get stuck in silos and getting approvals from different departments can take forever because you're traveling across and also up depending on the scope of the approval you're seeking.

Dante Healy [00:25:44]:

So you end up with a lot of talking and very little doing as you try and get that buy in. And finally there's a huge amount of old technology or technical debt. And this is the one that really killed me, trying to be agile in a traditional large organization. So you imagine building a new house but trying to connect it to a really old broken pipe system. It's hard to move fast around new things when your old systems are barely holding up. And yet many companies just keep the lights on with old technology and that makes it very hard to introduce new nimble ways of working. These old systems are like concrete boots for an agile transformation.

John Byrne [00:26:26]:

You're seeing a lot of that nowadays. And banking, I suppose, is a clear classic one.

Dante Healy [00:26:32]:

You know they run on Cobalt.

John Byrne [00:26:34]:

Yeah, yeah, yeah, they and, and yet the modern, the, the, you know, the new modern ones, you can set up a new bank account on your app, on the phone in a matter of 10 minutes, taking a photo of your app and all that. Whereas the, the old traditional banks, you still need to go in where all your documents get everything signed and then wait and you're still wait and wait. But regards to that, you, you mentioned the old technology, the technical depth there. So how does technical debt, you know, the accumulation of unaddressed code or system issues, how does that hold back agile progress?

Dante Healy [00:27:11]:

So technical debt is actually a huge problem and it makes everything slow down. It's a topic that often makes me sigh because it's so easily ignored until it's too late. And think of it like this. You're trying to build a fast, shiny new car, but you're starting with a rusty old engine and flat tires. So when you have a lot of technical debt, it means your computer systems and code are full of shortcuts, quick fixes and old ways of doing things that have accumulated because they were never properly cleaned up. And it's like having a house that where the wiring is tangled, pipes are leaking. Every time you try to add something new or change something, you find yourself tripping up over these old problems. And so for an agile team, this is a killer.

Dante Healy [00:28:00]:

Agile is about moving fast, adapting and releasing new features often. But if every small change requires fixing three or four old problems and then testing everything end to end regression testing and you find you're wrestling with messy code, then you can't be fast because you end up I, I've been in situations where I was two weeks from go live and told that that feature I was trying to deliver had to be rolled back because it had a knock on effect on another module for another department and it couldn't be delivered. So you end up spending more time dealing with ole mess than building new value. And I've seen like I've had teams stuck for weeks just trying to get a small update out because the underlying system was so fragile. Just to put a specific example Delivering a miscellaneous invoice. That couldn't be done because they couldn't, they couldn't, they couldn't code it in their green screen system, which was codeball by the way. So I ended up creating a CSV that printed out the, that was loaded into an access database in order to generate the miscellaneous invoice. That's how bad it was.

Dante Healy [00:29:14]:

You know, you try workarounds and that was at a time where I was less technical than I am now. So what's worse is that the technical debt makes you afraid to change things. If a system is so old and tangled that no one really understands how it all works and any change feels risky. A lot of these really old systems haven't been documented either, so it's hard to. You're almost doing forensic analysis and I didn't have anyone that technical on my team from a business requirements point. But when they failed, the IT and the technical analysts tended to band together to defend the system and blame the requirements, which were just high level documents. So in the end teams end up becoming scared to touch the code and that slows down innovation. So nothing gets done really.

Dante Healy [00:30:06]:

So they can't quickly try out new ideas or fix problems because the risk of breaking down something big, which is your existing business, is already too high. So in the end, as I mentioned alluded to, is that you end up with this blame culture where everyone points fingers when things go wrong. So I didn't deliver. I say it's a technical issue, technical. The technical team blame the business requirements and point to certain things that weren't done, even though you're not meant to be following through the system to every endpoint and it still fails. So again, it gets really frustrating. This fear and drag go completely against what Agile is supposed to achieve and you can't be truly agile if your technology is holding your business to ransom.

John Byrne [00:30:57]:

So far then you know the two key, you know. Well, there's been a few issues that you flag up culture within the organization, especially leadership culture and technology, that's a big one as well. So either of those two are capable of pulling down a whole agile transformation and going back to the leadership piece a little bit. Because, you know, the technical debt I suppose is kind of almost fairly clear how you fix that. Get everything up to date and get that done.

Dante Healy [00:31:28]:

Invest money in upgrading your systems. Yeah, exactly. I had an IT person who's IT director who came in new and he said you guys don't like to invest money and you knew you were in trouble, right? Trying to be Agile in that scenario.

John Byrne [00:31:45]:

That'S a, that's, that's the, that's almost an easy fix. Then you know, okay, there's the answer there. Update your technology, make sure you don't have any more technical debt. Get it all done. But the cultural piece. And for leadership, well, what leadership behaviors are essential for an Agile transformation to succeed?

Dante Healy [00:32:01]:

Right, so you've got me started here. From what I've seen, really, leaders need to do more than just support Agile. They need to show it with their actions every single day. Firstly, they need to be present and involved. And it's not about micromanaging. It's all about showing up for the meetings like Sprint reviews and actually listening to what the teams are building and learning. They need to engage with the actual work. I remember a case where the CEO and his top team would come to every demo, even if it was just for 15 minutes.

Dante Healy [00:32:33]:

It sent a powerful message like this work matters. And that kind of presence makes a difference. Second, leaders must be clear and decisive. They have to set clear goals and priorities for the whole company and then stick to them. So nothing kills agile momentum faster than leaders changing their minds all the time and giving conflicting instructions, because otherwise you just confuse your teams and again come back to wasting time. So when priorities are clear, teams can focus and deliver. And third, they need to trust their teams and give them power to make decisions. And instead of telling teams exactly how to do something, leaders should explain the problem that needs solving, set direction, and let the team figure out the best way to solve it.

Dante Healy [00:33:23]:

So it means accepting that not every idea will work and it's okay to fail fast and learn. It's not about being hands off, it's about providing clear direction and then getting out of the way so the teams can do their best work. And finally, removing roadblocks so teams will often hit walls, old systems, silly rules, and people who refuse to cooperate. The leaders need to step in when things are stuck and clear those paths. And that shows that they're truly committed to making transformation work and not just wishing for it. So in that context, leaders really it's all about, if they're not already doing these things, then they need to think about changing their own ways of working. And if leaders still demand fixed plans, punish mistakes, and or only focus on busy work instead of real problems, then the Agile transformation is just the show. So they need to live the values they preach once they subscribe to them.

Dante Healy [00:34:24]:

And it's about setting that example and being willing to adapt their own behaviors first. Otherwise the transformation won't stick.

John Byrne [00:34:35]:

Thanks. Gone through some ideas there what causes agile transformations fail and you've there now given a few ideas as to how to avoid failure. But how can an organization recover if the agile transformation has already failed or stalled? So you know, is it a complete write off or are there techniques, are there systems they can do to try and, and recover it and rescue it?

Dante Healy [00:35:06]:

Yeah, yeah, it's tricky one because you can't just keep pushing harder in the same direction and doing the same things, but just applying more effort. What I've seen in this instance you often need to hit the reset button and because you, if, if things you're trying are not working and I don't know how many times that they've been attempted but if you don't, if you don't feel like you're making progress, you need to stop, look at where you are, take, take stock of where you are and check the map to find a new path. You need to be honest about what went wrong. And oftentimes as leaders, it means admitting that first attempt didn't work or the first idea or strategy didn't work and explain why. It's a chance for people to say either they messed up or they, they had the wrong assumptions and that will rebuild trust with the teams. I've seen some leaders who just try and sweep it under the rug and that usually only leads to cynicism amongst the team members. But once you've admitted that a change of direction is needed, you need to re establish clear goals that focus on real results. So rather than going back into agile theater where you're just going through the motions, you look at focusing on what are the two to three most important things business needs to achieve in the next few months and then focus on those, make sure everyone knows why they matter.

Dante Healy [00:36:49]:

I mean, in one team we stopped talking about agile adoption and started talking about really, you know, how many developments, how many improvements could we deliver. And that shift in focus made all the difference. Leaders also need to be visibly changing their behaviors. If they were part of the problem, they need to show that they're doing things differently now. And that means being more present, more decisive and truly empowering your teams to make those calls. If they're, if they're stepping up, then you should encourage that. So lead by example and not just by words. And then also maybe it's a new perspective.

Dante Healy [00:37:31]:

So bringing in new team members, fresh eyes or even external help will allow a new, clearer view of the situation without old biases creeping in. And sometimes outsiders can spot problems that People inside the company have just become accustomed to and normalized. So I think the key thing is really starting small and showing real wins and don't try and fix every problem at once. So pick one or two high priority crucial problems, put a focus team on it and to get a clear and quick win and then hopefully that success will help to build momentum so it will show people that real change is possible and then the reset isn't just another false start, it's actually a gradual climb that rebuilds belief in, in the mission.

John Byrne [00:38:34]:

So yeah, interesting talk there. And you know, obviously we, we did it in this format because you're the agile person, you, you do agile, you know, agile. But I also happen to know like, you know, I'm sure a lot of people, anybody who is following you on LinkedIn or that will be aware you really like the new AI tools and you're constantly trying them out and playing with them and using various things. So, so, you know, combining both of those interests that you have together, give us a few ideas. How do you think AI is starting to reshape agile practices? Or is it? And are the teams ready for it if it is?

Dante Healy [00:39:15]:

So thanks, John. From what I'm seeing, AI is definitely starting to pop up in agile practices and it's a bit of a mixed bag whether the teams are truly ready for it. Right now. It's still an emerging practice. I mean, on one hand, AI is very useful for productive, busy work. Tools are coming out that can help with documentation and code snippets, and this may make some parts of the process faster. For example, instead of a scrum master trawling through minutes, they'll have AI recording, say, virtual calls and then automatically minuting those discussions and drawing out the key points and also doing documentation on stories. If you've got a project, a specific type of project, and you write the right prompt, it can give you a good draft first, first draft plan that you can update, which allows teams to focus on more complex things.

Dante Healy [00:40:20]:

However, I would say that AI carries a big risk that it can create or accelerate agile theater. So if a team uses pure AI to just churn out stories without understanding the customer, the business context, or write code without properly thinking it through, it just speeds up bad practices such as technical debt that we mentioned. I've already had developers on my team or tech leads say that certain vendor consultants are generating hundreds of lines of code, but a lot of them are redundant. So it just makes the whole ecosystem messy. They do get rejected, by the way, but you see, it suggests that weaker consultants or digital developers might just cheat with AI and not really think a problem through. But they look busy and that's something that needs to be captured. Not sure exactly if we've mastered how to deal with it when it's called out apart from the standard code reviews, but when you think about it, AI is like putting a super fast engine in a car. However, the car doesn't have a steering wheel or brakes and you're going to go nowhere fast or you're going to even crash.

Dante Healy [00:41:39]:

And I worry that some places will use AI to look busy with agile practices, but not actually improve how they deliver real value or truly understand the customers. Another thing is AI tools often work best when the data that they're fed is clear and high quality. But in many organizations, especially the big traditional ones, data is disparate, it's messy, priorities change, and processes aren't always static or clear. And AI can't fix that fundamental mess. It can only work with the context it's given. So if your organization has bad habits and unclear goals, AI might just help you do bad things more quickly. So some teams are ready for it, but. And those are the ones who truly understand how agile works and continuously learning and adapting and see AI as a tool that can supplement their processes to work even better.

Dante Healy [00:42:41]:

But many teams are still struggling with the basic basics of agile. And a good agile should we say so clear goals, trust, feedback loops, and for them, adding a layer of AI on top might just add another layer of complexity, risk and confusion, especially if leaders push it without fixing their core problems. So the real question isn't whether AI can reshape Agile, but whether organizations are ready to use AI to build better agile and not just be faster with bad agile. And again, the other thing with using AI is if you're not thinking through the outputs and working through it, you're not going to be learning, you're just delegating the thinking to a tool. Sorry, John, I can't hear you.

John Byrne [00:43:42]:

Sorry. And an interesting take on it, I suppose with AI and with tools generally it's how to use the tool that will matter and I will make it the best thing. So, you know, as long as people are using the tool correctly, ultimately I think that's from, from what you've been saying, it's the same Agile overall that, you know, agile transformations don't necessarily suit every business. Some businesses it may suit in the future, but at the moment they're so far behind, either culturally or technically, they couldn't, they're not able for it. So for them they'd have to do more traditional stuff until they get up to date in a way that they're ready to then try an agile transform. But you know, I suppose a lot of businesses and agile transformation will never be the answer. It's not what will work best for that business. It's very specific situations where agile transformations will actually be of benefit and should be to be used or attempted at least.

John Byrne [00:44:44]:

And I think kind of in back in your introduction you hit on that a bit when you said it's not, it's not a silver bullet, it's not a magical system that will make everything better. That some businesses it's the wrong thing to do. In other businesses it may be the right thing to do, but the business themselves need to prepare for it. They can't just wake up and say right Monday we're going to be an agile organization. They need to get rid of their technical debt and make sure they get their cultural beliefs changed to suit a force before they can start. That's kind of a large chunk to really summarize what I've taken from the conversation, but I'll hand back to you to finish up that, to make sure that. Is there anything that I've misread there or is that roughly what you were trying to emphasize? Is there anything else you'd like to say to finish up?

Dante Healy [00:45:38]:

That's a great summary. Thank you, John. Yeah, I think Agile, as you mentioned, is not for every project and I think some are still a spider agile, which is why they do hybrid. So ideally they get the best of both worlds, a customized flavor of Agile that doesn't completely risk their whole business. And it's not either or it's. You can have, you can, you can have elements of agile that work for you. So if it works, you see. But don't, don't feel you have to go all in.

Dante Healy [00:46:15]:

Even Agile is like series of experiments, right, that you test and validate before you decide to scale.

John Byrne [00:46:26]:

Thanks for that ante. I hope everybody found that interesting. I certainly did. And that's going from somebody who, as I said at the beginning, I'm not really into agile. I do do a little bit. I dabble in hybrid as. Yeah it just then there and that's about as far as I go because generally the projects and the organizations that I work with either wouldn't be ready for agile even if agile would for them or simply wouldn't work for them. But yeah, it was good to get that input from you and information to pick your brains and see how things went.

John Byrne [00:47:01]:

So hopefully the listeners felt the same way. And if there's any feedback from anybody, please feel free to, to reach out. I'll hand over to you, you, you look after all the technical stuff of, of getting their feet listeners. So I'll let you fill them in on that.

Dante Healy [00:47:16]:

Yeah, yeah, thanks. I'll drop links in the comments in the show notes and yeah, thanks, John. It was an unusual, unfamiliar, shall we say, experience being interviewed rather than having, like, equal conversation. But, yeah, fun. Thank you for. Thank you for being the host this time.

John Byrne [00:47:38]:

Thanks, Ante. It was a pleasure to interview you.

Dante Healy [00:47:41]:

Cheers.