4 Signs You're Doing Agile Development Wrong

Agility is the ability for development teams to respond quickly, deliver value sooner, and change your product along with changing customer needs and market opportunities. Implementations of agility vary widely, but we see a common problem: Most organizations, at least initially, get mired in the details of various Agile techniques. They start implementing a new framework, such as Scrum, and soon they're spending a lot of time and energy discussing the intricacies of pair programming, test-driven-development, or the mechanics of a Sprint Review. We lose the forest for the trees. 

Here are four warning signs that you're taking your eye off of the big picture and are at risk of not getting what you need out of "this Agile thing":

 1. Failure to "get done"
If it takes you longer than a few weeks to turn an idea into a ready-for-production feature, you are not Agile -- full stop. You have to be producing completed, working, tested, potentially releasable product every few weeks.

[Has the original intent of Agile been lost? Read The Corruption Of Agile Development.]

No need to read any more of these warnings, because getting to "done" every few weeks is the basic building block of Agile teams. Without this capability it is very expensive and likely just not possible to respond quickly to changing customer needs.

The biggest culprit causing this problem is, "We use Agile techniques for development, and then do all the testing at the end." While I'm sure that improves your development practices, this still misses the mark of being Agile. Agile teams should include testing and everything else that has to be done in order to make the product shippable as often as possible. Agile drives all the risk of product development into each short iteration, and allows for an empirical process.

 2. Failure to launch
If you haven't actually released your software to production -- and on to customers -- for three or more months, you are missing the big picture.

Once the organization masters getting to "done," the next challenge is convincing folks actually to release the product to customers earlier than they've typically wanted to. The "we must have all the features" mindset is pervasive among traditional product managers and executives, and it's a trap. Waiting until all the features are complete compounds market risk at a high rate.

Look at it this way: If getting to "done" limits the product development risk to each iteration, then actually releasing to customers early and often limits the market risk overall. If you release a version of your product often, you can test the market often and make changes as needed. 

I once worked on a project involving over a dozen teams and hundreds of people creating a cloud-based data-gathering and control system for efficient energy use in buildings. We were able to get to "done" every few weeks, and were doing a great job producing exactly what was asked of us. However, the business decided not to release the product for over a year, and by the time it did, it discovered there wasn't really that big of a market for the product. What a shame -- we could have discovered that after only a few weeks.

 3. Scope stagnation
If the features you set out to build are the exact ones you end up building, you're not getting all that you can out of Agile.

It's hard to get honest feedback on the product, and it's hard to hear it. This is exactly the point. Agility accepts that we can't possibly know everything up front, and so the best way to create the most valuable end product is to get that product into users' hands as quickly and as often as possible, and then listen to them. Gather market data, get individual feedback, and change up the features in the product. This is what Agility is all about.

I distinctly remember a project building a mobile app where the end users gave us excellent feedback. Every few weeks we got to "done," showed them our product, and released it to them if they wanted. However, their feedback for new and different features clashed with what management thought we ought to be building, so we never had the support to change the scope of the project. We had the users telling us exactly what they wanted -- this should be project management nirvana -- but it was blocked by locked-in scope.

 4. Unhappy developers 
If the people in product development are unhappy, something's wrong with your Agile process -- and it's probably one of the three points above. 

Getting to "done," releasing something to users so we can actually see it in use, and building products that customers love are hugely motivating for people who love to develop products. The many short feedback loops built into a highly functioning Agile product development environment feed this motivation and keep employees engaged in their work and happy. 

If people aren't happy with the state of agility in the organization, something just isn't quite right. Happiness is both a goal and a symptom of a modern Agile business. Grow a culture where the people doing the work are central to the organization, and carefully feed this system to keep people happy. Happy people build great products.

Can the trendy tech strategy of DevOps really bring peace between developers and IT operations -- and deliver faster, more reliable app creation and delivery? Also in the DevOps Challenge issue of InformationWeek: Execs charting digital business strategies can't afford to take Internet connectivity for granted.