Agile Isn’t the Problem

Failed implementing agile in your organization? Agile isn’t the problem.

As a software development company that uses an agile approach, we have a lot of love for the methodology. We also hear a lot of newcomers to agile complain about it. It’s often treated as a scapegoat for more complex issues for your team.

If you’ve tried and failed implementing an agile way of working, the problem likely isn’t the system.

What is Agile?

To be clear, there are several ways of implementing an agile process. Many people believe agile is a software development process, when really it’s a management process that can be useful for any business. We’ve seen agile become commonplace in many industries outside of software development.

Explaining agile has been done time and time again. Agile in a Nutshell is a tremendous resource for learning everything about agile, from the basics to “advanced” agile practices. For this blog post, think of agile in its simplest form: taking an iterative approach to solving a problem.

“Our Company Couldn’t Adopt It”

If you read through “Agile in a Nutshell” or the “Manifesto of Software Development” and make a dramatic shift to an agile process, you’re gonna have a bad time.

There’s a wonderful book on UX and Customer Experience called “Think First,” by Joe Natoli, which is all about the strategy and planning behind UX. However, many of the principles from Joe’s book extend to other parts of business, such as management.

A quote from Joe’s book that stands out to me is “If you fail to plan, you plan to fail.” Frequently when companies approach agile they try to jump into the “deep end,” which only leads to frustration and failures.

Before you start your move to an agile process, create a migration plan around the movement. Start simple and try converting your backlog into well-written user stories. Decide on a template that makes senses for your team and begin converting the backlog.

Once your backlog has been re-written, start looking into the way your team estimates stories. If you’re not already estimating stories, this is a great time to start. Make sure you make note of the estimates for each story so you can re-evaluate how you’re pointing stories.

When you do those two things, it’s so much easier to dive into iterations, burndown charts, and all the other concepts of agile that make it so attractive. Just remember, if you fail to plan, you plan to fail.

“Agile Leads to Bugs”

I was once talking with an IT manager at a large financial institution. He manages a development team working on payment integrations, and he was telling me about a recent failure his team had. They released a new feature into production and it had dramatic side effects on legacy code. “I guess that’s what you get with agile,” he said.

The failure in this situation is the lack of proper definition, QA, and automated testing. While agile lends itself well to incorporating unit tests, continuous integration, and refactoring, many organizations see it purely as a “rapid release” structure for their code.

Agile is very effective at time-boxing things into tight iterations. However, just because there is a time box doesn’t mean you have to complete the entire feature in a single sprint. If a feature looks so large that it’ll take three or four sprints, that may be necessary. You may also be able to carve up that large feature into multiple small features and deliver one of those per sprint.

Agile does not mean “throw testing and documentation to the wind, we’ve got software to release.” Make sure your organization keeps sight of why you wanted to switch to agile: reducing risk and being able to adapt to changes.