by Haran Rasalingam
Agile is dead! Long live agile!
ALERT: Bold assertion: The problem with the Agile movement is that it has been around too long. The capital “A” of “Agile” has institutionalised it. It has been appropriated and standardised by the very same forces who have successfully turned all other office work into a stultified, brain-deadening graveyard.
There was recently a post on LinkedIn entitled “Agile vs. Waterfall”. The argument was that Agile and Waterfall are not opposites, but they are complimentary. Some things need Waterfall and some things need Agile. Some things need a phased approach, some things don’t, for example. The article discussion moved in the direction of suggesting that perhaps Agile vs. Waterfall was the wrong distinction to draw. Perhaps it would be better to distinguish between planning up front and not planning up front. I did ask one commenter to give an example of this, but the example given was not software related, instead pointing to the erstwhile structural engineering building a bridge analogy. The debate moved on and then the suggestion was made that the distinction should instead be between fixed planning and adaptive planning.
But although I was myself involved in the discussion, I went away dissatisfied with the conclusion. Is that all it’s about? Phased approach vs. non-phased approach. Up-front planning vs. no up-front planning. Fixed vs. adaptive.
If I am honest, when people start talking about Waterfall/Agile hybrids, I find it immensely irritating. Deep down, what I feel that it usually means is that someone is working in an organisation which is extremely dogmatic about their way of working, but they don’t mind talking about things in small chunks (they latch on to the “iterative” part and usually forget about “incremental”, not to mention self-organising, people over process, etc, etc). It means that the organisational structure is so siloed and everyone is very cosy in their little siloes and they probably hate everybody else. It means they are very institutionalised and disempowered and probably don’t care at all whether software actually gets delivered or not, whether it is done efficiently, whether it is profitable or wasteful. This is what I would call a dead environment.
The spirit of agile (I’ll use a small “a” here) is all about a living, breathing software development effort. It is buzzing with the energy of lots of people caring about the work that they are doing. They are passionately focused on the same common goal and they all pull together to deliver software in the best, most efficient, most sustainable and most pragmatic way possible. This is what I would call a live environment.
So one might be tempted to contest my theory as follows:
– Is it necessarily the case that a phased approach, up-front planning or “fixed” plans lead to a dead environment?
I would say no. However, such approaches, in my view, create a large probability of this being the case.
For me, a live environment is all about caring and a dead environment is about not caring. For example, if a phased approach involves different groups of people doing a piece of work and then handing it off to another group of people, then those handing off have no direct stake in the actual end goal, which means they are less likely to care about the actual final delivery.
Similarly, if we attempt to make all plans up front or remain rigidly fixed to a plan, then once again, the software development process is less owned by the people doing the work in the here and now. They are detached, less invested and hence care is likely to be reduced.
OK, let’s turn the question the other way:
– Does a non-phased, adaptive approach automatically lead to a live environment?
Once again, I would say no. However, there is a much greater probability of this being the case. Such approaches do not imply a live environment in and of themselves, but they prepare the ground for a live environment in a much better way.
For example, if we don’t have the illusion of a full and complete plan (for illusions are what they usually are), this brings to light with much greater transparency the need to continuously think about what needs to be done. It results in a thinking, creative, intelligent atmosphere. And if the goal of each piece of work is to deliver working software, then this means that the goal is clear for everyone to see and thus everyone is more likely to be working towards that same goal in a focused way.
However, many are the “Agile” software development efforts which look more like dead environments than live ones. Why is this so? I have often seen the sprint cycle and the working through of the backlog also turn into a monotonous grind. This means that dogma has set in. The spark has gone because too many of the people involved in the project do not care anymore. I often hear about companies who are already “doing Scrum”, but they need someone to come in to “freshen things up”. This means that the team is doing “dead Agile” and they need to be doing “live agile”.
The “dead Agile” state of affairs comes about when a team is probably not as self-organising as it could be. Perhaps the person carrying out the role of Product Owner is not really the owner of the product, which means that they do not really make the decisions and also that they do not really care. Perhaps there is no drive coming from anywhere to get things delivered, perhaps no one close enough cares how much it is all costing. In summary, I would say that it is a question of care. If people care, the environment is live, if not, then it is dead. And I believe that Agile approaches give companies a better chance of setting things up such that people close to the actual work care about delivery.
Which kind of environment do you work in? A dead one or a live one? Because that’s the real point.
