Agile Can Contribute to an Acceleration Trap

Accelerating when you a plotting a change in direction can be a problem.

I am often asked whether Agile techniques contribute to an acceleration trap in IT. In an article in The Harvard Business Review, Bruch and Menges (April 2010) define an acceleration trap as the malaise that sets in as an organization fails prey to chronic overloading. It can be interpreted as laziness or recalcitrance, which then elicits even more pressure to perform, generating an even deeper malaise. The results of the pressure/malaise cycle are generally a poor working atmosphere and employee loss. Agile is often perceived to induce an acceleration trap in two manners: organizational change and delivery cadence.

Implementing Agile requires substantial and sustained organizational change. It generally affects team structure, the work and process management and technical techniques impacting configuration management, testing and coding. Changes of these types are almost never deployed in a single big bang, but rather in waves with minor tweaks being made in-between changes based on feedback. All organizations have a different “carrying weight” when it comes to change, or the amount of change an organization can absorb before the resistance level overcomes the pressure to change. Many factors can influence the carrying weight an organization can internalize, and therefore avoid an acceleration trap. These factors include organizational change management programs (selling the change), level of involvement, and the pressure to change. The first two items on the list should be built into the change program. Organizational change management programs generally help make the case for change, layout the benefits of change and seek buy-in. Getting the people who are being asked to change involved in planning and implementing the change helps to combat feelings of victimization that can occur. The third category, the pressure to change, is generally a reflection of market performance. I have often observed that a good “near death experience” (organizationally speaking) significantly increases the ability of an organization to change. Change driven by desperation is not something anyone wants to live through and you are asking for trouble if you try to fake it.

The principles of the Agile Manifesto call for a sustainable pace of delivery. The pace should be set to be able to be maintained indefinitely. Organizations that use Agile to address projects with a fixed scope and set delivery dates will generally find early success as Agile accelerates early delivery of functionality. This initial success is often followed by burn out as team cannot maintain the pace of delivery. A common pattern I have observed is that a team is able to increase its velocity for a few sprints until suddenly it encounters a sprint in which nothing seems to go correctly and average velocity is negatively impacted. This saw tooth pattern can either be reflection of exhaustion or overstepping. Both are a sign of an acceleration trap. A simple solution (or maybe an overly simplistic solution) is not to agree to fixed scope and fixed deadline projects. A less simple solution would include integrating the development of a minimum viable product (MVP) into all release plans for all relevant projects, so that unsustainable cadences can be avoided. The introduction of an MVP into the concept of a backlog and release plans will require educating both the Agile team including product owner and other IT stakeholders.

Agile can add to the possibility of an acceleration trap if change management is not addressed or the change to Agile is imposed on project teams. Further accepting unrealistic projects, Agile or not, can lead to all sorts of problems, including an acceleration trap. Neither of these categories of problems HAVE to create an acceleration trap, if action is taken early. Failure to address the causes of the acceleration trap is more to blame than Agile.