As stated earlier, Agile has its roots in IT. The Agile Manifesto, the 12 principles, and the practices within the methodologies are all oriented toward optimizing the delivery of software. It is therefore not surprising that many enterprises have not only kept Agile adoption limited to IT delivery but have also limited the adoption of Agile by merely applying the list of practices. This is because Agile is seen as something to "do," rather than something to "be." The difference between "doing" and "being" Agile has major implications at the enterprise level, as will emerge throughout this book. For the average enterprise, the benefits of Agile relate largely to the benefits derived from Agile practices only.

Moreover, differences in ways of working, and the approach to "managing" people in parts of the enterprise which have adopted Agile versus those which have not, create unhealthy friction. The tensions arising from such friction are usually addressed by diluting Agile to render it a mere "checkbox" exercise.

Enterprises that limit the adoption of Agile to only a part of their business have often seen the changes made quickly regress to their original state, thereby losing all, or most, of the benefits derived from Agile adoption. This happens due to Organizational Inertia [vi]. The unaddressed systemic issues appear to overpower the "green shoots" in the Agile-adopted part of the enterprise. This behavior is akin to antibodies overpowering a newly entered virus in a human body.

Examples of systemic dysfunctions include the business and IT sectors having different measures of success, KPIs which encourage and reward individualistic behaviors, and a culture of pleasing the boss, because the boss is the sole decider of the salary and career progression of subordinates.

According to Steve Denning, author of multiple books including The Leader's Guide to Radical Management:

The benefits accruing from Agile adoption are now well recognized [viii]. Many enterprises, not wanting to be left behind, jumped on the Agile adoption bandwagon without truly understanding how to derive value from Agile.

Agile has become a "buzzword" for many, and therefore no enterprise wants to be seen as not having adopted Agile. Some businesses adopted Agile for merely optimizing their software development process, without much regard for business-driven outcomes such as an increase in customer satisfaction. Worse still, some others adopted Agile simply because "others are doing it."

Adopting Agile without linking it to a broader purpose, and without taking a systemic view, often results in unintended anti-patterns. An example of this is that in the quest to speed up delivery, teams have created technical debt, which, over a period of time, has been quite damaging. Another problem with merely "doing" Agile, that is, adopting Agile without the right mindset and culture change, is the wrong use of Agile practices. For example, story points are being used to measure and compare the productivity of teams. This, again, can create serious anti-patterns, as teams learn ways to "game the system" and thereby create a false sense of achievement, which can last only temporarily.

The While Agile methodologies may be prescriptive to a certain extent, for example, Scrum prescribing the five "ceremonies," a one-size-fits-all approach does not work even for Agile practices, as the practices have multiple maturity levels. Adoption of Agile practices, without customizing for context, is a guaranteed recipe for failure.

The need for customization to context has tremendous significance for Agile adoption. It implies that both experience and expertise are needed to decide upon and facilitate the adoption of the appropriate practices. Moreover, Agile works on the principle of "inspect and adapt" and hence the adoption needs to be monitored closely and adjustments made swiftly as necessary.

Some enterprises have tried to save money by not engaging experienced coaches. Many have hired coaches who only appeared qualified. It is therefore not surprising that the benefits of Agile have been minimal or have not accrued at all for many companies. In many instances, half-hearted/incorrect adoption has caused serious damage to Agile's credibility and has also left teams in worse states than before they attempted adoption. The natural consequence is that leaders of such enterprises lost faith in Agile.

One of the critical benefits of Agile practices is faster feedback. This implies that if something is failing, or not working well, it will become visible early. This is very valuable, as it provides an opportunity for early course correction. However, a lack of understanding of Agile has led to earlier visibility of issues, and even early failures, being seen as an impediment that slows down delivery. Ironically, a significant benefit of Agile has at times been erroneously seen as a problem with Agile, leading to Agile adoption being suspended or even abandoned.

The problems that Agile helps to surface are not only related to what's broken in the delivery process, but also about systemic dysfunctions such as command and control culture, and silo-oriented optimization. These dysfunctions are almost always closely linked to leadership roles and behaviors.

When the dysfunctions related to their roles and behaviors start becoming visible, most leaders feel threatened and insecure. Such leaders, to protect themselves, have sabotaged and even stopped Agile adoptions, claiming that it is not meant for, or relevant to, their enterprise.

Agile, if implemented in the spirit of "being," brings positive outcomes early. Simple practices such as visualizing work in the pipeline, and daily stand ups, are highly impactful if used in the right way, even if they are implemented in the simplest form. The downside to this is that many enterprises have treated Agile like a "silver bullet" and expected it to act as a magic wand that can resolve all problems instantly. The reality is that Agile is not a problem solution framework, but a problem identification framework. Agile helps to surface problems early, through shorter feedback loops, as discussed in the previous point. Agile does not fix the dysfunctions in the system but helps to bring them out in the open early. Knowing the problems within the overall system is the fundamental step toward effectively enhancing agility in the enterprise.

A cardinal mistake, which most leaders and those helping enterprises to adopt Agile have made, is to underestimate and even ignore the breadth and depth of change and the ensuing impact of that change arising from Agile adoption. Agile, if adopted right, needs a significantly different mindset compared to traditional approaches. Change in mindset and behaviors is painful, for both leaders and teams. Change needs to be facilitated and steered, and that is a lot of hard work. Moreover, this type of intrinsic change almost always takes a very long time.

It took eight years for the insurance division of a large financial conglomerate in Australia, employing over 10,000 people, to achieve the mindset and culture change that began making a significant positive impact on its business.

In many cases, leaders have expected delivery teams to change their mindset while not doing much to enable that change. Even worse, many of them expect everyone to change but themselves. Consequently, many enterprises have ended up merely "doing" Agile and have either not attempted or have given up on a mindset and behavior change, that is, "being" Agile. Even merely "doing" Agile brings in benefits related to better visibility of the work pipeline, improved collaboration between delivery teams and business stakeholders, and so on, which puts teams in a much better position. Enterprises often miss out on bigger benefits by stopping at "doing" Agile, since they, albeit wrongly, believe that they have achieved the optimal benefits from Agile.

Even though agility is quite different from Agile, as explained in the following sections, the challenges encountered by enterprises in adopting Agile are very likely to be similar to those encountered when enhancing agility. Hence, it is important that enterprises draw lessons from these mistakes and avoid making them in the pursuit of enhancing agility.