Agile: Simple, Clear—and So Beautiful

– In IT we all mention it every day, but I'm not sure we understand what Agile is. How would you explain it to a five-year-old?

– As the most normal way to get good results at whatever you do. Of course, I'd hardly explain business to a five-year-old. I'd rather tell them that if they're playing a game with their friends and have to reach some goal, this is the most natural, most normal, most sensible way to get there.

First of all, because it's fundamentally childlike.

You don't try to work everything out from the very beginning, the perfect plan. Just like a child, you have a clear direction and an idea of something, and then you start trying things.

That's what children do: they try, see what works, correct course, change the game, experiment. Besides, they usually have no boss; everyone does something, talks to the others, they act together. Naturally, someone will stand out a bit more here or there, but the communication and collaboration are extremely natural. That's Agile.

– And if we move on to an adult who has never heard the word?

– First I'd ask whether they've ever wondered what the difference is between the most successful companies—Tesla, Facebook, whether in IT or not—and everyone else. It usually comes down to this:

the most successful ones have sensible, authentic leadership, self-organization and a clear vision.

The customer, the one who consumes the business, is at the center, and things are built around them. Added value is constantly sought, the company adapts and learns, and feedback isn't just a cliché. These are the things that set the successful apart from the unsuccessful. And I, at least, call them Agile.

Yes, my understanding differs from the common notion that it's some kind of process framework for software development.

– I think so too. I've taken Agile courses and I firmly believe in the approach. The idea, after all, starts with programmers who wrote the manifesto by that name…

– Yes, and the problems they pointed out are very simple. We're talking about top-tier programmers, and this happened in 2001. Among them were people whose work I studied at university, like Martin Fowler. They got together and talked about how to deal with their main problems.

And back then those were the following. “Process above all.” You can see that something could be done sensibly and well, but the process won't let you. No matter which process—decision-making, approving time off. You see things could develop better and more sensibly, but the process won't allow it. You have no way of changing it; what you can and can't do is imposed on you. No why.

The second problem is that documentation is considered the most important thing, while the actual work done, the added value, is pushed aside. Many companies still have this problem today. Say the year-end bonuses depend on a project; then everything has to match the chosen metrics, and the focus shifts:

how to turn the little checkboxes green, not how to add value.

Agile comes from the software world, but it's tied to problems every business has, especially in a fast-moving, dynamic field. And right now every field is like that. If in 2000 there were areas where it was normal for companies to follow vague four- or five-year plans to the letter, working the way they did during the Industrial Revolution, today 99 percent of businesses aren't like that.

– How would you translate Agile into Bulgarian? Гъвкав (gavkav, “flexible”), maybe?

– More like адаптивен (adaptiven, “adaptive”). “Flexible”… we're not going to do the splits. Adaptive in terms of the reality that hits us from somewhere.

You run a business, but the environment and the world we live in don't ask us what the plan is. Mike Tyson said everyone has a plan until they get punched in the mouth. That happens in real life too. Even without mentioning disasters, diseases and wars, every day brings a new technology, AI, a new competitor, a new business need.

You can't afford to tell yourself: I'll follow the five-year plan no matter what happens. That means not adapting.

Many people see it as a kind of lack of vision, of a plan, as total chaos, but it's exactly the opposite. You need a very clear vision. Elon Musk, for instance, a classic example of Agile thinking in some respects, has a 100-year plan.

Agile means a lot of planning, constant replanning and looking for the gaps, for the things that need correcting. That's why we call it “adaptability.”

– In all my time in IT, I've never heard of a company that doesn't claim to work Agile, and most use Scrum as the specific framework. But in the vast majority of cases, I think, it's a cliché. There's no adaptability behind the term; quite the opposite, we move tasks around and have two-week sprints.

– Yes and no. I'll be the positive one here. To a large extent we're all somewhat Agile, because it isn't a state—I am or I'm not—it's a direction, a journey.

Some things work well for you, others don't. You improve some while others lag behind, then the other way round. So if we break down the whole mindset, the principles, you'll see that every company does a certain set of these things, at least in some direction.

In some places there's a form of learning from mistakes—yes, maybe not enough. In others there's a more natural form of collaboration, of putting the customer at the center. These things are there. Just not everywhere, not in every direction, every area.

So we're all somewhere along the way. The problem here is the “cargo cult.”

That's the story of tribes on remote islands who imitated what soldiers had done in order to summon the planes and have them bring chocolate.

When we imitate, we expect the results of the one we're imitating. But that's doing without understanding.

We can call it Agile or whatever we like, but we don't dig deep enough. That happens with a lot of companies.

