When Agile Success is Eventually a Failure

Posted by Vikas Hazrati on Dec 01, 2009

Sections

Process & Practices

Topics

Agile in the Enterprise ,

Adopting Agile ,

Agile

Tags

Best Practices ,

Retrospectives

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.

1. Back to top

   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.

   Reply

• Older >