BT

When Agile Success is Eventually a Failure

by Vikas Hazrati on Dec 01, 2009 |

It is often assumed that once the pilot Agile team(s) are successful, the process of Agile adoption is on the right track. Dave Nicolette shares very intriguing insights into situations where the adoption failed even after very successful pilot implementations.

Dave observed in the first case study that even thought the pilot was a roaring success and the team qualified for the ‘hyperproductive ‘ state, the unimaginable happened thereafter.

As soon as they could, IT management "took control" of the agile group. Within a week, they had (a) canceled the practice of locating technical teams on-site with their internal customers; (b) scattered the agile practitioners around in the traditional organization, to dilute their influence; (c) conjured negative performance reviews of key agile proponents in the organization as a way to encourage them to leave the company; some were even put on probationary status, to pressure them to leave; (d) assigned some of the top performers to dead-end jobs babysitting relatively unimportant legacy apps; another tactic to encourage them to leave; and (e) re-established the waterfall process (decorated with a few agile buzzwords) as the sole way of delivering projects for internal customers. One year later, there was nothing left of "agile" but the word.

Likewise, in the second example that Dave presented, as soon as the Agile coaches and consultants left, the in-house Agile experts started to reassert the practices that they had been following before the consultants came in and the teams became hyperproductive. The in-house experts felt threatened by the external consultants who had contributed to the success of the pilot and they wanted to restore things back to where they were as soon as the consultants left.

On similar lines, Dave quoted another example where one of their showcase clients with whom they had done a very successful implementation never came back with repeat business. The reasons for not coming back were thought provoking,

Our team had performed at a pace that was far out of sync with the client organization. Our customers could not keep the backlog up to date fast enough to feed our team meaningful work. They threw stories together helter-skelter just so they wouldn't be paying us an hourly rate to have our people sit around and wait for something to do. The experience was so stressful for them that they decided they weren't suited for agile work, and they reverted to traditional methods and traditional services firms.

So what was the reason for these roaring success case studies not being successful?

Dave suggested the following two major reasons

  • Local process optimization – The pilot teams were separate from rest of the organization. They were working in isolation from rest of the organization and as soon as the pilot was over that ripple in the ocean faded away. The changes were carried on too much at a local level to cause any amount of friction in rest of the organization.
  • Insensitivity to emotional factors – The consultants ignored the support of individuals and departments who would have been instrumental in the sustained success of the effort. As a result of this as soon as the consultants left, these support groups rallied together to get into the earlier way of working.

They responded in a perfectly normal human way: They bided their time until they could crush the agile initiative, and then they did so quickly and firmly. They "punished the innocent" and made sure anyone who had been part of the agile group either sat down and shut up, or left the company.

Dave suggested that the formula for success lies in adjusting to the pace of change and the demand for collaboration according to the client’s ability to cope with change. This way the initial project might take longer to succeed, however the Agile transformation would succeed in the long run.

Turning all the knobs up to eleven while ignoring the human costs of doing so may not be the definition of success, after all. Beware of consultants bearing gifts of hyperproductivity.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

agile adoption at team level often makes things worse by Alan Shalloway

I've seen many cases where the real problem is that there is too much work being given the development group and everybody is working on too many things. By creating a pilot project, you actually overload the other teams even more. The pilot may work, but the root cause of the problem (no real teams, overloaded staff) has not been touched at all. When a team is doing well but the others aren't, people get upset (for good reasons).

For agile to be successful, one must look to the enterprise, not merely the teams. Starting with a team pilot alone is often a path leading to more frustration than success.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT