Comments
4 Signs You're Doing Agile Development Wrong
Threaded  |  Newest First  |  Oldest First
ChrisMurphy
50%
50%
ChrisMurphy,
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. 
DAVIDINIL
50%
50%
DAVIDINIL,
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. 
holavana
50%
50%
holavana,
User Rank: Apprentice
4/7/2014 | 3:55:13 PM
Re: Releases Every Few Weeks
@DavidNIL

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.

 
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. 
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..
Bob Schatz
100%
0%
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.
2h74webere
50%
50%
2h74webere,
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!
Somedude8
50%
50%
Somedude8,
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!
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!
drice01
50%
50%
drice01,
User Rank: Apprentice
4/29/2014 | 3:27:02 PM
Re: Agile or...
My guess is that they are probably not going to get done whether they call it agile or whatever approach they had previously.  Yes, they may deliver on-time and on-budget maybe... but was it really done, did it include the highest value features, was there positive market feedback and impact.  I think not.

 

Agile is the only way to deliver high quality features to market that people will actually use and enjoy.  As many referenced, it requires more than a high performing scrum team.  It requires an organization who understands there is huge business value through investing in a more modern approach to business.  People first, then process and then tools.
Justin Hunter
50%
50%
Justin Hunter,
User Rank: Apprentice
7/17/2014 | 3:35:13 PM
Re: Agile or...
I have seen a dozen if not more large orgnaizations and they claim to be agile but in reality they are a hybrid of what they want to create. Most of these companies need to understand the basics first. Good blog here about agile framework. 
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.
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

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.
ElizabethT568
0%
100%
ElizabethT568,
User Rank: Apprentice
4/11/2014 | 7:45:25 AM
Re: Agile Executive Pitch Template
Hi Abbey,

U r right but notonly Scrum ,PMP also carries imp in case pf Project Managemment.I would say that a PMP Certification is highly respected within both IT & non-IT communities where strong project management skills are required. If you plan on a long term career as a project manager, then yes, even with your level of experience, I would suggest getting your PMP. You can prepare yourself for the exam in one of the <a href="http://www.pmstudy.com/">PMP training</a>providers like www.pmstudy.com/. You can do minimal prep-work to get 40 PMI® Contact Hours and apply to PMI for PMP Exam before the class begins.
PeeterP975
0%
100%
PeeterP975,
User Rank: Apprentice
4/11/2014 | 6:40:55 AM
Re: Agile Executive Pitch Template
Hi Erik ,


Love the artcle written by you.Wonderfull descriptipon.As a project manager, I use Scrum in my projects. The Guide to Scrum Body of Knowledge by SCRUMstudy provided a complete reference for the Scrum project I am working with. It is a very good book and extremely readable. I really liked sections on risk and quality. The tools mentioned in the processes were very helpful. I highly recommend this book if you are planning to implement Scrum in your organization. You can go through the first chapter available on

http://www.scrumstudy.com

 
2h74webere
100%
0%
2h74webere,
User Rank: Strategist
4/11/2014 | 12:08:10 PM
Re: Agile Executive Pitch Template
I have yet to meet a single respected person in the agile community that approves of SCRUMSTUDY or PMSTUDY.  
jagibbons
100%
0%
jagibbons,
User Rank: Ninja
4/14/2014 | 8:58:16 PM
Re: Agile Executive Pitch Template
Agreed, 2h74webere. The very notion is a "body of knowledge" is contrary to the Agile Manifesto.
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.

 
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
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?

 

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 | 5:08:03 PM
Re: Agile Management?
 

Small Batches are key.  Everytime we release and react, we are resetting the "risk counter" back to zero.  As a business owner, I'd much rather have a series of releases that include only a few features and allow the teams to react to the feedback, versus havine one big-bang release.  Long-cycle development is quite literally putting all your eggs in one basket.  
PDXJ
50%
50%
PDXJ,
User Rank: Apprentice
4/11/2014 | 11:12:08 AM
Re: Agile Management?
This post reflects much of the thinking I have on agile in my software development company, except in our case, management failed to consider our existing products, including their complexity and detailed inter-relationships between each other, as well as customer needs prior to mandating our shift to agile. They simply wanted our monumental software releases to be developed and delivered faster. And, aside from hiring some highly compensated consultants to come in for a week or so, we've been left to figure it out for ourselves...and I believe we're doing it wrong.

While I don't fault agile itself, the implementation of it in our company (a Fortune 500 software company, you probably have heard of) is going on 2 years now, and it has been ugly. Despite the egotistical proclamations of management today, it isn't working well. Some groups stealthily cling to tenets of waterfall (disguised by agile terminology), not because they are 'clinging to old practices' but because of the needs of our customer base and their desire to release software that works. We've had pushback from some large customers on releasing software to them bit by bit. As agile developed features get turned on, it breaks other software they have. I've yet to hear a coherant explanation how adopting agile is benefiting our customers. We are also highly date-driven here as well, both to satisfy our customers as well as our own leadership.

The problem for us is, we're an old locomotive of a company. We have several 25-30 year old software products full of legacy code, that have deep and extremely complicated inter-connections with each other. There are very few people in the company that truly understand how they all work together. Many of those experts were let go so newly minted, young 'agile saavy' developers could be hired. Going 'Agile' here has increased the number of bugs, the number of support cases and the increasing dissatisfaction among the workforce and customer base. Management egos, however, will not allow us to alter agile to make it work for us.

Silos are worse than ever, with the software development teams heads-down working on software to meet some un-bending magical agile release cadences. Inter-organizational communication is close to non-existant, with the custome support, install and training organizations scrambling for bits of information about upcoming releases. As a result, we've had some spectacular failures inside our organization, as well as with customers.

Engaged, educated management is critical, I've learned, to making agile work in an organization. I'm not seeing it here. In the best interest of our customers, I hope egos can be put aside and voices could be heard admitting that 'strict' agile (isn't that a contradiction anyway) may need to be modified for our products and customers.

 
Charlie Babcock
100%
0%
Charlie Babcock,
User Rank: Author
4/8/2014 | 6:33:39 PM
Pointed portrayal of agile development
Nice pointed commentary, Erik. I am reminded throughout how the true benefit of agile development is its ability to enforce a feedback loop, a reality check, with the customer. without it, software can't fit the needs of the business or matching the evolving reality outside the business. At the heart of agile is the belief that we don't know everything we need to know at the start of a big project, no matter how carefully we've attempted to define it. 
jagibbons
50%
50%
jagibbons,
User Rank: Ninja
4/14/2014 | 8:57:18 PM
Re: Pointed portrayal of agile development
You are right Charlie, in that the feedback loop is critical for the agile framework to succeed. Without continual communication, agile isn't anything more than waterfall with new terms applied to it.


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 20, 2014
CIOs need people who know the ins and outs of cloud software stacks and security, and, most of all, can break through cultural resistance.
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.