4 Signs You're Doing Agile Development Wrong - InformationWeek
IT Leadership // CIO Insights & Innovation
09:06 AM
Erik Weber
Erik Weber
Connect Directly
[Dark Reading] Cybersecurity Crash Course
Jan 11, 2018
Keeping up with the every changing world or cyber security can be exhausting. Dark Reading wants ...Read More>>

4 Signs You're Doing Agile Development Wrong

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

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.

(Image: JimG, Cambridgeincolor.com)
(Image: JimG, Cambridgeincolor.com)

 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.

Erik Weber is a Professional Scrum Trainer and the Director of Centare's Agile Practice. For the last 10 years, Erik has been a developer, tester, and project manager, in both waterfall and Agile environments of varying success. As a business and executive coach, Erik enjoys ... View Full Bio

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
<<   <   Page 3 / 3
User Rank: Apprentice
4/7/2014 | 3:55:13 PM
Re: Releases Every Few Weeks

I was in a similar environment where a regular Change Request process took minimum of 3-4 weeks. But we still had agile teams delivering in sprints of 2-4 weeks. The trick is to invest time and effort to plan ahead and anticipate the needs a few sprints down the road. This can be facilitated by the Scrum Master as part of removing road blocks.

ALso in our organization, we were able to adapt a modified Change Request Contorl policy so that some of the change requests ( with moderate impacts)  could be approved by a representative of the Change control Board working closely with the teams. but is not a formal member of Change Approval Group. The scope of such changes allowed were explicitly defined as part of a Master Change Request and had to be approved by the board. The validity of approval was provided for six months and renwable.

User Rank: Ninja
4/7/2014 | 1:54:33 PM
Agile or...
Friend of mine was at a large shop that was making the transition to agile. One day in a meeting, a frustrated PM said "Are we gonna be agile or are we gonna get this project done?"

I am not making this up!
User Rank: Strategist
4/7/2014 | 1:40:46 PM
Re: The 5th Sign....
Bob - I agree!  Hopefully doing 1-4 makes getting real feedback from actual customers a cheaper, easier, and more pleasant endevour.  Almost like we want customers to be able to tell us what they want in the product next!
Bob Schatz
Bob Schatz,
User Rank: Apprentice
4/7/2014 | 1:21:20 PM
The 5th Sign....
Great article Erik! I would add just one more thing that I feel is important enough to be the 5th sign...Are Your Customers Happy?

None of this means anything if you can't solve your customers problems. Are you doing the right things, and doing them right. You certainly need to do 1 thru 4 ultimately leading to the biggest test...5.
User Rank: Strategist
4/7/2014 | 1:09:15 PM
Releases Every Few Weeks
The change control process takes 3-4 weeks at my company.  In order to release 3 weeks from today, I have to have proof of testing completed today.  Agile is just not possible in this kind of environment.  At large companies with ultra complex/ultra integrated app flows, executives are much too afraid to let very many rapidly developed apps to be released into the production environment for fear that they would bring down mission critical apps. 
User Rank: Author
4/7/2014 | 10:00:57 AM
The Unhappiness Red Flag
This "unhappy developer" warning sign really resonates with IT execs I've spoken to recently. Developers are motivated by knowing they're building something that will be used and appreciated. If they get that feedback -- good or bad -- every few weeks or months, rather than after a 6 or 12 or 18 month dev cycle, they're more likely to be happy. 
<<   <   Page 3 / 3
Register for InformationWeek Newsletters
White Papers
Current Issue
Digital Transformation Myths & Truths
Transformation is on every IT organization's to-do list, but effectively transforming IT means a major shift in technology as well as business models and culture. In this IT Trend Report, we examine some of the misconceptions of digital transformation and look at steps you can take to succeed technically and culturally.
Twitter Feed
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.
Flash Poll