I’ve met many people over the years who, once they learn I’m an Agile Coach, begin to tell me all of their bad experiences with Agile. Here’s a few (real) quotes from such conversations:
Agile? We tried daily stand-ups once, they were so boring.
We failed at customer satisfaction because we used Agile
My business failed because of Scrum. The clients didn’t get what they wanted because business people weren’t allowed to talk to the developers.
Retrospectives were useless, so we stopped doing them
Agile is, and never will be, a silver bullet for your organisational problems. It isn’t something you apply once and forget about. In these examples, Agile is being used as a scapegoat. Whether you use Agile or Lean or some random methodology you’ve made up for your company, it’s not the method that sucks, it’s your execution of it.
Let’s take a look at some of the above quotes again.
Agile? We tried daily stand-ups once, they were so boring.
The Agile Manifesto says nothing about daily stand-ups, but it’s one of the first things that come to mind when someone thinks about Agile. Nonetheless, they are a core part of Scrum and can be super effective if run properly. If you’re finding stand-ups boring, explore why that is. Are they too long in duration? Are people focussed or do they tend to ramble? Does everyone understand what other people are working on or is it a “status update” meeting that noone cares about? My bad habits post explores many of the reasons why stand-ups aren’t as useful. If you’re finding them boring, you most likely have at least one of these bad habits present. Work to remove those and remember what the point of a stand-up is in the first place: to track the workflow and raise anything that might impede progress to development. An effective facilitator for the stand-up is probably required in this case.
We failed at customer satisfaction because we used Agile
Why is this quote fundamentally wrong? Let’s go back to the Agile Manifesto, with the very first principle:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
If you were interacting with your customers do you really think they would not communicate their dissatisfaction? Or was it that you read this value and thought it was a “one time deal”? Remember, the Manifesto isn’t something you think about once and then forget about. If you really want to be Agile, then your highest priority is to satisfy the customer - keep this in mind with every decision you make. New feature? How will the customers use it? Developed something in iterations? The point of that is to get continual customer feedback loops that you can use to produce a product or service that the customer is actually going to use. If your customers are still not satisfied then you’re probably either not communicating with them regularly enough, or you’re not asking the right questions. Is this something that is going to benefit many of our customers? Is this something they really need or something they just think they want? How will it benefit the customer’s day-to-day life? It simply makes no sense to blame Agile for your customers being unsatisfied when this is the first principle at the heart of Agile!
Ok, moving on to my favourite quote of the bunch:
My business failed because of Scrum
Say whaaaaat?! Your entire business crumbled because of a methodology you were using to develop the software? Hmm, something doesn’t quite add up here. Let’s look at what actually happened: Was the entire business using Scrum? No. Was your entire business model focussed around delivering software? No. Were the business people and developers working together daily? Oh hold up, here comes the second part of this quote:
The clients didn’t get what they wanted because business people weren’t allowed to talk to the developers
Hmm, what does the Manifesto say about that?
Business people and developers must work together daily throughout the project.
No, your business didn’t go under because of Scrum, nor was it to blame for your clients not getting what they wanted. If Scrum in particular wasn’t working for you, why didn’t you try anything else? Once again, your execution of Agile sucked. But yet you claim it was responsible for the demise of your company. Yet, in this case, I’d bet that it was the offshoring of developers that dealt the killing blow: business people weren’t located in the same timezone or country as the development team, and nobody considered changing the working hours to follow-the-sun. So the business people had 3 hours in any given day to communicate their wants to the people developing the software, and product owners were located in the same office as the business people, thousands of kilometres away from the developers and Scrum Master. This isn’t to say remote working doesn’t lead to success—I know first-hand how powerful it can be—but Product Owners throwing user stories half-way across the world to a development team who then 1. had to comprehend what the story said and 2. didn’t have anyone on the business side to ask for most of the day if they didn’t understand the requirements was a recipe for disaster. And they weren’t retrospecting on that?
Which leads me to the fourth and final quote of this post:
Retrospectives were useless, so we stopped doing them
Now, now, I know I’m biased as retrospectives are my favourite ceremony, so let’s go back to the dear old Manifesto:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
OK, so you tried retrospectives, but they didn’t work for you, so instead of tuning your behaviour to find out how to become more effective (retrospecting on retrospectives!) you jumped ship altogether. Instead, in this case, the retrospective timeslot was used to berate the development team and tell them everything they did wrong. Congratulations, you just destroyed the morale of the people you’re relying on to deliver to your customers! But no, the “leadership team” can’t possibly be to blame, it’s all Agile’s fault.
In summary, it’s not Agile’s fault, it’s not the process’ fault. It’s your closed mindset and your inability to see that your execution sucks.
The takeaway from this: don’t use Agile as a scapegoat, instead try to open your eyes and see what’s really happening. Go back to the Agile Manifesto, as the root source of truth, and ask yourself for each of the values and each of the principles, one by one, are we actually following that? If you honestly can’t answer yes, then identify how to change that. What needs to change to be able to achieve the Agile values? And continuously reassess. You don’t become Agile once and forget about everything, you live and breathe it in the core of your organisation, it seeps from your pores and channels through to every person in your company. That, grasshopper, is when you know you are Agile.