Unfortunately, the Dunning–Kruger effect is very strong here too. The less you know about a subject, in this case Agile, the more confident you become in your knowledge. And you think: there it is, got it. I understood it in five minutes and we're Agile.

– Alas, this principle seems almost unavoidable…

– Actually, the deeper you dig, the more you realize how un-Agile you are, how many things you're missing. To me that's the big problem: the Dunning–Kruger effect combined with the “cargo cult.” We imitate certain practices but don't understand them deeply enough. We assume that's all there is, because we're smart and intelligent—usually these are people with a lot of experience and a lot of knowledge in a particular field.

That's one problem. The second is that Agile has become something of a dirty word because of all the overselling. At some point the community couldn't agree with itself on whether it wanted to create a model that helps businesses work well or one that turns into a certification business.

The certification business has become a machine where you hand over €200 and get a certificate saying you're great. But when you're in a manager's position, you get a certificate in two days and land in a “cargo cult” company… You run the show however you please, delete the title of the staff meeting and rename it the “daily stand-up.”

Then Agile doesn't work, it's no good. These things are closely linked. That's why we want to change the word, to rebrand this Agile.

– What will you replace it with?

– We're trying to talk about Business Agility. Maybe it's not enough of a rebrand, since it's the same root. But we want to show that it's about business flexibility, adaptability. That's the main goal. Yes, some team introduces certain practices, but ultimately the goal is for the business to adapt.

– Coming into IT from journalism, I realized that, without knowing it, I'd been part of a Scrum process. Publishing a magazine, my colleagues and I had one-month sprints, after which we'd sit down for an editorial meeting, which is planning. Every day—we didn't call it that—we'd have our daily standing outside the newsroom, some of us smoking. So somehow, intuitively, processes lead there…

– Yes, they're very intuitive. But

if we want to reach a high level, we also have to dig deep.

Achieving decent results as a process happens quite intuitively. And it does happen—as it did with you, and with many companies that are small and don't have much hierarchy.

But when we want to grow, to solve the next level of problems, intuition doesn't always help. It matters, but we have to question it, because we work with complex systems. In a complex system—and today they all are—the interconnections aren't obvious.

Very often the saying “you hit it here and it cracks over there” applies. We change something small, and a problem pops up at the other end. A bit like the butterfly effect: a butterfly flutters here, and a hurricane hits the other side of the planet.

We're not always talking about hurricanes, but there's always an unclear chain of cause and effect. That's why being able to recognize it is so important; intuition matters. But it has to be backed by a data-driven approach.

It should also always take the form of a hypothesis. I have an intuition that we need to do something to achieve a certain result. But that's a hypothesis we have to verify—to check whether it's right.

– What led you in this direction? I see you studied technical disciplines.

– First I was a programmer. I have a degree in software engineering, I worked for nearly eight years and rose to team lead and project manager.

The thing is that

at some point you see that the essential problems in software development aren't how to make a piece of code super efficient, but business questions.

Intuitively, I started turning my attention to solving that kind of problem. How do we find the most accurate solution? Why do you make something exceptional, only for the client to cross it out? Or why do you end up with misunderstandings… These different situations shifted my focus.

And besides, I got inspired! I managed to attend a few inspiring sessions by Agile gurus from around the world.

That's how I caught fire. Everything is very simple and clear. And that's beautiful!

Like in software or mathematics. You have a solution that's super simple and clear.

In this case, when I saw these people explaining how my complex problems could be solved in a super simple and intuitive way, it gave me the push to dig into the subject.

– And how did things go from there?

– For a while I was an employee, looking for roles related to Agile. I went through everything—programmer, product owner, Agile coach, Scrum master, enterprise Agile coach—partly because I was looking for it, and partly because I worked at outsourcing companies, where you're constantly on different projects.

On top of that, I dived into the subject itself as a side pursuit: digging, learning, going to conferences. I also started teaching it at Sofia University. I began taking part in more and more public events and conferences, and people started inviting me to give training. It became a second job—someone calls, I run a training, I take two days off.

Demand grew, and at some point it became my main job. What I used to do as part of an outsourcing company, we now do under our own name. That gives me more freedom to act. I consult various businesses and run trainings.

– Tell me about some examples of such a change, whether in IT or not…

– Of course. Sodexo, now Pluxee, is a company that makes meal vouchers. They had a very proactive leader, Gábor Olajos, who knew a major change was coming to their business. A company built on print services was becoming a fintech company issuing payment cards used through POS terminals—a very complex digital transformation.

It was clear this was coming and that it would be extremely intense. A 20-year-old business had to transform from the ground up in six months. And he said, “I want us to try Agile!” We started with pilot implementations and trainings. At some point the law came in, and we got to work in earnest, including with a huge number of outside companies.

