Dante Healy [00:00:00]:

Hello everyone. Welcome to Business Breaks your Project Management Edge. I'm Dante Healy and together with John Byrne we're getting into Agile anti patterns. Now the term anti pattern originally came from software design and it's a way of describing those repeated behaviors that look helpful but actually hold you back. So think of it as this seems like a smart move until it quietly starts wrecking your team. Over time that idea may move beyond code. We're starting to see it in project management, project delivery, and yet agile. So in fact, some of the most damaging dysfunctions in Agile team today look like they're doing everything right.

Dante Healy [00:00:46]:

You've got daily standups, check. Jira boards updated, check. Clean burn down charts, check. But when you ask is anything actually moving? The room gets quiet. So in this episode it's about identifying those dysfunctions so we can deal with them. Because once you can name a pattern or an anti pattern, you can start to break it down and solve for it. So let's start with refining what true agility is and most importantly, what it isn't. So let's get into it.

Dante Healy [00:01:22]:

So John, we're going to start with this idea of surface level agile versus true agility. And we've heard of like the cargo cult Agile Scrum as a religion and why retros never really. We've also discussed why retros never lead to change and are worse than skipping them entirely. So we can't just do agile, we've got to be agile. What does that actually mean to you?

John Byrne [00:01:52]:

I suppose I'll state the clear caveat at the beginning. Nearly all my projects tend to be waterfall, rather agile. So I wouldn't be as expert as you in agile. But what I do find is people tend to use agile. It's a buzzword. And that's all it is now has become a buzzword that everything is agile.

Dante Healy [00:02:12]:

If it's disorganized, you call it agile.

John Byrne [00:02:15]:

Exactly that. We don't want too much documentation. It's agile.

Dante Healy [00:02:19]:

We don't plan, we don't plan.

John Byrne [00:02:21]:

We don't really know what the scope of this project is. We're just going to start doing stuff and see how far we get. It's agile and I may not be an expert in agile, but I do know that is not agile. That's just using the buzzword. Try and justify not putting the typical things in place. And a lot of these projects end up being actually they're waterfalls and aren't even agile projects. They wouldn't work as an agile project. They're waterfall, but they just don't want to put the things in so they call them agile.

Dante Healy [00:02:54]:

They call the Gantt Chop bar sprints instead of.

John Byrne [00:02:57]:

Exactly, exactly. And even the, you know we're using JIRA so we're doing an agile project and. Well actually we're using JIRA just to raise tickets in our uat. It's part of our waterfall project. It's not. Just because we're using a particular tool that's known to be used in Agile doesn't mean we're using it. Kanban Boards is another one. It's just a nice visual to know what are we going to be doing next and what have we got done already moving things along a nice flow.

John Byrne [00:03:25]:

But not everything that uses Kanban Boards has to be agile. Some of the agile tools can be very useful in project work or in day to day work.

Dante Healy [00:03:35]:

Business as usual. Yeah, when you want to justify what have you done you have a checklist.

John Byrne [00:03:40]:

I mean we're, we're accountants. So where I've seen Kanban Boards being used very efficiently is month end process. You know here's all the stuff we have to do and we want to move it across to here's all the stuff we have done and, and then you've got the, the scrum that the team scrums. You know the typical thing, people who have meeting standups every morning think that they're doing scrum and you're kind thinking well actually no A this meeting has just gone on for over half an hour. It is not a team stand up in a, in a scrum setting. B we're not really talking about projects, we're talking about well what's everybody getting upset and, and that's it, you know it's, it's more of an update meeting rather than a, an actual stand up. So I think things like that are, are what I would assume, you know in your think they are people just using scroll. They're not actually sorry being agile, they're just kind of attempting to do agile.

John Byrne [00:04:40]:

They're just using the word, the name conventions but they're not actually thinking in an agile way and they're not actively doing agile and they would be an anti pattern because when they are doing things like that they are actually working against themselves.

Dante Healy [00:04:57]:

Yeah, thanks John. And you're right, I mean especially organizations who have bought into this idea that with Agile you get so many benefits, you get effective transformation, you get people who are collaborating more, working together more organized, understanding more and taking more personal ownership and accountability without thinking well maybe you'll get this but what do you need to get this? And sometimes it's as fundamental as the people aren't geared up to be agile. So when you say doing agile you go through the rituals but people are just using all the buzzwords, the new terms and new phrases to hide that it's still underneath business as usual and nothing's actually changed. I think also when people look at adopting Agile and what the practices are, there's nowhere in the Agile manifesto where it says just follow the Scrum guide because there's. Scrum is just a subset of Agile, it's a flavor of Agile. So saying what's really agile isn't actually just Scrum. You, you have different practices and a lot of them are technical, such as extreme programming having really strong test driven development. So things that are set up up front so that the quality is correct so you don't repeat the same work.

Dante Healy [00:06:34]:

And yet what you see are oh, we've completed this but actually we need to raise some more tickets. So you get new tickets in and it just becomes a cycle of raising tickets, closing them out quickly because you want to show a nice burn down chart and there's optics involved. So you put them in a next sprint but nothing's actually being delivered. People are busy but they're not delivering.

John Byrne [00:07:00]:

