Dante Healy [00:00:00]:

Hello, everyone. Welcome to another episode of business breaks with your cohost, myself, Dante Healy, and my friend, John Byrne. So this session today, we'll talk about the pitfalls of misapplied agile. And this will be, hopefully, a real no nonsense look at the reasons why agile goes wrong in companies today. Our three most common failures of misapplied agile. Looking at the background or where we are today with Agile, it's supposed to make businesses faster, more adaptable, and better at delivering value. Instead, many companies are stuck in what's called Agile Theater, going through the motions, but seeing little real benefit. However, companies have exploded in terms of agile adoption with 61% of them now using it not just for software delivery, but also functions like HR and even finance deployments.

Dante Healy [00:01:00]:

And its market is set to grow by about 19 and a half percent annually. And at the same time, there is also this backlash. Companies are phasing out agile roles, and I presume it's because of the rigidity of which the frameworks themselves are applied. Consultant over each and both broken promises of transformation. And agile itself isn't a sim silver bullet. It is useful. However, companies do experience framework fatigue setting in because of cookie cutter application of agile principles and methodologies. So what went wrong, and how do we stop agile form being just another corporate illusion? So let's get into it.

Dante Healy [00:01:47]:

So, John, I'd like to start off with how does short term thinking lead to long term technical problems like technical debt? Would you like to share your thoughts?

John Byrne [00:02:00]:

Yeah. Well, I think one of the the big issues overall with with agile at the moment is that it has become a buzzword that everybody wants to shoehorn into whatever they're doing. I think, one of the problems, you know, the short term thinking and the the leading to the long term technical debt that you're you raised is, you know, I think really doing agile or just cutting corners and pretending that it's agile to, to, to do it. Cutting corners, it'll get things done very quickly now, but, you'll run into problems. If not immediately, you will run into problems later on. Those corners, you know, being cut do do cause issues later on. You know, the, the, the old adage to, to move fast and break things, break things. It sounds great until everything's broken and then nothing works and you're, you know, in serious trouble at that stage.

John Byrne [00:02:56]:

And then the, the, the idea that they'll fix it later, later never really comes because something else will be happening later that becomes a priority and, and everything will start to snowball up and you're running into issues. So I think, yeah, in, in, in brief terms, that's where short term taking can lead to long term technical debt that the the shortcuts you've taken now means in the future, you're missing something that you need as a bedrock for for greater expansion. Yeah.

Dante Healy [00:03:28]:

One of my biggest bugbears, In fact, one, should we say, recent role where the head of the digital finance analytics said we are agile, so we don't do documentation. And that's one thing that really gets my goat Is that if you don't document things, you don't understand the background, and there's no history. So when things go wrong, you can't go back and trace. Was it a poor decision? Was it a poor was it poor design? Was there misunderstood assumption? And, therefore, poor documentation would be mind bug bear because, also, you don't have an audit trail. So if you wanna reflect, you don't learn either if you can't document it. You're you're at the mercy of anecdotes and people's own personal views of what went wrong. So opinions will tend to fly around, but they won't be verified. Yeah.

Dante Healy [00:04:28]:

And I guess other things are people rushing to get work done. So you get ropey code. You also find that people play fast and fast and free with design decisions, which may actually get reversed as as quickly as a few days later. So no scope lock. So people aren't working in a consistent way or in a in a clear direction. So I think some sometimes you need to plan, and that's always a problem. If you're not being thoughtful in how you approach your work and what you're trying to achieve, then it's gonna come back to bite you seriously. So I think sometimes it's being too reactive rather than proactive and thinking longer term about how do we set ourselves up properly for success.

Dante Healy [00:05:23]:

And I think sometimes there's a hidden cost to that because you you build up too many shortcuts, and over time, it just becomes harder to actually move forward. So cutting too many corners will just as we as you just said, come back to bite you further down the line in your projects. So have you seen that? People say, we'll cut this corner now. We'll get back to it, but they never get back to it.

John Byrne [00:05:48]:

