Strategic CIO // Executive Insights & Innovation
Commentary
4/7/2014
09:06 AM
Erik Weber
Erik Weber
Commentary
Connect Directly
LinkedIn
RSS
E-Mail
100%
0%

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

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
<<   <   Page 2 / 3   >   >>
ChrisMurphy
100%
0%
ChrisMurphy,
User Rank: Author
4/8/2014 | 5:00:42 PM
Re: Agile Management?
At the InformationWeek Conference last week, Adrian Cockcroft (Battery Ventures fellow, former Netflix cloud architect) talked about enabling teams to go faster, and the need to create an architecture and policies to allow for deployment to customers much more often. While he was talking about cloud architecture and not Agile dev directly, his risk/quality assessment fits this discussion: You're doing smaller feature updates each time, so the risk of any one deployment goes down, but you're doing them far more often so the overall rate of change and volume of change goes up.
2h74webere
100%
0%
2h74webere,
User Rank: Strategist
4/8/2014 | 1:30:10 PM
Re: Agile Management?
moarsauce123 - you have some interesting experiences!

It does take some time to transform a whole organization, and along the way there are various peaks and valleys among teams, managers, and other departments.  That's all part of the journey, and with a good transforamtion team to help, this becomes transparent and very very manageable.  More and more companies are going down this path with increasing success.  

The thought that certain industries can't accept new features on a more regular basis has really been disproven at this point.  It actually costs less in absorption costs to deliver frequently.  I understand this is not the "normal" for some industries.  However there are certain things that are changing the global economy (mobile, continuous delivery, SaaS) that make this "the new normal."  Here's a really good talk on the subject: http://www.getchef.com/blog/chefconf-talks/chefconf-2013-keynote-session-opscode-adam-jacob/

 

Finally, on quality.  Agile enables teams to produce higher quality products.  This has been shown over and over in multiple industries, and many of the modern quality practices emerged from agile techniques (XP, pairing, TDD, among others).  If the team chooses to create new buggy features over fixing old buggy features, this is not an agile problem.  It's simply bad product maangement.  Or underskilled developers.  It really has nothing to do with whether or not the teams are agile.

Thoughts?

 

Somedude8
50%
50%
Somedude8,
User Rank: Ninja
4/8/2014 | 12:29:14 PM
Re: Agile Management?
Yikes! Agile should never be used as an excuse to write crap code, or for developers each interpresting what they think the requirements would be if there were any. Sounds like your dev team is using Agile as an excuse to go Wild West.
2h74webere
50%
50%
2h74webere,
User Rank: Strategist
4/8/2014 | 11:46:08 AM
Re: Agile or...
 

That's a great line - sometimes you just have to laugh!
moarsauce123
50%
50%
moarsauce123,
User Rank: Ninja
4/8/2014 | 8:11:50 AM
Agile Management?
The biggest problem with Agile is that development teams might embrace Agile, but management continues on the same path as before. How many times did we want to change product and process, but figured that the change is so massive that we need management buy in. After inqurying again and again what the management decision is it eventually was put on a meeting agenda months later. I don't recall that we ever got a response. The entire organisation needs to be agile and focus on quick, simple results. Any process that takes longer than a few days needs to be tossed out, that includes getting new hardware, spinning up virtual servers for product deployment, and getting other decisions made.

What strikes me odd in all that Agile discussion and also mentioned in the article here is the focus on testing and quality. Since I am working in an Agile team the interest in fixing bugs went down a lot. The product owner is more interested in getting new features in than getting existing features properly working. There was barely any feature that truly was done as in design and code completed, fully tested, and patched to a high quality level. The argument is that we want to get feedback first before making any design changes. I have yet to see any feedback or any convincing reason other than wanting to stuff more features in than keeping quality high. Agile is nothing but pure frustration for someone working in QA. Developers love it because they can do whatever they want and call it quick iterations and on the go design. And we also lack some detailed requirements most of the time, so developers build something that in QA's mind does not meet the requests and the product owner as decision maker asks for new features, wants to keep clearly dysfunctional design in place...and we all wait for the feedback to come.

