Structuring Agile; paradox or silver lining?

Let's start with a hard and inconvenient truth: transforming your business is a highly complex undertaking with social, organizational, and technological factors at play. Many (research McKinsey 70%) organizations fail to deliver on their transformation's promises.

Many transformations take place in organizations that have already established themselves in their markets, and are now trying to stay competitive. Even with strong leadership commitment, managing change can quickly become so complex that it’s hard to keep sight of the road that leads to success.

“The current economic circumstances are unpredictable. When business results suffer due to complexity, introducing Agile is definitely something worth considering.”

To anyone versed in Agile, it will come as no surprise that many organizations aim to deal with complexity and reach business objectives by establishing Agile operating models and delivery practices.

No longer is Agile seen as "something the IT department uses to deliver software.” Instead, its adoptation ranges to a much wider range of field, such as marketing, HR, sales, and even procurement.

The organizations I talk to are either in the process of establishing an Agile operating model, or have some experience with Agile and are now trying to scale up and use Agile to reach other transformation objectives, like building a data-native business or delivering smart software platforms.

The pitfall of Agile empowerment
Many executives, managers, coaches, and consultants acknowledge that working Agile is not without pitfalls. Agile is frequently considered a purely bottom-up delivery technique; teams autonomously determine what's best and work on what they think will deliver the most value.

Understandably, this evokes enthusiasm from teams who suddenly find themselves more empowered than ever before. Few Agile teams revert to prior ways of working. However, as much as empowerment and autonomy are part of this way of working, it is a myth that they are enough to reach set-out objectives magically.

Is having highly qualified, autonomous, and empowered teams not enough?
Imagine a situation in which a group of horses needs to pull a wagon to its destination along a muddy road and treacherous terrain. Each horse is a very Agile (not to mention powerful) animal, capable of reaching high speed and maneuvering around obstacles.

But, when several horses pull the same wagon, each of them determining their own course at full speed will result in chaos. Some horses will escape the pack, the wagon will break, and the driver will be left wondering what happened.

Consider the horses to be the delivery teams and the transformation to be the wagon; it's easy to understand why autonomy is challenging. So, how do you use Agile and get your wagon to its destination simultaneously?

A structural paradox
Working as a transformation manager for ten years, I have discovered that getting it right is mostly about balancing between providing autonomy and creating structures. The latter intended to work as the prerequisite to the former.

The organization's leadership team needs to drive change, make sure the transformation team has the right skills, and create a narrative that convinces people to invest their energy into the process.

Leadership also needs to make sure the structures are in place to thrive, such as creating a transformation office, setting up change management meetings, and creating a leadership oversight cadence to remove any obstacles blocking future progress.

One of my recent clients, who is in asset management, did this exceptionally well. Its senior directors took the time to prepare the transformation and establish a new vision with an accompanying transformation roadmap and backlog. A few directors formed an Executive Action Team to remove any organizational impediments hindering the the delivery teams and the transformation.

By putting these structures in place, they ensured that if a development team was to join later, it would know what was expected of them and how they were contributing to the larger transformation goals (the vision). Additionally, it allowed teams to work autonomous and empowered, within the scope of their respective products.

The directors then frequently updated and shared their vision, listened to the teams’ experiences, and used their political weight to sponsor the transformation and help remove any impediments.

Another example is a large retail company working on a new software platform, impacting various operating companies worldwide.

This transformation had started already. Several mostly autonomous software development teams were building an MVP of the new platform. After months of working together, aligning the teams with the larger product and architectural vision was still challenging, and when integration with large ‘outside’ programs was needed, something needed to change. Do you meet more frequently or leave teams to figure everything out by themselves?

The company added more support structures and kept specific responsibilities from teams. Every team shaped its functional domain to work on. A Scrum of Scrums support structure was added for teams to voice concerns and dependencies. Transformation management removed any bottlenecks for teams to focus on what they do best; deliver awesome software.

The paradox is, by involving leadership more, understanding the strategic support role they play in this process, and creating procedural structures such as a clearly defined and well-communicated vision, roadmap, and oversight structures, teams have a direction. They are empowered to do what's best and able to perform all the difficult tasks needed to bring the transformation home successfully.

RELATED CONTENT - GET THE BEST IN LEADERSHIP THINKING

Author

Thijs Wesselink, Senior Digital Transformation Consultant. I am very keen to hear your experience and thoughts on the topic. Let's have coffee so I can provide the right structures to make your transformation work.