Yeah. To be honest, what what you mentioned at the beginning there was the documentation. That's the the biggest corner of seeing that in reality, the project that's being done is for all intents and purposes. It is a waterfall project, but somebody's decided we don't want to go through the hassle of all the paperwork. So we call it an agile project and just get new. And that's a, you know, even when it is truly an agile project, there is still some paper hook that needs to be done. There's some documentation that needs to be done. You need to have a plan, a business case, various things like that.

John Byrne [00:06:21]:

You just don't need to be quite as rigid about or quite as detailed about some of the things, but certain things like that that you still do need to have documentation. And that is the biggest, shortcut that I've I've seen people do that. They just rush in no documentation, no plan, no idea rush in. And then as you said, you know, sprint two is actually undoing half the stuff that sprint one did because it hadn't put taught into it and then just realized when it was delivered, oh, this probably wasn't the best idea.

Dante Healy [00:06:52]:

Exactly, John. Exactly. I mean, you've got the agile mindset, which some people might think is the approach you take when you're doing an agile project, which is get to MVP as quickly as possible, and then use customer feedback to iterate quickly on top of that MVP. But, really, what agile should be is, in terms of the mindset, is about risk management. And to that extent, you're looking at more the strategic side of it. How do you scale quickly once you've got a decision where you've proven that there is a product or a a market out there, and then you have to adapt to it. So make refinements, and then you plan to scale longer term and build in resilience into your structures so that you can actually succeed. So yeah.

Dante Healy [00:07:45]:

Yeah. I think, I think that's always been a top peeve of mine is the I think, agile. And to be honest, when I first started with agile, I used that excuse once where I was saying, we just wanna get to an MVP, but not realizing that there were regulatory implications to what we were trying to do even though I thought it was a localized thing within finance and accounting. It turned out there were some tales to it on the reporting side, regulatory reporting to be precise. That meant that I should have engaged certain stakeholders on that side to to ensure that they weren't negatively impacted. But this was in the early days, and we didn't go live with it. It was just somewhere in the analysis. We'd we'd made certain assumptions that turned out when we got closer to go live, needed to be delayed on implementation whilst we build in what was needed for regulatory reporting.

Dante Healy [00:08:48]:

So yeah. Brilliant. So the next topic we'll talk about is agile in name only. So we have various flavors of going through the motions of agile, but it's nothing more than a performance. So there's three names for it. There's agile theater, which is the most common one. You've got fake agile and dark agile, and the distinction is really degrees of not being agile and pretending to be agile. So agile theater is when you go through the motions, you do daily stand up sprints and retros, but you're not actually an agile project.

Dante Healy [00:09:23]:

You probably have a a sprint plan that is really a waterfall plan, and you're you're focusing on the processes and ceremonies and looking at doing those for the management optics rather than the actual approach and the outcomes. And then there's fake agile, which is a broader term for agile in name only, where they claim to follow agile, but are still fundamentally waterfall in the sense that they have a command and control structure and are essentially bureaucratic, so they document to death. And then the worst one is dark agile, which is a more insidious version, where agile is twisted into something harmful, such as micromanagement disguised daily stand ups. And that leads to team burnout because you're basically pushing your developers harder. It's funny. I had a a senior architect say, we've got a great scrum master. He basically keeps people on on top of their tasks, which is not what a scrum master should do. He's supposed to be supporting the old agile, framework or scrum framework.

Dante Healy [00:10:33]:

So, yeah, so when agile is nothing more than a performance, it usually goes to not actually achieving what should be achieved through agile. So it's not really it's forced into projects where it doesn't belong. And, John, what do you think are some of the reasons and causes behind that?

John Byrne [00:10:55]:

Well, as as I mentioned earlier, I think because agile has become such a buzzword, everybody thinks that's what you need to do. Waterfall projects have kind of been around so long that people almost look down on the mountain that it's not the, the modern way of doing things, even though it is the modern way of doing most projects, actually, even, even projects that become agile and sometimes think are better off. I usually do a waterfall element force and the agile comes afterwards so that you've delivered the waterfall bit is the minimum viable product side of thing, but that's being planned out. And then after that you do incremental improvements. But yeah, and there are some tools in agile that work well outside of agile, but people, you know, wrongly think that once they're using those tools, they must be doing agile. So like the standups that you've mentioned, they can be a very effective tool to use in, in any, business, you know, any day to day operations, even to do a short standup, a proper standup, you know, that's only wherever ten minutes or fifteen minutes point of them. If you're going for an hour long standup, it's not a standup that can, that can work well in, in many fit settings. But when people start doing things like that and using some of the tools, they automatically use serum.

