At a strategy meeting with Leaders, I asked a Sr. Executive on why business agility was identified as an optional initiative… They were not the most enthusiastic about backing it up fully and their response was not surprising in the least!

A few department leads had tried implementing various methods and frameworks (including SAFe) and were discouraged by the amount of chaos it created which left them wondering if it was worth the investment. 

Some had completely shunned the idea and reverted to the tried and tested project management methods. And, of course, that sends a message up the chain–cautious and familiar approaches are better than the new methods.

No wonder the Sr. executive placed a condition on any further spend towards business agility – “only if it had something tangible to show!” Their past experiences led them to not entertain any further discussion on the topic unless it was supported by hard facts and real improvements to the business.  

The state of business agility report from 2023 states that, on an average, organizations can start to see measurable benefits between years one and three, but it takes approximately eight years to see significant benefits from business agility, which is when agility becomes the norm. 

Not many are ready for the long haul and quite a few agile transformations reach a state of disillusionment when the traditional approach of starting a new initiative by forming a core team, creating a charter, a plan and executing such a plan is applied to business agility. 

Business Agility is about making your business nimble, so it can better retain its customers, wow them even further and grab new opportunities quickly (before their competitors). In doing so, it helps a business gain the first mover advantage and grow their market share. 

Business agility is about a mindset change–the kind of change that allows you to make better decisions so you can grow your business, keep your employees happy and navigate the market dynamics. To expect such a mindset change in a relatively short period of time is not realistic–it is an expectation that will set you up for failure. The companies that understand that it is a long haul, are the ones that can reap significant benefits from adopting business agility.

Notice that in the statement above, there is no mention of a team of consultants that would do this for you, instead the keyword is “YOU”. It then stands to reason that business agility is only possible if you decide to change… your mindset, your decision making process. 

The mindset change must start with the senior leadership. It needs to start from the top. Unfortunately, this is where most agile transformations go wrong. Often, senior executives misconstrue business agility as just another initiative that can be delegated to middle management and have them report on progress. 

Indeed middle management has a significant role to play later in the implementation cycle, but one cannot delegate awareness, desire and knowledge aspects to them. 

Say you wanted to get in better shape and decide to join a gym and hire a personal trainer. They can teach you different workout routines, suggest a diet plan and assess your progress, but they cannot do these things for you. How we wish we could lose weight by making our trainer run on the treadmill for us, while we continue to enjoy our chocolate cake—alas, that’s not possible. We have to put in the hard work, if we want to get in shape. 

Agility is the same way, you can’t hire a team of highly paid consultants and put them to the task of making your business agile. They won’t have the same level of experience and understanding of your business. Importantly, even if they do gain the understanding, they will likely not have the authority to make decisions that you can. 

Many  companies substitute consultants with delegating this responsibility to middle management. That, however, is not a prudent decision either. For starters, the mindset change, as alluded to earlier, needs to start with the senior management. Importantly, many decisions that would make your business agile could likely result in process changes and reduction of workforce that could go against their self-interest or job preservation.

Over the years, I have noticed that it is becoming harder to recover from failed agile transformations. Despite the significant benefits provided by agile transformation, organizations are becoming wary of reconsidering investment (time and money) into training and coaching. I list the primary driving factors of this hesitation.

Dual operating system 

Large enterprises have placed a lot of faith in traditional hierarchy which offers efficiency and stability in conducting operations; it creates a predictable structure which has been perfected over time. 

However the hierarchies create barriers to smooth flow of information, inhibit quick response to opportunities and cede advantage to smaller more nimble organizations that can move quickly to grab market share. 

The introduction of a dynamic network that organizes around value and offers smooth communication across silos by creation of value streams and agile release trains was thought to overcome limitations posed by organizational hierarchy. 

Maintaining a balancing act where the value stream network can co-exist with organizational hierarchy (in harmony) has been an ongoing challenge that causes many organizations to revert  to traditional ways of working rather than risk upheaval of their tried and tested methods.

Where most implementations falter is to underestimate the tight grasp that organization hierarchy has made on mindsets and careers of employees, many of whom have come up the ranks by subscribing to the command and control structure and it now runs deeply in their veins. This includes middle managers who are often tasked with executing agile initiatives within their business units. 

Making an assumption that introducing a new way of working without fully analyzing its impact on employee roles, responsibilities and careers causes much uncertainty and anxiety. 

During a discussion with a sr. manager who was considering launching an ART, we had multiple conversations on the implementation plan over the course of a few weeks, which is when they stumbled upon an interesting dilemma. “What should I do with my Project and Program managers ?” they inquired. With their teams transitioning to an ART, they suddenly found an excess of Project/Program managers that would not fit into this new structure as is. 

Remember when questions remain unanswered, people usually assume the worst and would try and secure their position by gravitating to things they know rather than taking initiative and venturing into the unknown. This is where leaders have to lead from the front, participate actively in the transformation and keep a check on the pulse of the organization via periodic surveys.

When to use Agile (and when not to)

The 4C model (Cynefin Framework) aiding decision making can provide unique insights on when it might make sense to consider an Agile approach and when it may be an overkill. 

Without going into too much detail, the model allows you to classify work into clear, complex, complicated and chaos categories. Agile likely is a good fit for complex and chaos scenarios where quick learning and a fail-fast approach helps lower your risk of straying too far from delivering value in the shortest possible time. 

The clear and complicated scenarios do not exhibit much volatility or the need to course correct thus a predictable and iterative process can provide quality solutions in the desired time. 

This can also help identify if Scrum or Kanban is a valid approach for your teams. The key point to remember is to classify work into one of the four categories and then assess if utilizing an agile approach would benefit or hinder progress and outcomes. 

Lets do this all-at-once 

SAFe provides an implementation roadmap to aid large enterprises with a structured approach in adopting agile and scaling it to the enterprise. In it, they mention an approach to start with one agile release train, learn from the initial PI planning/execution and then apply the learnings when launching more ARTs, extending it to portfolios. 

In practice, its rare to see a pilot ART going through planning/execution while the rest (of the organizations) sits back and wait approx 3 months for it to reach the end of PI. 

Most managers would opt for launching an ART as quickly as they can, perhaps use the available budget for training, get to the finish line and check the box on being agile. By doing so, they all would likely make similar mistakes and have a harder time course-correcting. 

This isn’t as hard to fix but the fear-of-missing-out is ever present and perhaps being the first one out there has greater benefit than waiting to learn from other implementations. 

Have you observed similar impediments to your agile transformation ? What has been your experience in transitioning towards an agile way of working ? Share your thoughts and leave a comment below.