Yeah, they, I think there is still a lot of misunderstanding about what Agile is. As I said, I don't use it regularly because types of projects I work on wouldn't suit them. But I do tend to have a little bit of an Agile kind of component at the end of the project after it's gone live almost. It's just in what we do you can't get everything in the original plans because people don't know what they don't know. But as they've gone live and they've used it and gone live.

Dante Healy [00:07:30]:

Build a backlog of requirements.

John Byrne [00:07:32]:

Yeah, exactly, exactly. And so use a little bit for the backlog at the end. But it wouldn't be, I, I, I would say you would not consider what I do to be true Agile either. You know it is a. But it's useful, it is useful the way I do it. But I do see an awful lot of that that people especially in the projects I do because the projects I do tend to be system implementations which they, they're waterfall. That's really the only way to do it. Series of many waterfalls, but waterfall nonetheless.

John Byrne [00:08:04]:

And oftentimes I've had to go into rescue failing projects. People who are involved and are convinced that what they're doing is Agile and you ask them why are you doing it as an agile project? It needs to be kind of waterfall. Well, we do a stand up every morning and we're using a Kanban board planet. So it's an agile project. Yeah.

Dante Healy [00:08:25]:

Okay, fair enough.

John Byrne [00:08:29]:

That's it. And then when you attend the stand ups every morning you realize they're not even talking about the product. This has almost become a BAU stand up because the people involved are also still doing their BAU and everything's getting discussed. It's not just specifically about what did you do since yesterday, what you're planning to do today and is there anything we can help, is there any holdups? They actually start discussing the problems and trying to come up with solutions during a stand up and you think well no, that's, you know, stand up should be finished after 15 minutes tops so you can get on with your and you just know from the stand up then you, you need to arrange more one to one meetings that come up with solutions and who it is that you have to talk to. But now we're doing a stand up so we're doing especially the use of Kanban board. That's a big one. Anyone uses a Kanban board, it's a natural project.

Dante Healy [00:09:19]:

It looks agile so it must be agile. Yeah, and that's always a problem when especially those dailies, as you say, people say oh, it's only 15 minutes. Have you ever facilitated a 15 minute agile daily call? I have. And you have to be to a certain extent rigorous and almost to the point abrupt, close to rude. And that's not necessarily what you would deem a classic agile behavior in terms of that idea of psychological safety. Now you have to coach people into it and you even have to take the lead in terms of facilitating the meetings and say look, here's the agenda and please, we want to keep to 15 minutes. So please either come prepared, update your tickets in advance of the meeting and even then it's not about status. Ideally it should be about, well yeah, you cover what you've done.

Dante Healy [00:10:27]:

So that is status, what you're planning to do. So that's well, setting your target for the day until the next call and also blockers which are or what's burning. So it sounds logical but contextually you have to prepare for other team members to ask a million and one questions because they're interested or it might impact them and that can derail your agenda pretty quickly.

John Byrne [00:10:53]:

That's the thing. I mean they're the three challenges. There's only three things are A proper stand up. And they're the three challenges, what you've done. And the big challenge there is that it's what have you done since our last meeting? Not what have you done since we started the project. People start kind of rehashing, especially if they haven't really done a lot over the next day, which is normal. You know, you don't get a lot done in a day. So to say, well, we've just tweaked on from where we were yesterday.

John Byrne [00:11:18]:

And that's it. That's all you have to say. But they feel a needs to justify their existence almost. And they go, then the second thing, what you're planning to do, but again it's what you're planning to do between now and the next meeting tomorrow, not what you're planning to do over the course of the next month. And trying to get that. And then the blockers, when they name a blocker then somebody starts trying to, you know, oh, well what we can do here is. And they try to answer the blockers and well, no, hang on, we just need to state the blockers here.

Dante Healy [00:11:45]:

Yeah.

John Byrne [00:11:45]:

And we'll take it offline when this meeting is so everybody gets a chance to say what their blockers are and then we'll find out. Well, and that's what the facilitator is. Especially in an agile thing.

Dante Healy [00:11:54]:

Scrum Master has to help with unblocking.

John Byrne [00:11:57]:

Yeah. And they do that off the meeting, but they need that meeting to go around so that they can get the full list of everybody's blockers and then everybody can go off and do their work on the Scrum Master or the project manager that it's, you know, they're not using Scrum, whatever. Then go and try to fix those blockers. Set the meetings up with the right people to solve the blocker or follow up themselves if they didn't get a full understanding of what the blocker was. But not to be trying to fix the, to discuss the blocker at that meeting, just state the blocker and then it's the next person's thorn and then the next person's thorn and let everybody have their goal. And I think that's one of the biggest challenges with the stand up. It's a very effective thing even in a normal project. It's a very effective.

John Byrne [00:12:40]:

In a waterfall project. The stand up can still work very well if everybody sticks to what it's actually intended for.

Dante Healy [00:12:46]:

Yeah, I think group meetings are great for collaboration and alignment, but they shouldn't be hijacking everyone else's time because you have people who've delivered their updates at the start and they're just listening to all this blurb about stuff they're not working on and they're not really interested in because they have their own job to do and it's just tying up their time, especially if it overruns beyond the 15 minutes. So that's not efficient. Then again, Agile was never meant to be efficient, it was meant to be effective. Focus on the right things, deliver value. But if you're focusing too much on rituals and for the sake of optics, then you're missing the point of why those practices were put in place.

