Agile transformation – When practices won't help?

Agile embraces change. In fact, this is the biggest reason why organizations select Agile over conventional delivery methodologies (as per the recent State of the Agile Survey). We see more and more people are practicing Agile methods; number of Agile certifications are growing exponentially; and big or small, organizations of every size are signing up for Agile. Yet, most of the Agile transformations are failing. Why?

 If you carefully research, a typical “failed” Agile transformation might look like this...

Label the Agile transformation with a fancy word. Select a bunch of middle managers from IT and Business, and change their job title to ScrumMaster and Product Owners, respectively. Arrange 2 days course and certify them as SMs and POs. Roll out an Agile ALM tool. Create team KPIs. Create 2 weeks Sprint, and start the daily standup and other ceremonies. Then sit back on couch and wait for a miracle to happen. Well, all goes well until teams on the ground start unpacking the newly arrived package, and struggle to follow the operating manual. (Well, some of the struggle is good, and comes as part of the change, however, most could have been avoided.) Then after sometime Business starts questioning the promised benefits, while transformation leaders are finding their feet. Finally, frustration starts to take over the excitement, and that eventually results in its failure.

Before we dive in to the reasons, we need to remember that Agile is a “methodology”, “the why”, guiding principles, an umbrella term that covers variety of frameworks underneath. It is not a “framework” or “practice”, and does not prescribe you with “the how”. Nonetheless, frameworks are very important and should be carefully selected based on various organizational factors, including the nature of products or services the organization is providing to its customers, organizational structure etc. Now let’s get back to the discussion.

There is a common pattern in majority of unsuccessful transformations. That is, focusing more on Agile practices, such as Scrum, Kanban, XP etc, over Agile principles and values. To the extent that many a times management gets too obsessed with practices that they don’t even realize that Agile principles are being compromised. Typical example is, Scrum is being followed in a product team, but due to a change in product strategy the arbitrary Sprint boundaries and fortnight planning are no longer working, but because team KPIs are formed around Scrum, management still forces team to comply with Scrum instead of exploring the alternatives. I always give an analogy to explain this during training sessions and offline, which is, following a Religion is not limited to performing the prescribed rituals. Core is faith, and if there is no faith, performing rituals is of little or no benefit. (Of course, no offence to anyone who does not believe in any religion ??).

It is when Agile transformation is centered on Agile principles and values that success is made. These principles and values need to be embedded in the organization culture, while new frameworks are taking over the old processes. The organization, with its culture based upon agile values and principles, inspires people to practice with authenticity instead of performing rote rituals. Moreover, it drives them to continuously review and adjust them based on their learning.

Let’s take a couple of examples to explain it further.

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

This Agile principle demands organizations move from Command and Control mode to Self-organized and Self-managed autonomous teams. People should feel motivated to do their job, they should take pride in what they do and achieve. This is only possible when they are entrusted in doing what they know best, rather than someone on top controlling their moves. Management should set the objectives (what) and let the teams decide how. Apart from trust, fear has to be eliminated from the environment so that teams focus on producing quality outcome, not saving themselves from consequences.

“Working software is the primary measure of progress.”

No matter, how good the burndown chart looks, or there is a consistent increase in team velocity, or the recent demo was a “wow”; success only counts when the product is delivered to the customers, and they like it. The framework you use is just a means to an end. The end is to deliver the quality product to your customers at the time they need it most.

Therefore, I tend to disagree with the argument that “Doing Agile” is a precursor to “Being Agile”. A team can easily fake the former, so how it can be a reliable foundation for latter? Instead “Being Agile” should be the only focus for the teams, whereas “Doing Agile” is an inherent and important part of it.

In closing, there are many quotes out there, on the importance of Practice in order to achieve excellence in any area. Every practice has underlying activities and actions, that you perform over and over again, in order to master it. This is how we have been trained since kindergarten times. There is truth in that, but as environmental changes pick up, there is lot more to it. There has to be a fundamental purpose behind a practice that does not change with changes in environment or people. Basically, your practice alone won’t be able to lead you to success in a complex working environment, unless there is a core foundation beneath.

It is when Agile transformation is centered on Agile principles and values that success is made.