Suddenly it turned out to be very easy!

They brought in the suppliers and the other companies they worked with. They organized their business transformation themselves through an Agile approach. They had a two-week cycle in which they reviewed tasks and set goals, introduced self-organized distribution of work, transparency… The six-month transformation went remarkably efficiently.

A second example: a fairly large pharmaceutical company. Again a proactive leader came along and said, “I have a few months to prove that our company's Bulgarian office can be a digital hub for innovation.”

These are business people, pharmacists, doctors with enormous experience in their field, but no knowledge of how to build a startup or a product from scratch. We supported the whole process of generating and filtering ideas, prototyping, selecting and implementing the resulting solutions by new cross-functional teams.

When you hear “pharma,” you picture regulations and slow progress, but Agile turned out to be a very good fit. Because you make a plan, you have five steps to go through… Suddenly a regulation pops up somewhere and stops you, and it's precisely the approach of adapting, replanning and self-organizing that helps clear these things up quickly and sensibly.

The result, which they measured themselves, was a 40 percent optimization, a faster path from idea to finished product. In six months they generated 50 or 60 ideas from scratch, and in the end, through the whole funnel and process, they arrived at two that went into practice. Again by their own estimate, this would have taken two years, and we did it in four or five months—it was summer, it could have been a bit faster.

– And if we go back to the IT world after all?

– Gameloft is a well-known company in gaming. They don't even define themselves as IT but as a studio, even though what they develop is very much a software product.

The interesting thing is that they, too, carried out a sweeping transformation of their entire approach, which helped them achieve much better financial results. It was remarkable: from people saying, “No way, get rid of it, Agile doesn't work, it's nonsense!” to the idea, six months later, that everything should be Agile.

– With this return to Agility, can we say there's no need for additional frameworks like Scrum and Kanban? That they've rather played a part in making us see Agile as a precise recipe instead of a way of thinking?

– Frameworks are needed, but the point is that we have to understand them.

They're simply tools that are good to have. They're not mandatory, but they can help us.

The problem, again, lies in the combination of the cargo cult and the Dunning–Kruger effect. Add certifications to that, and you get this mindset, the negative side.

It's like the sparkling wine we call champagne. Most likely a lot of people who claim to make much better champagne than the French get annoyed. In the same way, the Agile world doesn't like it when we say Agile equals Scrum. Sometimes it may be better never to have heard of Scrum and Kanban.

I personally believe that if they're done with understanding, Scrum, Kanban, Extreme Programming and Design Thinking are extremely important and useful. But you need a teacher who can point a few things out to you. Or, if you don't have one, you need to keep seeking verification of what you're reading or doing.

In the martial arts there's a model of how you become a sensei: “Shu-ha-ri.” “Shu” is the phase where you simply repeat the basics. If it's tennis, you hit a forehand a million times; in karate, you kick the air a million times. That's to master the fundamentals.

In this case, Kanban and Scrum are the fundamentals—someone already knows that these basic moves lead to a good result, a solid foundation.

But we don't stop there. If someone only ever does the basic tennis stroke, at most they'll play with a friend once a week. The next step, “ha,” is where you start experimenting, combining practices, looking for different variations.

The final phase of mastery, “ri,” is building your own style. Rafael Nadal has a highly unorthodox forehand—he hits a distinctive “banana shot,” whipping the racket behind his head. If you go and tell your coach you've watched Nadal and at your first session you'll hit like him, either he'll throw you out or you'll break your wrist.

That's why great athletes build a style of their own that doesn't follow the fundamentals, but if you go to Rafael Nadal's academy, you'll see how they teach you through the fundamentals. It's the same with Scrum and Kanban.

– To wrap up, let's talk about the upcoming conference. Who will be the most interesting speakers, and who should come?

– We believe Agility is horizontal: it's not just for information technology, for banks, for pharma. It's everywhere. At the same time, we really do want to rebrand Agile, to pull it out of the cliché of a team of programmers building something.

And to ask: “Let's see—if I'm a leader in a company, even an informal one, how can I use Agile practices to influence the whole business? How do I want my leaders to influence the business positively too?”

That's the theme of the conference. People in leadership positions, even informal ones, are welcome. The focus is on showing how Agility is achieved—on the one hand through outstanding experts from the business world, consultants, specialists who have written books we learn from, world-renowned in this field. The second track is people from Bulgaria, leaders at a high professional level, who can show from their own experience: look, we're the business, and we did it.

– Great! Thank you for inviting Digital Stories to have a booth at the event, where guests can learn more about my book and my venture. That's pretty Agile… And I'll be glad to talk more about all the important topics we touched on. See you on the 26th!