John Byrne [00:13:30]:

And in that situation, even then, you're not even focusing on the ritual, you're focusing on the naming convention. They're calling it a stand up but you're actually having a, a team update meeting. That's not, that's not what a stand up is. No, they're two different things. But you're turning it, you know what should be a 15 minute, 10 to 15 minute stand up into a 30 to 60 minute team update meeting every morning.

Dante Healy [00:13:53]:

Yeah, yeah. Team collaboration workshop, problem solving, hackathon event. It gets crazy. And I mean that's just, that's, that's the obvious, shall we say, villain. But what other anti patterns are there? I mean for example, one I think which is more enterprise wide is when you actually implement an agile transformation. But it doesn't work and it's not agile at the end of it. Management and leadership don't really think about the context. Agile isn't suitable for every scenario and unfortunately it seems like what leadership want and what they're willing to sacrifice to try and make it work.

Dante Healy [00:14:41]:

There's that disconnect, right? Because what they think is they go for a workshop and it's agile consultants telling them all about the benefits of Agile. And unfortunately the behaviors and habits don't die, they just get a new label. Plus you've got a JIRA board to manage your project instead of a project tool. So you get project plans chopped into two to four week blocks called Agile managers. Still deciding, well, what do we do and how do we do it? Because they're still micromanaging the teams. You have reports and optics still driving behaviors. So people aren't really looking for outcomes, they're looking to make the optics and the metrics that they're reporting look good. And also you've got people who are finding that instead of being able to do the work, they're being burnt out on more meetings in order to show that you're doing Agile.

Dante Healy [00:15:45]:

And I think a lot of the time what's being sold to executives on Agile is faster delivery, more output, cheaper teams, predictable timelines and essentially plug and play productivity.

John Byrne [00:15:59]:

The other thing as well can be at times I've seen people rolling out Agile or the IT department, they love Agile. A lot of their projects would, you know, suitable to agile now, but somehow they've gotten the role of rolling out the pmo, you know, the, the program management office and deciding the tools and the things there and they decide they're going to do it. We're agile, we become an agile, you know, an agile company. But they're not actually IT aren't. They're not that they're very knowledgeable at it, they're not that knowledgeable of necessarily other, especially if it's not a tech company, if it's a company that has some other thing, they're not that knowledgeable and they don't really take into account that yet. The projects that the rest of the company are doing are not suitable to Agile and they'll be the one selling to the executives. What you just said. So it's actually going internally even.

John Byrne [00:16:51]:

It's not even an external Agile guru, it's the internal IT team. I'm blaming it because that's usually what I've seen. It's IT internally initiate Agile.

Dante Healy [00:17:02]:

And a lot of them are, should we say probably their backgrounds are more software product led, which lends itself to Agile. You know, exactly. You release something quickly to the market, you test if there's a market to be, to be got at and then you launch your product MVP and then iterate on top of that with a roadmap based on that customer feedback. And ideally you want a strong product owner who's commercially driven. But Agile is product led at heart. Most PMOs aren't product led, they're structured around delivering projects. And so when you go out Agile often they keep that project mindset which is managing to a fixed scope, fixed budget, fixed timeline. And then they try to bolt on that process of agile which is really more built around innovation, testing, iterating and then off the back of that continuous learning and delivering value, which is commercial value in the market.

Dante Healy [00:18:07]:

Whereas IT often if you're a corporate, if you're an IT function to a corporate business, your, your customers are your users and they're your employees, not the market itself. And it can work if you're delivering fast products to serve your employees, but it shouldn't be the be all and end all and a lot of these systems, they have bigger issues and you have dependencies, you have integration, you need architecture, you need some form of design and you need a plan to make it work and also show progress in a way that is more about key deliverables rather than MVP and then iteration because there's too much at stake. If something fails it could slow down your organization and it's not the ideal situation where you're set up to fail. You can't afford to fail usually in project.

John Byrne [00:19:08]:

I think one of the things there that you just mentioned you went through the Agile process, the end piece where you've gone live the small iterative improvements. You almost basically described the old Kazon mindset. I think that a lot of companies that decide they're going agile, that's the bit that they're looking at. They're not really thinking through all the bits before it and that's where they fall down that they're not really agile but they're trying to force. Yeah, it's that don't suit their company on in order to get to that end bit because they rather than just saying well no, we'll just do Kzon, we'll just do the end bit there, you know, we'll continuously improve in small things. But they try to then force that through all the project work throughout the whole business which a lot of businesses, unless they are software driven businesses, doesn't work.

Dante Healy [00:20:03]:

Yeah. And what if you're looking for a Kaizen and continuous improvement then you're not looking for Agile, you're looking for Lean.

John Byrne [00:20:12]:

Exactly. That's it. Exactly. And we could have another episode on Lean that it's kind of become another bit of a buzzword that people just, you know, they don't really think is suitable. They just try to force it in, in every situation and yeah, but that's, that's certainly where Agile is, is suffering at the moment. And there's a little bit of a backlash I think some in some places because people are saying Agile is not good or not not effective. You say no, it is just a set of buzzwords.