John Byrne [00:12:14]:

Well, if we're using that tool, we must be doing an agile project. No. You're not. You're using one of the tools that's most known with agile, but you're using it in a different setting.

Dante Healy [00:12:23]:

Exactly. I mean, some daily stand ups aren't necessarily your typical scrum daily, where you say, what, what have I completed? What do I plan to do today? And what's blocking me? You sometimes, you can have daily sessions within your team that are actually detailed working sessions or breakout sessions. So it depends what you need the daily call for. And the other thing is you don't necessarily need a daily call daily if some of the work is probably gonna take a week or even a few days. But you might wanna check-in on progress more frequently than the end of the week.

John Byrne [00:13:03]:

You don't?

Dante Healy [00:13:04]:

Because you don't wanna yeah.

John Byrne [00:13:05]:

Yeah. I was just I did have an example of that once before where, there was we we'd moved on to a project and we were doing that, the project as an agile project, a proper scrum, project. So we were having the the baby stand up and I was busy doing some other things. So I said to, the the one of the people I was technically the project manager, even though we were we were kind of running as a scrum, but I was acting as a scrum master. I was just facilitating this is this at the end of the project effectively when we were just doing that job piece. And I said to one of the the the business analyst who was working on it and was still involved to just set up a, daily scroll and a daily stand up to to just so that we can keep abreast of what's going on just to do exactly, you know, what it's supposed to be. Are we having any problems? What what what have I done? What am I about to do? And have I run into any issues? And he sent out the invite for a a one hour meeting every morning to get him to cancel the meeting. And, you know, an hour meeting is not a stand up.

John Byrne [00:14:09]:

It's not a scrum. It's, you know, ten, fifteen minutes tops and move on is right there.

Dante Healy [00:14:16]:

Exactly. Another thing I find with, sort of like the agile ceremonies, another root cause is, as you mentioned, it's a buzzword and leadership loves agile. And they usually continue to promote it until they realize it doesn't necessarily mean false results overnight. And yet still some people try to force agile transformations to look more innovative. But then they refuse to change their own ways of working. They still wanna see a critical path and a Gantt chart, which isn't really an agile methodology or approach. But, again, as to your point, this is where you don't necessarily need to adopt every part of an agile framework or methodology. You can take the bits that work for your system and come up with something more of a hybrid approach.

Dante Healy [00:15:06]:

As long as it serves your business goals and your project, then you can tailor it to your needs because that's where the best project managers are flexible. And the worst scrum masters can be overly dogmatic about how you use the scrum framework.

John Byrne [00:15:24]:

And it's supposed to to know to know when it fits and when it doesn't and, you know, act on that. And as I mentioned, you know, you mentioned the hybrids. They they're kind of my favorite, but that's where I've almost developed. I'm usually involved in finance projects and finance systems and that. Just by their nature, you can't really do them as a as an agile. Lots of waterfall, but it it can be done as a series of mini waterfalls. You know, you don't have to wait for everything is ready before you go live with the system. When individual modules or functions are ready, you can hand them over to the you know, if they're useful and and can be used by the the the function needs the same needs state, then you can hand over to them.

John Byrne [00:16:03]:

But what I like to do is at the end of the last mini waterfall, when the system has been handed over fully, I like to then have, you know, a couple of two weeks sprints afterwards, two or three of them built in afterwards for the simple reason that as people start using the system, then they'll come up with a whole, here's an idea. We could tweak this and we could tweak that. So I like to just, you know, okay. As you're using the system, be making a note of this, we'll get our product backlog up and running. And then when we're finished, we have time and we have budget left over to start trying to go through the backlog and see, well, what can we deliver to, to improve it just to give you a little bit of improvement because you know, I, I am an accountant for by trade. So I don't feel, I, I feel I can get away with criticizing us a little bit and that we, we often lack imagination at the beginning of a project that we, we can't envisage how we use the system until we're using it. So that's why I like to have a little bit of an agile thing at the end of it so that as they got using it and realized, oh, these were things that we should have asked for, but we never thought about at the time. They can still ask for them as long as it's not a huge, big issue.

