Cargo Cult Agile (2008)

At one point I had a talk with a director of a smaller bank, and he was enthusiastic to bring me on board, even wanted to pay me just to spend my workday in the office doing nothing specifically. I declined, because it was a lost cause: their team was too fragmented, their processes were too convoluted, their estimate for a very minor change added up to several months...

Yet, I felt bad about it, because I wanted to help them, but in that environment, I was not able to do anything. How do you approach such situations?

When you think something is stupid (like adopting only standups), frequently it's because you don't understand the motivation behind it. Standups are one of the first obvious changes any team, no matter how oldschool and rigid, can adopt and see the results behind it quickly, to encourage further transformation.

When you're changing something big (like a development process that is stable, consistent and filled with people, resources, operational and deployment plans, etc.), you want to change it either radically, or chunk by chunk. Radical changes are easy to decide yet hard to pull off while preserving business continuity, it's a bit of a gamble not everybody is willing to take. So, many executives want the "transformation" to actually be "step by step evolution". And one of the first steps are standups and enhancing the planning.

All of the above doesn't debate the fact that there are companies which get Agile terribly wrong, and companies which can't get Agile right due to extremely rigid structure. However, not all companies who fail to visibly transform into Agile in a few easy steps are like that: sometimes they're stuck on early iterations, slowly working their ways further while preserving continuity and market momentum, and there's nothing wrong with it.

In one occasion, where they officially brought me in as an agile coach, I tried to at least achieve some local optimum with the team, because some big improvements were plain impossible. I occasionally talked to managers about all the walls we were constantly hitting, but the answer was always "we can never change that in this company". This did not stop me from mentioning the problems, though.

Most company actually hire me as a technical coach or as a developer. There it is easier: When changing the way the team works is not officially my responsibility, I will still mention things that could be done better. But when the company does not listen to me, it is easier to let go: Then I'll just focus again on helping the team dealing with their legacy code monster (or whatever else I was hired to do).

So, in short, my strategy of dealing with it: Never give up mentioning problems and trying to establish a culture of continuous improvement with small experiments. But don't get too frustrated when they don't listen.

Also, often they do listen, and things get a little bit better ;)

How do you deal with those situations? Do you have a different strategy? What could I try to do differently?

Stand ups didn't really work for us either as we are doing our own thing most of the time, so there is little to coordinate, and when there is a need, we usually just work closely together.

> Individuals and interactions over processes and tools

This does not mean that you minimise process and tools. This means that individuals and interactions trump processes and tools. So if you have a process that doesn't fit the people on your team, then you change the process, not the team. Similarly, you try to encourage interactions through as many avenues as you can. You don't say, "You must use this tool and only this tool to communicate".

But it's a mistake to think that you want to remove process. That's not "agile". That's "ad hoc". There is nothing particularly wrong with ad hoc processes if you are successful, but the "we'll just use common sense" approach that many teams attempt is usually anything but successful.

Process is there to support individuals. When I am coaching a team, I never go in with the idea of introducing any particular process. Of course, I am more skilled with some processes than others, but imposing my skill on a team I am coaching is not going to be successful. Instead, I watch what people are doing and write it down. That is the process. At that point I start looking at problems that we can solve. I look for places where the process is not consistent, or where people are struggling because they don't know what to do. Then I try to extend the existing processes so that it is consistent across the team. Finally, I start introducing things that I'm skillful in where I am sure it will make a difference. At this point the team is already delivering with their process and we are just looking at ways to optimise.

There is a lot more to it that this, of course. However, for me this is the minimum thing that you need to do to coach a team. I've tried other approaches (when forced to by upper management), but I've never been successful.