Dante Healy [00:20:43]:

That's what people perceive it to be. Yeah, buzzword for being. For covering up the fact that you're ineffective. But that's not the case. And to be honest, I mean I mentioned, you mentioned Kaiser and I mentioned Lean that you're looking at the wrong thing. But they're not necessarily mutually exclusive. Same with Hybrid. You can manage projects and you can have a product mindset.

John Byrne [00:21:06]:

Yeah, definitely. And I mean even within projects what you will find is there'll be a certain amount of both. I mean, I do systems implementation, so I can think of a clear example where you may have a team operating with a true agile methodology in the middle of a waterfall project. Some only require configuration, but others you may have to do a little bit of development for of specific software development to write a piece of code that's specific to something that you do that the system you're putting in wouldn't normally do. Well then that team writing the code is probably better off using an agile methodology because they are actually doing software development. They just happen to be within a larger context of a waterfall project, but they themselves aren't waterfall. They'll get a minimum viable thing that we can slot into our thing and then they'll continue to iterate and improve that MVP while we're still working on the overall thing that's only a part of. So, you know, hybrid and mixed methodologies and that do work, but that's the key thing.

John Byrne [00:22:15]:

You need to use the tool and the methodology to suit what it is you're trying to achieve. Don't try to force what you're trying to achieve to fit into the methodology.

Dante Healy [00:22:28]:

You'Re shoehorning it in. Yeah, yeah.

John Byrne [00:22:30]:

And I think that's what a lot of people do. They pick a methodology or a framework or whatever you want to call it and then try to force what they're doing into that. And you think, no, it's the other way around. What are you trying to do? Now you find the methodologies and the frameworks and the tools to suit that.

Dante Healy [00:22:44]:

And you find also what tends to happen when organizations try and implement a transformation. They basically just call their project managers Scrum masters. And you know, it's all about renaming business analysts become product owners, but nothing about their work changes. They still work as they normally do. They create a business requirements document, they convert it to a test technical specification document, they start creating a test plan. But it's all about end to end. It's sit, it's uat and it all has to happen at once. It's not about building increments of value in small chunks and then testing the market.

Dante Healy [00:23:31]:

It's actually a system implementation which you can't just cherry pick Agile and put it on us on, on a Kanban board and, or a Scrum board. You need to have the holistic view to make sure that things to get the context of whether things are on track. Otherwise you just could just be running around in circles as a team.

John Byrne [00:23:54]:

And I think that's yeah, that's it exactly like, like the Kanban board as I mentioned. No, I've seen them being used and people think because they're using it, they're doing agile and you think no, you know, you're using it just to visualize what you're doing and where it is in the process. But there isn't actually a clear flow management, there's no work in progress limits, there's nothing. True Canva. You're just using the board as a tool to suit your team. Which is fine. I mean I've done it. I am actually in the currently doing it.

John Byrne [00:24:29]:

I do use a Kanban board to visualize a certain things, but I'm not doing agile, I'm not using it, it's not Kanban. I'm just using the tool and I'm rejigging it a little bit to suit my needs. And then the same with the, you know, I've got a very brief Gantt chart which it's not a project plan, it's just to give us an overview, I think, and using the, you know, so I'm not saying don't use the tools if you're not doing agile. I'm just saying don't, don't claim to be doing agile just because you're using the tool. I think that's kind of in keeping what you just said there about the way people were using things. Cherry picking.

Dante Healy [00:25:11]:

Exactly. I mean you can have a board, you can have blockers on there, but if you, if you're not able to understand which blockers are actually impacting the overall timeline because you can't see a critical path or you see our blockers, these things could be holding up everything like literally months of work and they're just hanging on indefinitely as unresolved items because they're outside of the team to solve, if that makes sense. So as you say, it's cherry picking. Some of it is actually removing the dependencies. And I think Scrum, when we talk about Agile, Scrum works best when you don't have too many dependencies that the team can work on things and deliver things independently. But in a real organization, especially large corporates, you can't avoid, you can't afford dependencies, for example, even things like setting up your development environment, all of your digital resources, your servers, et cetera, getting security accesses, getting rights permissions, even you know, requesting integrations out all requires collaboration. And you can't, you know, to try and implement a digital tool that hooks up to everything. So that makes sense I guess moving on to Agile myths and misunderstandings and I suspect we've covered quite a few our myths and I guess John, you've probably heard that agile, you mentioned that Agile means no documentation, usually no planning and moving fast at all costs.

Dante Healy [00:26:55]:

But as, as we've called out, it's usually lazy thinking that leads to lazy and weak delivery. So I guess I'd say just, just.

John Byrne [00:27:05]:

On that, I don't think that's what Agile is, but I do think that's what a lot of people when they do that claim. Oh, that's because we're agile.

Dante Healy [00:27:13]:

Yeah, exactly, exactly. And it's a cop out. But. And you know, I think we have to admit that there's been a lot of misuse of the MVP concept and also chasing story points for optics and also when blurring the lines of when a person tries to be a product owner or a scrum master versus a project manager. And I think, I think there's a lot of confusion around what Agile actually is because what, what you see, and we covered it in an earlier episode, is it's misapplied. So I guess, you know, what are your, what are your favorite misbeliefs based on what you've seen about Agile and what do you think people get wrong?