John Byrne [00:17:14]:

But the key thing is though, it is a waterfall project up to that point.

Dante Healy [00:17:18]:

And and this is true because even in in any technology project, especially if you're on the cutting edge or even the bleeding edge of technology, You're making big assumptions on what the technology is capable of and what it can do until you've done the deep analysis, run it through some pilots. You don't know the limitations and the boundaries of what you can achieve with the new technology you're trying to implement. So and, again, coming to your point, you're enforcing disciplines even after that are more suited to Agile because you're getting customer feedback after you go live. That's when they engage more because it feels more real. And therefore, the backlog is a useful tool to keep track of everything that can be improved, and then you go through that prioritization. What are the big hitters that will move your implementation forward quickly, and what are the ones that are more nice to have items? So then you can, again, implement all of the lists and go through it accordingly, be in the best possible way because you focus on the prioritization. You're you're doing it intentionally, and you're not just implementing things that are low priority whilst some really important items are left left still hanging in the backlog. So yeah.

Dante Healy [00:18:45]:

Very true. Step.

John Byrne [00:18:46]:

I suppose I just wanna I just popped into my head there. Not all our listeners will be project managers or I will know what we're talking about. So just for those, a backlog, a product backlog is basically a to do list. And it's just a, a prioritized to do list, to, to walk through as much as you can. And your sprints would usually last a certain amount of time. So maybe say a two week sprint and you try to get through as much of that to do list as possible. Then at the end of it, you see what you've gotten through, what you haven't. We prioritize things because things might change and have your new ordered priority list to do this for your next sprint.

John Byrne [00:19:23]:

And then you just keep walking through it until you're in our sprints.

Dante Healy [00:19:26]:

Yeah. Yeah. Makes sense. Thanks for that, John. I guess the final point about misapplied agile is really something that you don't really consider as agile, but all governance and lack of discipline. Certainly for scrum, it's about self organized self managing teams. But that being said, agile isn't a free for all. So why do so many companies still treat it like one? And I think there's this perception that governance equals bureaucracy.

Dante Healy [00:20:02]:

However, if you don't have any governance, that can lead to disaster. So what what are your thoughts on that, John?

John Byrne [00:20:11]:

I I almost think that when you're running a true agile project, governance is even more important than when you're running a waterfall project because the waterfall project is kept on track through the documentation. And if you've not got as much documentation, then you need a more, you know, a stronger governance thing to make sure the project doesn't start going off the rails. As, as we said earlier, you know, there's a myth that agile means there's no rules and no documentation and no structure, but that's a myth that there is documentation, there is structure and there are rules to running an agile project, but it's just less, less visible because if it's a lower amount of documentation, there's a lower amount of structure and there's a lower number of rules. So I think governance is, is, is vitally important. Overall governance is vitally important than an agile project because that's really the the overriding thing that will keep your project on track if you don't have the details documentation that a waterfall project would normally have.

Dante Healy [00:21:14]:

Yeah. If you're if you're not careful, you end up with this whole scope creep nightmare where teams who are in theory self organized, you may have end up having a scrum master who's probably very familiar with scrum, but has no necessarily business experience because they've been parachuted in from externally. And you end up playing the role of we'll figure it out as we go along. And then you end up with this whole scope creep nightmare where, you know, your constant changes in direction and what to deliver ultimately kill your productivity. And even within scrum, within that sprint, at the beginning, you lock your scope by saying, out of my to do list, which is the backlog, we'll do these 10 items of a list of 50, for example. And you don't you don't change. You're focusing on that list of 10 in your backlog within that sprint. If you suddenly if suddenly a manager decides, hang on a minute.

Dante Healy [00:22:21]:

I don't agree with this 10 midway through the sprint. You've done five of these items. However, the item on the backlog, I wanna include this as well. And then you you've thrown the team out of sync because they're they're having to contact switch. And then and, you know, prior to reprioritize what they had to do. So it could end up leading to demoralization if you undermine the team's decision making powers.

