If you're not getting what you want from Agile, these signs might explain why.

Erik Weber, Director, Agile Practice, Centare

April 7, 2014

5 Min Read
(Image: JimG, <a href="http://www.cambridgeincolour.com/forums/thread28288.htm" target="blank">Cambridgeincolor.com</a>)

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.

About the Author(s)

Erik Weber

Director, Agile Practice, Centare

Lysa Myers began her tenure in malware research labs in the weeks before the Melissa virus outbreak in 1999. She has watched both the malware landscape and the security technologies used to prevent threats from growing and changing dramatically. Because keeping up with all this change can be difficult for even the most tech-savvy users, she enjoys explaining security issues in an approachable manner for companies and consumers alike. Over the years, Myers has worked both within antivirus research labs, finding and analyzing new malware, and within the third-party testing industry to evaluate the effectiveness of security products. As a Security Researcher for ESET, she focuses on providing practical analysis and advice of security trends and events.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like

More Insights