John Byrne [00:28:05]:

I think one of the key ones is like we mentioned there, and I think we said it in our last thing, it's the documentation that people tend to think Agile means no documentation. And that's not what Agile means. It means you just enough documentation so you're not doing like a full on. But then again that's a little bit of lean, you know, almost, you know, if you do print two project management and if you just look at the, all the text, you know, there's a huge amount of documentation that's the other.

Dante Healy [00:28:33]:

End of the spectrum, you know, called documented to death. Your job becomes full time documentation.

John Byrne [00:28:39]:

That's it. But then again, when you look at prints the way it says it, prints two the way it says it, you're actually not supposed to use every single one of those documents. You pick the ones that you need for your project and Agile just takes it a little bit more extreme. So Prince, there will be certain documents that you're supposed to use for every project, whereas Agile will kind of say no, there's no particular document you need to use for every project, but there is a certain amount of documentation you do need to use in your project. Figure out what that is and keep that documentation. It's slightly different to what's in Print. But I think some people take prints to the extreme in that they, they try to use and force every single document that's in their template folder and use it. And you think, well, most of these you don't need it's repetition.

John Byrne [00:29:28]:

These are, some of these are actually options. You do A or B, you don't do both. And then with Agile though, it's the other extreme. It's people just do no documentation. We'll wing it, we'll have our daily morning meeting and that will keep us all aligned. We don't need a document to keep us aligned and that's it. And I think that's, that's probably, from my experience, that's one of the biggest misconceptions of it, that almost immediately when somebody says we're doing an agile thing, I can kind of say, so I take it that means you've got no documentation done whatsoever. And I'm usually right when I say that.

Dante Healy [00:30:04]:

It's right and it's harsh. I mean, I think the problem and the other misconception about Agile is which you've, you've hit the nail on the head is we cut corners because we're going to move fast over doing things correctly. And then you find there's a huge amount of rework that just becomes a disorganized mess at the end. You know, leadership will equate Agile with speed to market and not about sustainable delivery. So there's going to be massive amounts of rework. And one thing that I guess misapplied Agile ends up doing, which actually goes against one of the main principles of Agile, is ignoring technical debt. So you have teams that look busy this, they're closing out JIRA tickets, they're doing things, but they don't, they don't understand really what's, what's happening. They don't really, they're moving about, it's busy.

Dante Healy [00:31:03]:

But you know, you count steps but you're still not, you're not, you're not getting closer to your goal. And that's the problem is if you skip, you skip documentation. One of the biggest, most critical documents is having a plan. So if you skip planning because you think, oh, we'll figure it out as we go along, you, you're not actually making progress. And in fact, if you have a ticket that needs to be closed out, but it requires planning in order to do it because you need other teams involved, then you mark the ticket as blocked, but it shouldn't be blocked because you just miss the step where you need to plan. Before you can actually deliver, you need to get everything aligned and organized.

John Byrne [00:31:49]:

I think that was a brilliant description there that you just gave of what I think people that I've come across have misconstrued Agile with making it up as you go along. I haven't thought about phrase before whenever I've been described but that sums are perfectly. The biggest problem with Agile is making Europe as you go along and thinking that means you're agile. That's what agile. It's still need a plan, you're just not running it as a waterfall project.

Dante Healy [00:32:17]:

And yeah, that's the other thing. Some people might even say we're a lean team when they say we avoid documentation. But how can you not document? Where's the accountability? Where's the agreement?

John Byrne [00:32:30]:

Lean doesn't mean that you leave things out. Lean means that you just put you leave unnecessary things out. That's what lean means. But it doesn't say that everything is unnecessary and in projects, especially documentation. Not different extremes for different people and for different projects. But lean just means you don't put the unnecessary stuff in. And agile would be a lean, a very lean thing but it still requires documentation and in fairness even waterfall now I mean the most document oriented one is Prince who that's why I keep mentioning it. But even Prince two it's Liam.

John Byrne [00:33:08]:

You know they're saying don't use everything, pick the bits you need.

Dante Healy [00:33:12]:

Yeah, yeah, it's like a menu. And the problem is if you skip documentation and things go wrong, no one knows why it's gone wrong because you haven't documented what you've done. So no one knows why a decision was made. We decided to go one way but it didn't work and now we don't know why we decided that one way. So we'll just faff about and figure it out until something eventually does work or we run out of cash and then you can all you can just applaud, say congratulations, you've moved fast and you've completely broken the context. And that's the problem with these anti patterns. One of the biggest ones is shortcuts that are labeled as being agile. So you focus on really not what we've delivered but how fast we got stuff out.

Dante Healy [00:34:01]:

You ignore technical debt because you think we'll just tidy up later and that no documentation Agile, we don't do documentation, we're agile.

John Byrne [00:34:12]:

And then you've got things like, you know, we don't have to worry about scope because we're going to be running sprints and we do the backlog and all that. I think, yeah, that's great. There were 10 things that we wanted to achieve. We've done 10 sprints and we've achieved two of them. Is that really successful? We did 10 sprints. We're on. You know, we got through as much of the back of the, of the backlog as we could, so it was a success. And you kind of think, yeah, but if you actually had the documentation and he's done a bit of planning, you probably would have got through all 10 of those items and you'd had a halfway through your sprints that you'd have still had five sprints left to go and you could have put new on.

Dante Healy [00:34:52]:

At the end of that 10th sprint. Congratulations, you got half an MVP because you still can't release it to the market. You're not ready. So you've just wasted a whole load of money on learning that you're actually disorganized.

John Byrne [00:35:08]:

Yeah, it's not agile. It's disorganized because agile is actually expensive. Extremely organized doesn't work if it's not organized. If you are making your ups to go along if you're not organized, if you've got no idea, no plan, agile will not work for you.

Dante Healy [00:35:23]:

And that's a risk. I mean you can't train a Scrum master on a two day grandmaster course and expect them to be mastering delivery. You're just confused. Technical teams, they'll just be probably doubling down on the Scrum guide because that's what they've learned and that's what they trust. But they don't have the context. They don't, they can't match it to the organization or the team. They can't match it to the goal. They don't know the size of the challenge and they don't know what's coming around the corner.

John Byrne [00:35:54]:

And to be honest, a lot of this you almost can't. How do I say this? Okay, there'll probably be a few people who disagree me and you might be one of them when I say, but I honestly don't think you can make a decision upfront about a project going to do this as an agile project or I'm going to do this as a waterfall project until you've done a bit of planning and lined out what needs to be done and then you can decide and this is the best methodology fit to deliver according to our plan or need. I think, you know, as you mentioned before, sometimes we think it, the Sprint goal is to just to deliver something regardless of whether it's the right thing or not. And no, that's not what a sprint goal is. Sprint goal is to deliver something useful to the end goal.

Dante Healy [00:36:42]:

And that's the problem. If you're not aligned with the sponsor's vision, you can't, you can't, you can't plan, you can't even come up with a strategy because you don't know what's needed. You have to do that gap analysis. Right? Vision will be where we want to be in the future. What outcomes do we want? You've got your present state and you've got your future state. What are the capabilities we need to be able to effectively deliver the vision? And it's that gap you have to try and reconcile and bridge through the plan. So, and that's organization in a nutshell. It's not about coming into a delivery development team, giving good vibes and a little bit of facilitation and not any actual leadership.

Dante Healy [00:37:32]:

People need to be organized, they need contact and they'll have different views on things and they'll know what works, what doesn't work with their specific sets of skills. And you don't have to be an expert, say software developer, but you need to understand technology. If you're managing or leading a technology team. You need to be able to smell if something is wrong and you need.

John Byrne [00:37:55]:

To be able to assess what is the best way to deliver this. And if all you've done is a two day Scrum master course, then that's all you know. You'll try to force that into every situation, even when it doesn't apply.

Dante Healy [00:38:09]:

You'll just be a really bad project manager using JIRA instead of project Planner. You'll be assigning tasks, you'll be tracking tasks, you'll be, you'll be looking at the deadline saying, this was our goal at the start, this is what we delivered at the end of the two weeks and this is what we haven't delivered. We failed. And then morale drops. Rather than understanding, well, what's the underlying problem? Was the plan wrong? Was the goal wrong? Are the team properly aligned? Do we have too many external dependencies? And if you know what you're doing, you can actually support the team better by managing expectations between the team delivering and the leadership who are funding the team, who are expecting certain outcomes and saying, well, are they realistic?

John Byrne [00:38:55]:

And that's, that's one of the issues as well. You know, this is, this is what our ultimate goal was and we failed, we didn't get to it. And you kind of think, yeah, but were we Even taking the right steps in the direction of it. And what you find is a lot of the time when people don't really know what they're doing. They've got the two day Scrum Master certification. Yay. And they've done it with no planning or not. And when you actually look at what they've achieved in the sprints, they achieved a lot of steps but these steps were going in a different direction.

John Byrne [00:39:23]:

They weren't never going in the right direction because they've no plan, they taught no plans needed. We just do iterative.

Dante Healy [00:39:30]:

We got the backlog, we've got to just refine the backlog and then you're into doubling down on. Well, we didn't do Agile properly or the backlog refinement was wrong, the product owner wasn't available or they didn't give good guidance. You can, you can come up with all the team team dynamics weren't good. And then you're looking for scapegoats and that, that is an anti agile pattern, you know, undermining psychological safety of your team because your position's at threat.

John Byrne [00:40:03]:

That then leads to a downward spiral and that's. There's no recovery then there's no point in adding more sprints on or replacing team members or adding to team members or anything like that.

Dante Healy [00:40:15]:

At that stage the Scrum Master has to come to the conclusion that ultimately they've become the impediment.

John Byrne [00:40:22]:

Yeah. And the key thing was because they used the idea of Scrum and Agile as a shortcut rather than as a methodology to deliver a planned outcome.

Dante Healy [00:40:34]:

Well, let's try and find some positivity. I feel like it's all a bit bashing Agile and I love Agile. I'm the Scrum Master, I'll say that.

