"Agile" is all over every workplace from municipalities over manufactoring to of course software development. Everyone has caught the "bug" and everyone talks about agile as the best thing since sliced bread. Agile is of course a framework that somewhat encourages you to take the things you like and get value from and leave out the rest. The movement in of itself is not trying to push some magic pill on you - there are just a lot of people who did not get that memo, and talks with the same objectivity about agile as your newly-turned vegan friend talks about your 500 gram steak.
But this piece is actually not trying to bash agile (or vegans for that matter) it is more a stream of thoughts and reflections on what agile has been interpreted to mean and where the implementation has perhaps gone a bit too far.
Defining "Agile"
As almost everyone has their own interpretation of agile ways of working I will start by describing what I lay in the meaning of agile.
Agile seen from my perspective, is about quick iterations and quick learnings. It is about shortening the feedback loop and course correcting as quickly as possible along the way. It acts as the anti-thesis of "waterfall" or is often put up against "waterfall". Waterfall is painted as the process of making sure you lock yourselves into a room and cut all communication with the outside world - especially your customers - because by doing waterfall you have obliged to have tunnel vision and only deliver what was originally planned, and by no means change anything along the way. Change along the way is patented by "Agile"! (Irony may occur)
Reflection - anyone?
Seeing Agile in this light of quick iterations and quick learnings, my concern becomes visible. Because while I do really like the aspect of quick iterations and feedback i feel like it has somewhat killed off thoughtful time for reflection. It is as though thinking has been totally replaced by doing. As if people has totally lost the value of actual thoughtful reflection on a problem.
I get it that you cannot have a team full of developers sitting for hours reflecting over their work, but that does not mean that nobody should spent time reflecting over whether the project is moving in the right direction. Whether the ideas that are being quickly iterated makes sense at all.
Quick iterations are good if you have an idea about what you want to do, but you are unsure about the actual implementation. They are also very good if you are trying to keep up with a competitor that is already ahead. But in my opnion it is not always the best way forward for all situation.
Faster horse
As the old quote by Henry Ford goes:
If I had asked people what they wanted, they would have said faster horses.
If you attack a problem head on and iterate quickly you may end up doing the faster horse instead of taking a step back and seeing whether horses is really the future or not. This approah may be right, depending on what you want to achieve.
In my experience "Agile" has been a way to shift analyses work to development - meaning that it is better to have the developers try something out instead of spending the effort of analysing the problem properly. This can of course cut both ways. Analyses paralysis is a real thing and should not be ignored. In some organisations the bar had perhaps swung to hard in the direction of analysis and you ended up with these multi-year projects only inquiring actual feedback at the big-bang launch.
This is of course not what I am advocating getting back to. I fully acknowledge the value of agile ways of working and the iterative approach. I have just met a lot of overemphasis on the efficiency of this applied across all functions in an organisation. It has absolutely earned its place and merit, but it should not be over-done and kill time for reflection for the functions that actually require that.
Even though our society does its best to distract us in any way possible I actually still believe that there is merit and value in the good ol' time for reflection.
Top comments (0)