There really is no point in delivering features ready to ship when the industry does not expect or want releases every few weeks. We did two releases a year in the past and many customers complained about that to be too frequent. Most of them skipped one release and did the upgrade only once a year. I can see a benefit for sales to have something new to show every other week. For that reason I suggest adopting a continuous delivery model where features get pushed out when they are done. That means that sometimes it will take a month or longer to get a big feature in place. Often there is no point in delivering it piece by piece. A set of database tables and an empty form do not add any value.

Lastly, the artificial time boxing especially with Scrum is a major obstacle. Three weeks is just not enough to do design, development, and testing. QA might get the test plans in place going by vague requirements, but then ends up changing the plans to match what the rogue developers cooked up leaving the last four hours of a sprint to do some testing. Any bugs found will not get fixed because that was part of the old sprint and now we do new features. It is a quality nightmare and the overabundance of mediocre software clearly shows this. Scrum in particular is nothing else than mini waterfall with the QA phase lopped off. If a team is lucky it gets to do a hardening sprint where the worst of the accumulated technological debt might be mitigated, but often enough so much undone stuff piled up that most of it gets scratched or postponed to be never done.

Agile is the death of quality....but maybe we are just doing it wrong.

 
jagibbons
50%
50%
jagibbons,
User Rank: Ninja
4/7/2014 | 6:25:24 PM
Re: Releases Every Few Weeks
Through a number of metaphorical scars, I've learned that you can't do "agile lite" if you are just getting started. You have to buy-in and revolutionize (not evolution which takes too long). You can't ease into it as it will become burdened with "the way we've always done it." Other may have been successful easing into agile, but my experience was that cold turkey was the only successful transition..
jagibbons
50%
50%
jagibbons,
User Rank: Ninja
4/7/2014 | 6:23:19 PM
Re: Agile Executive Pitch Template
That is a really easy value proposition to explain and defend.
DonM632
50%
50%
DonM632,
User Rank: Apprentice
4/7/2014 | 5:40:08 PM
Agile Executive Pitch Template

Great article, Erik.

I think these four points make for a great agile executive pitch: 

Learn to be production ready + Release sooner + Listen to your customers = Happy customers + employees.

Don

David F. Carr
50%
50%
David F. Carr,
User Rank: Author
4/7/2014 | 5:01:38 PM
Easier Claimed Than Done
A lot of the people I interview will throw something into the conversation about "and of course, we're usign agile methodologies" and I wonder how often that's really true.

The Oregon state government health information exchange was supposed to be following very agile processes and yet never got built. One of the reports on the failures of that project specifically mentioned the need to translate good intentions into real agile discipline.
DAVIDINIL
50%
50%
DAVIDINIL,
User Rank: Strategist
4/7/2014 | 4:07:49 PM
Re: Releases Every Few Weeks
@holavana.  Good info.  I am sure that my company could make it work if it wanted to.  A few years back we had a moderate push on to do "agile lite".  For whatever reason, we didn't see a big benefit in whatever flavor of agile we were using and we are doing much fewer projects with it now. 

IDK if we were unsuccessful due to the type of projects we used it on or if our approach to agile was not fully dedicated enough or some other reason.  But agile has not caught on in a big way with us. 
<<   <   Page 2 / 3   >   >>
The Business of Going Digital
The Business of Going Digital
Digital business isn't about changing code; it's about changing what legacy sales, distribution, customer service, and product groups do in the new digital age. It's about bringing big data analytics, mobile, social, marketing automation, cloud computing, and the app economy together to launch new products and services. We're seeing new titles in this digital revolution, new responsibilities, new business models, and major shifts in technology spending.
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Tech Digest - August 27, 2014
Who wins in cloud price wars? Short answer: not IT. Enterprises don't want bare-bones IaaS. Providers must focus on support, not undercutting rivals.
Flash Poll
Video
Slideshows
Twitter Feed
InformationWeek Radio
Archived InformationWeek Radio
Howard Marks talks about steps to take in choosing the right cloud storage solutions for your IT problems
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.