Who killed Agile?

Last week I attended the Agile2014 show in Florida. Agile and continuous delivery can bring significant improvements to any organization for building, testing and deploying software, but we often find that there is resistance for adoption. Creating the necessary processes and tools and automating and accelerating them can help you deliver better software faster – a key requirement in today's highly competitive environment.
One of the break-out sessions at the show, lead by Dhaval Panchal, focused on helping participants understand the reason for this resistance. The session was entitled "Who killed Agile?" and was designed to have participants act as detectives, investigating the resistance as if it were a crime (and maybe, it is!).
The motive (or “why would someone resist adopting agile”) included “fear of something new” as the number one reason. Other reasons reported included; keeping the "status quo," resistance to change and fear of losing control. After we had come up with our own list, Panchal reported top excuses he had heard from other organizations implementing Agile, including:

• “Our teams are geographically dispersed.” Agile is about working closely together on short, focused sprints. The thought of trying to collaborate across multiple time zones and overcoming cultural differences is often enough for people to decide against trying to implement Agile.

• “We have so much legacy code.” Often, people think that Agile is only good for developing new features, so they don’t see the benefit when they are simply trying to maintain older codebases or bug-fixing previously supported features.

• "We are drowning in technical debt." A corollary of the previous problem, many people have made poor architectural choices and built workarounds on top of workarounds to keep their systems running. They often don’t see the benefit of an Agile process in addressing these chronic problems.

• “We only see Scrum as software.” Respondents seemed to think of Agile not as a process of collaboration and continual improvement, but rather just some off-the-shelf product.

• “We still let IT drive the train.” The transition to Agile is a hard one, and if the rest of the organization is not “on board” with the transformation it can lose efficacy. If IT will only allow a maintenance window every 6 months when new code can be deployed, why should Developers transform their pace and complete sprints every 2 weeks.

• “Too many Managers deciding how the teams should work." With Agile, focus is important and following proven methods of process means you need to have buy-in from all Management

• “There is no accountability.” If no one is held accountable why would anyone try to make it succeed.

Next we moved on to identifying key suspects – those who we thought would have the most to gain from inhibiting the implementation of Agile. We identified Developers who comment that this is the way we have always done it. Project Managers complained that they don't have time to change the system now. HR advised that they wouldhave to set new objectives, and Management asked why make waves and complicate things. Lack of executive sponsorship or having a clearly defined vision, as well as a management team that did not support the efforts required to "go Agile" were our most common suspects.
In order to commit a crime, you need a weapon. In this case, the weapons we determined that were most often used as an excuse to resist Agile transformation included stress, existing contracts and performance appraisals – a clear sign that teams fear moving to Agile believing it would make existing goals more difficult to meet in the short-term. Other weapons we discussed were negative gossip – brought about by “the water cooler effect,” which kills the spirit of the Agile transformation, and translates into poor execution.
Obviously, when Agile transformation is stagnating, people can see what is going on. The most obvious witnesses we identified included Agile coaches and Agile team members, who play a key role in the Agile transformations’ success.
For a crime to occur, the perpetrator needs to choose the right time to strike. We unanimously felt the best opportunity for this would be during the actual implementation of an Agile transformation. This would be the time to gather the most resistance since change in general is a common challenge even with the promise of a better way to do things. As we left, Panchal let us know that the detective work we completed matched the efforts of others who have come before, but he told us that we shouldn’t be discouraged by the obstacles we identified. To overcome this resistance, he outlined key areas to focus on:

• Secure executive support

• Enlist active, motivated proponents who provide momentum throughout the process

• Ensure all parties take ownership and follow procedures and processes

• Acknowledge early that change is hard, but the ultimate results will be well worth it

• Provide a clear path for meeting and exceeding goals and objectives.

Are you starting, in the middle of, or finishing up an Agile transformation? What challenges have you had and, if you put on your detective hat, what would an investigation reveal?
Leave a comment below and let us know what you think.

Want to learn more?

Check out our recent webinar:
An Agile Approach To Achieving Continuous Delivery