John Byrne [00:22:49]:

And then then you've got the other, you know, the famous one fail fast and fix and move on, but that's not really it's not really applicable to most projects. You don't fail fast. You try not to fail at all. And failing fast, I would work with something like a marketing project because marketing is a is a lot. Even when you're using an expert, it's guesswork. So the expert will recognize it's not walking quicker than than a nonexpert would and will so fail fast and then adjust and try something else and try something else. But that generally comes when, you don't know what will work. With the projects that we kind of do, you know, finance transformation would be our specialties, but, you know, software development, whatever, you, you need to have done a certain amount of research before you started the project.

John Byrne [00:23:39]:

Therefore, you should know it will work, and it done right. And failing fast is not really good. You need to have something to show for you. You can't, you know, failing fast can turn into failed, failed for, very quickly. And that's not a good for a project. You need to to have some kind of success even if it's not all the success you are hoping for.

Dante Healy [00:24:00]:

Yeah. Failing isn't failing. It's it should be learning. But the problem I've also seen even within an agile structure is a lot of the teams who say they do agile and even big consultancies, they don't bother with retrospectives. And that's the key important thing to learning is to reflect upon what you've done previously and what went well, what didn't go well, and what you can improve on. If you don't reflect, you're never gonna learn, adapt, or improve. And the reality will be some teams will end up continuing to fail without ever improving and learning from it. So I think in terms of that then, so agile isn't really a quick fix.

Dante Healy [00:24:48]:

And when you do when you do implement structure, it's about implementing guardrails, not micromanagement. And therefore, you need those boundaries. And you need to adhere to whatever works. Ultimately, being sustainable with agile is really trying to balance that iteration with execution, not not flip flop between scope changes and changes in direction. That's great, but you need to at least give some ideas a proper chance before you discount them. You don't just change on leaderships, changes in direction if they have a change of thought. You need to continue ideally until your the end of your sprint because they're usually very short anyway. And then you can reflect upon it and see, well, is it working and do we continue or do we need to course correct?

John Byrne [00:25:42]:

Yeah. That's that's one of the things that agile, like, you know, two two is about being adaptable, but that's not the same thing as being completely gameless. I'm I'm just hoping for the best, you know, that that needs some, some controls.

Dante Healy [00:25:57]:

Thanks, John. And, yeah, that wraps up those, our ideas on really what are the common misapplications of agile. So, I guess, to summarize in terms of those three problems, how would you start fixing them, John? If we start with the the short term thinking to long term technical debt, how would you intentionally introduce something that would address that problem?

John Byrne [00:26:27]:

And what well, you you basically need to the plan, I suppose, is is, you know, using agile doesn't mean you accept into a project with no plan. You still need to have a plan. Where are you going? Where to, and that plan should it should take into account the technical depth that you don't just start trying taking shortcuts that you actually take the route you take to get to where you want to go. Agile is a tool for getting there. It's not, you know, it's not a shock of it. It you slow need to go through the the the the moves. It's just how you do it. It's what's agile versus waterfall.

John Byrne [00:27:03]:

But, I think the plan having the plan is the big one there. How about you?

Dante Healy [00:27:08]:

I would agree to that. And also, technical debt means that you're taking a shortcut now, but you plan to repay it later down the line. So things like intentionally building in refactoring into your backlog, so you actually have the revisiting of that shortcut to actually improve upon it when you have the capacity in your team would be another good way to ensure that you're addressing those shortcuts. Because sometimes shortcuts are necessary because you want to meet a timing. So you you go live with an imperfect solution, but you refine it later down the line. But the key thing is to avoid missing it altogether. And then when you have to pivot again on top of that that process, then you've got you've got a bigger issue because you've built a dependency on a broken process. Brilliant.

Dante Healy [00:28:04]:

So and then the other one, agile phase of fake agile, dark agile. How would you address that?

John Byrne [00:28:12]:

I think, ultimately, you apply agile where it makes sense.

Dante Healy [00:28:18]:

Mhmm.

John Byrne [00:28:18]:

