The term Agile isn't new; it has been in circulation for quite some time. In fact, it's been used to the point of becoming somewhat clichéd, causing many to react with a certain level of skepticism. Ever since the formulation of the Agile Manifesto in 2001, it has extended its influence beyond the IT sector to areas such as culinary arts, education, politics, and even private lives.
In this blog post, I will share a story based on my own experiences, demonstrating how an Agile transformation might develop in a large organization.
The Agile kick-off
Since 2001, many companies have decided to jump on the Agile bandwagon. However, many of them do the right thing for the wrong reasons. When an organization decides to fundamentally change the way it operates, it’s important to understand why. To gain a deeper understanding of this, I highly recommend reading "Start with Why: How Great Leaders Inspire Everyone to Take Action" by Simon Sinek.
Now, imagine a large company with thousands of employees. This company is eager to join the bandwagon as well. Typically, they’ll start a project called "Agile Transformation." They set a deadline, enlist the services of consultants and Agile coaches, identify teams suitable for this transformation, and start the kick-off meetings.
During this stage, selecting the right people for the roles of Product Owner and Scrum Master is of crucial importance. These individuals can strongly influence the direction of the Agile transformation, both in a positive or negative direction. It's advisable to identify people who aren’t afraid to experiment with innovative work methodologies. Given the multitude of frameworks available, you face the challenge of choosing the one that best aligns with your team’s needs. Based on my experience, especially with teams that have yet to adopt the Agile mindset, the Scrum framework (as outlined in the Scrum Guide) consistently proves to be the best starting point due to its easily implementable values and principles.
Scaling
After a few months, management will inevitably want a progress report. At this point, the transformation still appears promising, as the company maintains a relatively contained Agile ethos, and enthusiasm remains fresh. To expedite the transformation, more people are added to the project. Former project managers, business analysts, and middle managers transition into roles of Product Owners and Scrum Masters, prompting necessary adjustments to deadlines. However, a new set of problems now appears, and it’s the worst kind: they're the kind that many, particularly in large organizations, wrongly assume have already been solved. How does an organization manage growth?
A variety of pre-established organizational models are now available, such as SaFe, LeSS, the Spotify model, Scrum Nexus, or Scrum@Scale. Let’s say this company decided to use the Spotify model.
This Agile scaling solution was first introduced in 2012 when Henrik Kniberg and Anders Ivarsson published the whitepaper "Scaling Agile @ Spotify," introducing the radically simple way Spotify approached Agility. The Spotify model focuses on structuring an organization to enable Agility. Key elements of the Spotify model are organizational units known as Squads, Tribes, Chapters, and Guilds. In theory, the largest organizational unit, the Tribe, should be capable of independently delivering some form of a product.
Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds, Henrik Kniberg & Anders Ivarsson, Oct 2012
After choosing the scaling model, the transformation really gains momentum. A lot more people will join the so-called Agile teams, contributing to the expansion of the Agile culture within the company. Those working within Agile teams undergo certifications, training sessions, workshops, and seminars designed to usher them into this new way of work.
This is the moment when people realize that merely introducing new roles and job titles isn’t enough. The real problems, such as interdepartmental communication, resource sharing, and management, still need to be addressed.
To resolve these issues, quarterly planning sessions are dressed in special Agile clothes. During these sessions, initiatives and projects across the entire company are prioritized, and large boards containing project outlines are created. Yet, the company remains focused on optimizing the functioning of its smallest units.
Our key insight was that, regardless of how sound our plans were, successful execution consistently depended on a single team, causing delays for all other teams. So, we changed the way we planned work. Now, every other team must plan their work to minimize dependence on others. My understanding of this problem came from the book "The Goal" by Eliyahu M. Goldratt, which I highly recommend.
Local vs. global optimization
At a certain stage of our journey, it became evident that to achieve progress, the company leadership needed to adopt the new mindset as well. Agile coaches and scrum masters began to shift their focus to the leadership team. However, at some point, we realized we were looking at this the wrong way. To change our perspective, we decided to borrow a page from the book "Rethinking Agile: Why Agile Teams Have Nothing to Do with Business Agility" where he introduced a thinking model called Flight Levels.
As the name says, Flight Level describes how high an airplane is flying. Depending on the flight altitude, the degree of detail you observe on the ground below will change. If you are flying at a very high altitude, you can see for miles in the distance, but at the same time, you cannot see every detail on the ground. On the other hand, if you are flying at a lower altitude, you can almost look into the bedroom window, so to speak. However, you can no longer recognize the areal extent of the city. Each flight level has its own characteristics and advantages but also has limitations on what can be seen.
We can apply the same principle within organizations. Using the Flight Level model, we can find out which organizational level offers the best leverage for improvement.
Image from the book Flight Levels by authors Klaus Leopold and Siegfried Kaltenecker
The leadership team operates at the highest flight level, they need to have a clear view of everything, but they don’t need the details. As the leadership team began to change, the true potential of the Agile transformation became apparent. The leadership team was now a guiding beacon for the entire organization, playing an important role in the improvement of multiple Agile teams. They started leading by example, as people naturally prefer to follow those who are leading from the front, rather than those merely yelling and directing from behind.
I came to the realization that company leadership is the key factor. If you direct most of your attention towards operational teams and individuals, you’ll get Agile teams and individuals working in isolation. And some of them might perform better than others as a result. However, if your goal is to teach people to adopt the Agile mindset, the most effective approach is to begin by focusing on leadership.
Agile transformation: A journey of change, not a project's end
Setting up your Agile transformation as a waterfall project is at the very least ironic if not outright dangerous. It creates the illusion that the transformation is something that has a beginning and an end.
Implementing changes on a broader scale follows a certain pattern. You can change the way you interact with your coworkers at a moment's notice. However, the difficulty of changing interactions of a large group of people spread across space and time increases exponentially with each added person. These changes can take months or even years. From my own observations, significant changes became noticeable after approximately 10 to 12 months, but this was at an individual level. On a larger scale, it took almost 3 years before we could confidently say that we’ve changed for the better.
My experience going through this process has taught me what Emerson knew 150 years ago: it’s not about the destination, it’s the journey that matters. The outcomes gradually reveal themselves, evolving in small increments. To adopt Agile principles, the focus should shift away from superficial alterations in terminology and job roles and instead delve deeper into nurturing the right values and cultivating a compatible mindset.
I wouldn’t call the transformation project a failure; in fact, I wouldn’t even categorize it as a project. I see it as an important step towards achieving an ideal known as Business Agility.
