I’ve written about Agile and Scrum before and most of my regular readers know that I am a huge fan. But recently I am starting to believe the Agile movement is doomed. In fact, the most common response to my enthusiasm for Agile and Scrum is, “Yeah, we tried that once and it was a complete failure.” Which seems odd to me because in every instance where I’ve been able to implement it, it has worked beautifully.
So why would I say Agile Will Not Succeed?
The buzz around Agile has become so loud that Agile has moved from strictly a software development thing, to all corners of the business world. And yet, as much as I believe Agile is the right way to develop software, as a movement, it is doomed for failure.
Why?
Reminder - Agile Isn’t a Method
This is the surest sign that a movement is struggling. It has become so popular that people are using it without knowing anything of what they are doing. The surest sign you’ve walked into an organization where Agile is doomed is if they say something along the lines of “We do Agile.”
Why is this a clear sign?
Because you can’t DO Agile. You can only BE Agile. Read the Agile Manifesto. There is nothing there about how to implement Agile. It simply isn’t a methodology. So, when an organization says to me they are “Doing Agile” it tells me right away that they have no idea what it means to be Agile.
‘Doing Agile’ for the Wrong Reasons
One of the outcomes of implementing an Agile process is that code tends to get developed faster. Unfortunately, this has become the main selling point of moving toward Agile. I get it, every shop I’ve worked in has been under some sort of development pressure to get stuff done. So it is easy to look at faster delivery as the main reason why you would use an Agile method.
But, speed is a side effect. In fact, it is only a long term side effect. Initially, as you move toward being Agile, you will probably end up being slower. You might have to lay people off because they only know how to work on their own while true Agile requires teamwork. The more mature your team, the harder it will be to switch.
So, if you shouldn’t move toward Agile because of speed, why should you? Well, two of the main reasons for me are: visibility, flexibility, and predictability.
I was once told the story of how plumbers plumb a new house. The first day they come in and hang all the pipes in hangers. By the time the owner comes by that evening, everything is hung and it looks like they are practically done. They now have two weeks to get it all soldered together before the owner comes by again. This is why most Agile methods require short sprints. The more you can show the customer the progress you are making, the less nervous they will get and the more likely you are to be left alone to do your job. However, it will take time because the customer has been burned too often in the past, so it may be a while before they learn to wait for the sprint reviews.
But there is an added advantage to being visible that is a huge win for everyone. By letting the customer see the progress you are making, he is able to make tweaks along the way. I’ve learned over the years that no one really knows what they want until they see it. But letting them see it often and make tweaks along the way saves me from having to do a complete rewrite when I am “done.” And agile adds predictability that isn’t available using older methods. It doesn’t let you say up front how long a project will take. Estimates are still rather futile. You’ll never know less about a project than the first day you try to provide an estimate. But, as you progress, you will know roughly how much effort the remaining project will take and how much time that much effort will take on average. The project becomes predictable using statistics generated by the project.
You Aren’t Fully Committed
In my last interview, I was asked if I had any experience with “Agile.” I really need to learn to qualify that question. I answered, “I have my Scrum Master certification, but I’ve yet to work in a truly Agile environment.” And yet, I have worked in environments that call themselves “Agile” But these are all environments that Carl and Richard over at DotNetRocks call “Scrum But…”. “Agile But…”? And at another place, we called it “Scrummerfall”. The idea is the same, rather than doing either Scrum or Kanban, they take the parts they’ve heard about that they like and merge them into what they are currently doing.
Of course, they weren’t fully committed to the process they were using either, so it shouldn’t work any worse. But it often does.
One of the most obvious points of failure is with project management. I’ve seen it all. Scrum masters who are still trying to function as project managers and organizations that have skipped the scrum master role and left the project managers. Stand ups that last an hour.
Or how about this one. Teams trying to estimate stories instead of task.
I went on one interview that had the following bullets in the job request I was sent:
- Must be able to work in an Agile environment
followed three points later by
- Must be able to work under tight deadlines.
Talk about an oxymoron! When I asked what “Agile” meant to him (the owner of the company) he said, “Oh, that just means we do iterative development.” Here’s the deal. If you are going to say you are going to implement Agile, at least learn enough about it to know what the word means! You might decide it isn’t for you. That’s fine. Doing something simply because it is the “In” thing to do is never a good reason to do something.
Management Has No Clue
In my current job, I was told that some boss several levels up who I’ve still not met has declared our project to be a “Waterfall project” because “we already know what this is supposed to do.” As soon as I heard that, I said, “Someone doesn’t know what Agile is.” Here is why this sounds right. The project I am working on is a rewrite from a very old platform to a web application. In principle, from that definition, it sounds like a known entity. However, simply because the GUI has changed there are things that were done on the old platform that make no sense on the new platform.
But it gets worse. The application is being expanded to include other business units with additional requirements. So, we only partially know all this is supposed to do.
If we were using true Waterfall, we would have to design the whole thing up front. This project is due in a little less than a year. Tell me what on the web doesn’t change in a year?
Agile Will Not Succeed
So, what’s the point? People love their perceptions. Not reality. What Agile set out to do was nobel, and for the most part, right. But people are lazy. They get a snippet of the truth here, a snippet of the truth there, ignore a snippet, paste in a snippet (here a snippet, there a snippet, everywhere a snip of snippet). And that becomes their truth, while not being THE truth. We do it with everything we believe. Agile has reached that point of group think that it can now be classified as “religion.” It now has so much group think weight that I’m not sure even those who started the movement can clearly articulate what it IS anymore.