Don't just apply agile everywhere. You know? It it it does come back to, you know, as as we kind of said a couple of times in the past, it's a buzzword, so everybody wants to be agile. But agile is not, suitable for everywhere. So don't pretend there is. Don't try to to to shoehorn a waterfall project into being an agile one by ignoring, you know, or or insisting on pretending that it's an agile one. By the same token, agile techniques can be used in waterfall projects where it makes sense. So, you know, it does have to take it on a case by case basis. Not every project needs to be fully 100% agile.

John Byrne [00:29:06]:

My experience is most projects still need to be waterfall, but some agile techniques can be used during that waterfall project.

Dante Healy [00:29:14]:

Yeah. And I think to that, to add on that, which I completely agree with, it's about understanding the nuances where agile fits and when it doesn't. Also, don't get to too too bought into this whole idea of that you need to have the agile badge. Agile isn't really a a complicated approach. It's basically the waterfall cycle delivery cycle, but compressed by breaking down your delivery into smaller pieces rather than doing a massive big bang. You're you're iterating quicker and building on top of your initial MVP development. So I think it's it's a good approach, but often misunderstood, which is why we're we're trying to advocate for it as much as critique it. Ultimately, how you add how you adapt agile and how you apply it should serve your business goals and not just be a box ticking exercise.

Dante Healy [00:30:20]:

Brilliant. So and then the final one, how would you address poor governance and lack of discipline?

John Byrne [00:30:26]:

Well, by by by having the governance and discipline back in agile. Yeah. You know, it it it it's not an excuse to have no governance, no discipline. Agile is, is flexibility, but controlled flexibility, you know, that that that beats aimlessness and chaos. The the, you know, there there isn't a full, you know, the the scope where where agile by its nature can be a little bit fluid that's not structured, but that doesn't mean that you have no scope. You still have a scope. You have your product backlog or or whatever. Changing that is just a speedier process that you don't have to wait for them to, you know, to have the to set up the steering committee meeting to go to it with the proposal and all that.

John Byrne [00:31:09]:

That that decision can be made a bit quicker, but there still needs to be somebody making a decision. Somebody, you know, a small subgroup or something has to. It wouldn't be the scrum master's job to approve it or not. But the team leads, the the function lead, and the scrum master together approve the the scope change, approve a change to the, back product backlog or something. It it's it's more flexible than a normal change management's scope change, requirements would be, but it's not completely free for all. There there still has to be a process. It's just a speedier process.

Dante Healy [00:31:44]:

Mhmm. Mhmm. Yeah. I think it needs control flexibility, rather than just unaccountable chaos. And there is still a lot of great tools in agile that streamline documentation without eliminating it. So it makes it more efficient. So, for example, implementing integrations with project management tool like Jira, and then feeding those user stories into something like Confluence, where it automatically takes in the adaptation. And also integrating Jira on the actual work side with your Git repository in your development environment so that the the request automatically goes to the developer, and they know exactly what they're working on, what component of the system or code base that they need to adopt adapt.

Dante Healy [00:32:40]:

That's great. So I think to wrap up, I guess, agile isn't the problem, but how we apply is when you see a lot of the challenges with agile adaptation and transformation. John, anything to add?

John Byrne [00:33:00]:

I think we we've recorded everything more or less. Yeah, I I think that the the biggest myth about agile is that it's a a a more modern way of managing projects, and it can be applied to all projects. It cannot be applied to all projects. It's got a time and a place. There are certain projects that can be applied to, and it's very good at those projects. There are certain projects that should not be applied to, and if you apply it to them, chances are those projects will fail. So I think that's probably the biggest myth about agile is that it's an option for all projects. It is not an option for all projects, and you need to kind of apply it to the suitable projects and don't apply it today on suitable ones.

Dante Healy [00:33:41]:

Yeah. Trying to shoehorn agile everywhere as an entire framework when it doesn't necessarily make sense. Yeah. Agile should really be an enabler rather than an excuse for not doing the things you need to do regardless of the type of project. So to wrap up, let's make sure we fix how we use Agile and ensure that our projects in the future are successful. John, brilliant discussion as always. Thank you very much, and look forward to catching up next time.

John Byrne [00:34:14]:

Thank you, Dante. I'm looking forward

Dante Healy [00:34:15]:

to it. Cheers.