Agile Transformation again

Fábio Lima Santos
4 min readApr 14, 2020

Agile has been here for a couple of decades right know. Some people say it is dead already. But, in fact, most of the companies in the world never experienced it. Companies are going Digital and still can't be Agile (maybe this is the reason that it takes so long and why it is so painful). And worst, even inside Agile consulting companies it seams Agile is not spread or even well understood.

Let me try to start with the basics here. First of all, Agile is not a process. By definition it can't be a process. If you or your company see it as process, you are not being Agile. That is it.

But it is not so complicated (probably simpler than doing Scrum or Kanban at scale). There are only two, but critical, pillars to agility:

  1. Incremental and evolutionary work
  2. People's ownership of their work

The first pillar is, probably, the most discussed topic inside Agile transformation work performed by consultancy companies. And it is important and really, really hard to learn and to practice.

But the second is the hardest one. And maybe the one that is most misunderstood. So, let's try to go a little bit deeper on this topic: Ownership.

As I said, I hope you already have by heart that Agile is not a process. But what is it actually? Agile is a culture! And if Agile is a culture, the first thing I want to point out is that Ownership is a culture also.

Agile is a culture of Ownership.

And a culture that means that people who actually do the work have the ownership of it.

This principle seams to be very simple. Probably, if you ask inside your company who has the ownership of the work (mainly in software related areas) the answer is going to be: The Team. But don't stop questioning that because it is, probably, a lie. How do you know that it's a lie? Well, we, software developers, have developed a very good sensibility for smelling some problems. We call that Bad Smells, and they indicate you are not going on the right direction. Let's try some of them:

Teams without the required capabilities;
To many people on managing and transversal roles;

When the Agile Manifesto speaks about “individuals and interactions over processes and tools” it is not saying that being people oriented is enough. It means you need better individuals with better interactions over better processes and better tools. In other words, invest your money and time in people, and not in managing people's work (that what processes and tools are meant for). But investing in people to manage people's work it is not a solution here also.

I hope that some day managers are going to realise that managing is about staffing the right people to do the work, and not about trying to make any people do any work. The book Team Topologies [Skelton and Pais] is a great starting point if you want to understand what managing is really about.

After all, if you don't have the right people inside teams, how they are going to own their product?

Experienced people are always promoted to outside the team;

This is probably the cause of the problem of not having the right people inside the teams. If promoting someone with better experience and great results means taking them from inside the team to some managing role, you are probably creating a big problem for you in the future. Your teams are not going to have the right skills for owning their products. So, you are playing against ownership by the teams.

Standardisation of processes, techniques, architectures and technologies;

This is the ultimate bad smell. If you feel you need to standardise processes, techniques, architectures and technologies it is because you have all the problems above and you already failed to build team's ownership.

No CEO wakes up in the middle of the night with the great vision of standardisation of processes. It's not driven by the company's dream, but always driven by operational need.

I'm not saying you don't need to create these standards. You probably need to. But the problem is that you already lost the fight for ownership inside your teams and the only option you have is to try to enforce your unskilled teams to behave in a way that is, at least a bit, more productive then chaos.

All of this are bad smells that the teams are not the owners of their products. If you are investing in these things inside your company, you probably don't have a culture of ownership and you are not agile.

But why ownership is so important?

Well, basically, if you are building something incrementally and with an evolutionary mindset, you are going to have to take decisions fast, understand fast feedback cycles and handle a broad and complex context. It is really easier for a team to receive all the work that is required already defined and planned. The problem is that the outcomes in this scenario probably wont meet the business expectations. It is not a problem of team happiness, it a business problem. It is an existential threat for most companies today to wait for information to travel throughout the company hierarchy to take a decision.

At the end, the side effect of low ownership is the lack of engagement leading to a set of critical decisions made based on meeting managing expectations and not driven by outcomes. In other words, teams with poor outcomes and low engagement. Does it sound a common issue?

So, if you are investing time and money in an Agile Transformation, don't forget to pay attention on these bad smells. Ownership is critical for Agile. Of course, doing Scrum or Kanban instead of Waterfall is great. Even Scrum Waterfall or Kanban Waterfall are better that the old Gantt Chart Waterfall. But don't expect much from it.

--

--