John Byrne [00:40:44]:

No, I mean I think in fairness now most of what we've said has been bashing the misapplication supplying Agile Agile itself. As I said, I think it can be a very powerful tool in the right situations and it should be used in the right situations. And sometimes it's not waterfall or agile. Sometimes the two do actually mel real well together.

Dante Healy [00:41:09]:

For certain projects you can do a hybrid of the two. Like you can have a JIRA board with your backlog, but you can also build a critical path analysis. You can track dependencies in jira. And I do, I do some funky workarounds to create Gantt charts from the project from the tickets in the JIRA board. But that's. Yeah.

John Byrne [00:41:35]:

And even within big projects that, you know, a big waterfall project can have certain sections where certain teams are running as an agile environment because what they're delivering is a little standalone from the rest of the team, but so they'll deliver a fixed product, a finished or an MVP that will fit into the overall project. So they're operating because they're doing software development, they're operating in their agile environment and as part of a larger thing. And I have used it that way before, I just don't get hands on with managing them. Usually there's a team lead who's just really good at agile methodology in that environment because it is what they use day in, day out for all the project. And don't try and force that change if you don't need to facilitate that to fit inside your waterfall project. Doesn't quite work the other way around that the overall project is an agile project. Having a small waterfall element probably doesn't fit in quite as well, but I suppose I've never come across one. But I suppose that might be examples where that does work.

John Byrne [00:42:43]:

But no, Agile is a good when it's used in the right circumstances and when it's used actually properly, not just as a buzzword or being forced into a situation it doesn't really suit.

Dante Healy [00:42:57]:

Yeah, I agree. It works well when it's applied intelligently and you don't get, you don't get lost in all these shiny tools, especially some of these whiteboards. Collaboration, it's great. And when it's skillfully applied, it works really well, you know, so for example, you, you're working remotely, you start drawing, I don't know, process charts and diagrams on a whiteboard, you start logging tickets, you start brainstorming and you start voting on things. Facilitation is, is valuable, but I think plenty of teams focus too much on ceremonies and also process discipline. Logging every ticket, updating the tickets every day, which, to be honest, I'm, I'm not against that. I love that because it makes my job easier in terms of doing less admin, because you're getting it directly from the team. But also obsessing.

Dante Healy [00:43:56]:

I feel like sometimes there's something about chasing the wrong metric and obsessing over optics rather than outcomes. So there's this idea of velocity theater. I mean, agile theater. And the theater is really trying too hard to make the metrics fit the ideal narrative rather than tell the truth and be transparent. And I think when, what happens when leadership say yes to Agile, what they're still expecting are fixed timings, sign offs, formal sign offs before things go live, and also weekly process Progress reporting. And that's where this whole theater falls apart because you still have to accommodate the executive sponsors because it's still projects. Ultimately our leadership still expect to see some degree of governance. And I think Agile isn't about.

Dante Healy [00:45:00]:

You can have self governance within your team, but within the organization you still need a little bit of accountability and reporting to the people that matter, the people who are funding it and the people who have an interest in it. So I think that's pretty much it. I mean in terms of tools, obviously we've mentioned JIRA a lot, but there are other forms of Kanban boards, digital Kanban boards. I've heard a lot of good things about Monday.com but I wonder if it typed. One of the things I don't like about JIRA is they charge too much. But that's not nothing. That's not an anti pattern. I think it's more of just an observation.

Dante Healy [00:45:42]:

But I guess in terms of, in terms of process discipline, the most important thing about Agile is getting the feedback and the right feedback loops so you can, you can understand, learn and adapt your behaviors. Right. I feel like retrospectives don't get enough, they don't get enough love. And I keep hopping on about retros but if they're done well, it's a powerful tool for improving performance. And this is an anti pattern. When you do a retro and you make sure the retro is done so you can tick the box but the retro itself isn't performed well.

John Byrne [00:46:19]:

And that can be the other side of it. There's the one where people are using it as buzzwords but not actually doing it. And then there's the other one where people are technically doing it to tick the boxes but not actually looking at the value they're getting from doing it. Not not doing it. Right. Said you can. We did a retro and we ticked the box up. We did a retro but we didn't actually take in any of the information from the retro and we didn't learn from it.

Dante Healy [00:46:48]:

We just carried on as normal. Yeah, we just did it. We had a great discussion but nothing changed.

John Byrne [00:46:55]:

Which, which is similar in a way to. I think we discussed the previously and normal in Waterfall Project. The lessons learned. We've collected all the lessons learned and we filed them away and they'll never be looked at again. The difference being with the retro, we didn't even file it away. We just.

Dante Healy [00:47:14]:

Nothing was document. We just had. We had a coffee chat.

John Byrne [00:47:18]:

Yeah, that was it exactly. But we ticked the box because it was a retro coffee chat.

Dante Healy [00:47:25]:

It was A structured coffee chat it is though.

John Byrne [00:47:29]:

It's good like those things but as well people to know that the tools are just tools that can be used for anything. Using Jira does not mean your project is agile, doesn't mean you're agile, it doesn't mean you're using agile, it means you're using Jira. If you're using Agile, Jira can be a very good tool to help you use Agile. But using Jira doesn't mean you're agile. And same with Kanban boards. It's the same actually. Even when you do normal project management, waterfall project management using Microsoft projects does not mean you're doing a good waterfall project, just means you're using that tool. So that's a key thing.

