Comments
4 Signs You're Doing Agile Development Wrong
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 September 23, 2014
Intrigued by the concept of a converged infrastructure but worry you lack the expertise to DIY? Dell, HP, IBM, VMware, and other vendors want to help.
Flash Poll
Video
Slideshows
Twitter Feed
InformationWeek Radio
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.