1. How It All Started

One summer afternoon in 2010, I was given three departments of software developers, software testers, and hardware designers and was asked to form one new department of engineering from them—a department with high collaboration and flexibility to build cross-functional teams across those three domains. The department would serve our customers better, with higher flexibility, creativity, and innovations, while keeping our technical excellence and living the company’s vision: “Added-Value Solutions.” I was asked to come up with my own idea of how I wanted to run my new department by the following week.

I went home, sat in the garden, and thought about it. My first feeling was “Wow! I can make a difference!” And then it faded. . . . The image of 120 people coming to me every day with their questions, requests, and approvals was overwhelming. I felt tired before I had even started. It felt like the beginning of a storm: thunder and lightning, dark with no hope. I started to think about names and hierarchy.

The next day brought new energy. Later that week, at the next executive meeting, I got the courage to present a very different structure based on a network of self-organizing teams with only Scrum Masters rather than managers and a new position structure of only team members instead of people’s original roles. I was both excited and nervous about my presentation of a flat team.

Our chairman was a typical traditional manager with a hierarchy hardcoded in his DNA. He always wore a suit and kept his distance, and he had the aura of a person who could never be wrong. On the day of the executive meeting, he was clearly in a good mood, sitting in front, making jokes. Then he started a meeting: “Let’s start with the engineering structure. We need to know who you expect to be in the management roles.”

“Sure, let me connect to the projector,” I said. My mind was exploding: Management? I don’t have any. . . . What if he . . . ? No, that’s not going to happen. . . . He is not going to fire me in my first week. . . . What if I . . . ? No time to change that. . . . Here it is, I need to start.

I took a deep breath and started: “You asked me to come up with my own vision of the new engineering department, but let me first summarize the goals we need to achieve with this new department.” It was good, I had their interest, so I continued: “The department should have high flexibility and a fast-learning environment, and it should deliver added value solutions through innovations, creativity, and technical excellence. Is that correct?” I paused and looked around the room. They were nodding, seemingly in agreement. The chairman started to become impatient—his eyes were saying yes, we all know that, move on.

So I continued. “I did a research about companies that are similar to us, read several case studies and articles about the way they work, and came up with an organization that is a flat structure based on self-organizing teams with no management in the department.”

“With NO MANAGEMENT?” the chairman asked with raised eyebrows.

“Yes, no management,” I continued. I had to be fast and deliver a simple message. “No management actually enables the empowerment, motivation, and creativity we need in the department. It’s a natural continuation of the agile team structure with Scrum Masters we currently have in the development part of the organization.”

“So you want to make us all agile?” he asked, as though he’d just heard a joke that made him smile, clearly recovering his good mood.

“Yes . . .,” I said slowly, still puzzled by the turn of his mood.

“Let’s do that,” he continued. “After all, we’ve chosen you because we need a change, right?” There was nodding around the room. “We’ve been stagnating too long and have to turn this company around to be much more flexible than we are now. We have to attract new, talented people. Frankly speaking, we want to be a modern organization that attracts people in the region and is a model for other organizations to follow. Let’s talk this afternoon about how you plan to do it.”

The meeting continued, but I don’t remember the rest. We were done with the team-level experimenting phase on our agile organization journey. I still don’t know why the chairman said yes to this crazy idea, as he was generally very conservative, hated experiments, and had been fighting this flat structure with emergent leadership almost every day. I think part of it was that I was able to link my plan with our strategic goals, which resonated with him. Agile was not our goal, but it was the best way to achieve our strategic goals. It was a hard journey for everyone, as we all needed to change significantly, but if I had to go back, I would do it again. It worked and we made it. We achieved our dream goals, and only one person left the organization because of the change. It was a lot of work, and I’m glad I had this opportunity to learn and grow as an agile leader.

Agile is not your goal—it’s only the best way to achieve your goals.

The Need for Change

In most organizations, you realize that to bring about change, you first need to fight the pharaoh syndrome, where the shared feeling is, “We don’t need to change. We are a successful organization, and nothing can happen to us.” Such overconfidence stands in the way of any change. And agile requires quite a hard change in the way we work and in our mindset. The very first step of the eight-step process for leading change described by Kotter [Kotter12] is to create a sense of urgency. Simply ask why. Why do we have to change in the first place? What is the need behind it? What would happen if we don’t change? And unless we can find a good enough strategic reason, maybe we should not even start.

Agile is not your goal—it’s the way you can achieve your strategic goals. I reiterate this statement at the beginning of this book because without a really important reason for change and without a sense of urgency, no organization will move, no leaders will change their habits, and no change will happen. Let me quote Mike Cohn from his keynote speech at Agile2010 in Orlando, Florida: “The goal is not to become agile; the goal is to understand how to be more agile. Agility is a result of a mindset, not a process. An enterprise will never finish ‘becoming agile’ because it will always find ways to improve its operations” [Kessel-Fell19].

Before you start reading, do this exercise to make sure you have a sense of urgency yourself.

Why do we have to change? What is the need behind it? What would happen if we don’t change?