Breaking Free From the Cult: 6 Reasons Why Agile Doesn’t WorkWritten By: Talia Fukuroe
Jan 24, 2013 • 12:09 pm 11 Comments
For the last six years, I have been trying to create a real, true Agile environment. I’ve gotten teams together and tried to follow the rules, doing everything “right” to achieve true Agile productivity. I’ve tried. My coworkers, colleagues, and fellow program managers have tried too. At this point, I’m ready to call it. Agile doesn’t work. Not like they say it will.
Technically, I’m talking about Scrum, which is just one method that falls under the official “Agile” umbrella, along with Extreme Programming, Kanban, and a few others. But whenever I hear people say they “know Agile” or “follow Agile”, this is what they mean: fixed-length sprints, standups, product backlogs, estimations, burndown charts, retrospectives, etc.
I’ve never successfully managed to get a team to follow all the rules of Agile, nor have I seen or heard of such a team outside of case studies during Agile training. The teams I worked on had plenty of successful projects. They just weren’t “Agile”, and that part felt like failure. At first I thought it was me. Then I thought it was the team. Then I thought it was the company.
When I joined Impermium – an early-stage startup, a small team of brilliant, motivated engineers, and no existing (codified) development process – it was a pristine environment, the Program Manager equivalent of fresh powder. Surely, if there was a place to achieve Agile perfection, this was it. And yet, Agile was still impossible to follow.
So now I know. I’ve tried it. It doesn’t work. Here’s just a few reasons why:
1. Teams are never co-located. Agile says you need to have teams all in the same place. But somehow, they’re always split – between the Bay Area and San Diego, or Bangalore and Stockholm. Even Impermium’s original 4-person dev team had an engineer in India. The whole point of modern communication technology is so that people can be physically apart, but still in touch. Someone works from home. Someone used to be here, but moved to Portland. You have to be able to deal with people not being face-to-face.
2. Sprints are never locked down. Despite all the talk about being able to accept change, Agile is built on the idea that each sprint itself is fixed. Unfortunately, the real world always intrudes. Per Agile, when faced with new requirements mid-sprint, you have three choices: the first choice is to say “no” and hold it off till next sprint. Ever met a Product Owner with an urgent new feature, who’s willing to wait 4-6 weeks till the end of next sprint? Me neither. Next, Agile says that if you genuinely can’t prevent a new requirement, you have to terminate the sprint and start a new one. I’ll tell you a little secret: nobody actually does that. It’s too costly. Finally, theoretically, you can trade out other requirements from the sprint to make room, but it’s never that simple either. Usually there’s no way to accurately say, “If I have to do X, it will mean you don’t get Y.” The best you can do is put the new requirement on the top of the list and make sure the things you don’t get to in this sprint are the ones that were lower priority.
3. Estimations are a waste of time and send the wrong signal. Engineers can spend hours estimating a task, but with so many inherent unknowns, the estimate will still be unreliable. And if the team decided that something was a small task, but it turns out to take a long time, how does that reflect on the engineer working on it? How does it make them feel? How does it make others see them? Not exactly the environment you want for a happy, productive team.
4. “Velocity” is a unicorn. Things are never the same from sprint to sprint: there’s a holiday in the middle, someone takes a vacation, or gets pulled into debugging production issues. Even if everything else were perfect – spot-on estimations and no mid-sprint requirements – you still wouldn’t be able to accurately compare productivity from one sprint to another.
5. User story format is awkward and heavy-handed. “As a ___, I want ___, so I can ____.” The concept is good – there should always be an explanation of “why” the task is desired, to make sure the end result fulfills the actual need. But the amount of verbal gymnastics I’ve seen people go through to try to make a simple and obvious requirement into a “User Story” proves that despite what Agile says, it’s not always the best way to go.
6. Physical sprint boards just don’t cut it. Of all the things on this list, this one makes me the saddest. I love the sprint board. I love the multi-colored post-its, the visual picture of where things are, the tangibility of physically moving a task to “Done”. But sprint boards are a lot less appealing on days that I work from home and can’t actually see them. And user-story post-its can’t hold the comments, info, and history around a task, so you always need some kind of software too. But then you have to keep them both in sync. The engineers won’t do that – they (rightfully) say, “It’s already online. Why would I write it down too?” So you spend 20 minutes a day just making sure that both “truths” agree with each other. Yeah… I can never keep that up for more than a few days either.
Don’t get me wrong. There are absolutely good things that Agile has brought to software development. Iterative development and constant communication between Engineering and Product have become industry standards in modern software development. Agile has some great ideas, and is a vast improvement over what existed before it. But the zealots go too far, claiming that Agile can work for every team and every situation, and if those teams fail, it’s because they didn’t follow the rules strictly enough.
I know I’m not the first to come to this conclusion. What I have learned (and am still learning), is that the only Right Way is the way that works for that particular team. Using Scrum or Kanban as a starting point is great. But teams are made up of people, each one different. Companies that try to impose a single method of project management on every dev team in their organization will never get the productivity they’re looking for. The best, most effective way to manage a project is to do what works for that particular team, and recognize that it will be different for every single team.
Next week: What works for us at Impermium.
Talia is Impermium’s Program Manager. She is a planner by nature, and enjoys Getting Things Done. Her idol is Hannibal Smith from the A-Team. And just like Hannibal, she “loves it when a plan comes together. “