John Byrne [00:48:10]:

If you're not doing an agile project, don't think, oh, I'm not using those tools, they're agile, they can be useful in other situations. But if you are looking to do an agile project, pay attention to what you're actually trying to achieve with an agile project. Don't just assume, well, that means these are the tools that we're going to use and that's it, we'll use them whatever way we feel like using them. Now there are certain ways to use those tools in an agile setting. The tools themselves are very well in an agile setting. But if you don't know, if you haven't got an agile setting, using those tools won't make you agile.

Dante Healy [00:48:44]:

Exactly. And at the end of the day you can see software is just, you know, it's just an enabler. It's not the be all and end all. And yeah, it can have some very good features like roll up, reporting, reminders, notifications, but pretty soon they can be quite irritating as well Teams. They can be actually a blocker if it's misapplied.

John Byrne [00:49:11]:

I think a key thing is, you know, if you're learning number one, an agile thing is not, as we've said, it's not just maker up as you go along. There is a skill set to being an agile project manager, Scrum master, whatever you want to call it. Technically, slightly different things, but there is a, there is a, there's a learning curve. You need to learn how to do it. But it's not just a matter of following a checklist. You need to know why, why are you doing, what's the point of the stand up? If you know why you're doing the stand up, what the point of the standup is, then you won't let it turn into a regular meeting Trying to come up with solutions to blockers, you will stick to what it is for. It'll be nice, quick and efficient and it'll do exactly what it's supposed to do and it'll allow you to follow up. Why are we doing things on a Kanban board? How's the Kanban board supposed to work then? You can use a Kanban board in an Agile setting because you know why you're supposed to be doing it as opposed to just ticking a box that, well, we're using a Kanban board, Various things like that.

John Byrne [00:50:20]:

You know, when you're, when you're, do a little bit of study. If you're thinking of, if you're a project manager and you're thinking of getting into doing agile projects, read up on plenty of, you know, resources on Agile. But don't just read the, the, you know, an Agile. What was, what's the, what's it called?

Dante Healy [00:50:40]:

The Scrum Guide or the Agile Manifesto?

John Byrne [00:50:45]:

Yeah, manifesto. That's the one I was thinking of. Don't just read the Agile Manifesto and think, oh, I just tick these boxes on I'm agile. No, read it. Fine, figure out what's the point. Why are you doing these things? Why are they in the Agile Manifesto? Because that's what you actually need to achieve. Not just ticking a box, it's achieving what they want. So make sure you understand that before you try to turn everything that you do into Agile.

Dante Healy [00:51:11]:

Yeah, I think don't get overly, overly focused and obsessed over process. I remember. What was it? A month ago I posted something which was actually very popular. It was actually off the back of our episode on Misapplied Agile and it got quite a lot of engagement. But some, I mean, I posted something that was satire and people misunderstood it and thought I was having a rant and funnily enough, people were trying to dig into the content and what I was trying to communicate was about messy delivery. But I had scrum masters and experienced agile consultants talking about how I got the roles mixed up because I like I gave the analogy of a rugby scrum and they said, well actually the scrum master shouldn't be on the field playing, they should be the team coach. And I was like, come on, you're missing the point. You know, it's not about roles, it's not about process, it's not, it's about the mindset really.

Dante Healy [00:52:22]:

And the mindset is risk management through fast feedback loop. So I think you miss the point ultimately when you're thinking about applying techniques and misapplying techniques. The pattern. The problem with an anti pattern is you think it's going to be a solution, but it won't solve the root cause of the problem because either it's the wrong problem you're solving or you've got the wrong solution. So I think, I think that's the biggest issue is Agile isn't about frameworks or methods or tools. It's about the mindset itself. That's where it works, is being flexible, getting feedback, being aware and adapting. So I guess that was pretty good.

Dante Healy [00:53:13]:

John, any, any key takeaways from your side?

John Byrne [00:53:17]:

I think I've said them all. I won't push me luck because as I said at the beginning, I'm not. I don't tend to use Agile too much in my projects, so I hopefully haven't made any glaring errors. But I'm sure if I had, you would have flagged me up on it because I do know you are somebody who uses Agile quite a lot in your projects.

Dante Healy [00:53:37]:

Yeah, I've. I've been passionate about Agile since I came across it actually 10 years ago. So happy anniversary. But yeah, Agile isn't new and it's not meant to be about following a script or a checklist or a process. It's about that mindset shift for better results. I think the problem is somewhere along the line people latched onto it and started obsessing over the method rather than the outcomes it should bring. So we're leaving you with this thought. Are you waiting for outcomes or just hiding behind the ritual? And if you've seen these patterns and you want to do something about it, follow this show subscribe to our email list I'll share the links in the show notes where hopefully we'll be able to deliver you extra insights, tools and possibly some future workshop depends on.

Dante Healy [00:54:40]:

But yeah, feel free to reach out and with this final thought, let's stop performing Agile and start delivering value. Thanks for listening. 

John. Thank you for sharing.