The only thing you can do wrong in agile is to work the same way you did 3 months ago.
Corollary: The opposite of agile is static.
“The only thing you can do wrong” is born out of two things: my belief that agile is all about learning and putting learning into action.
Second, the proliferation of “agile tests” – maturity models, things like the Nokia Scrum test and the mental models in our own minds which condemn teams . Failing these tests means you label the team something like “Agile in name only”, “ScumBut” or “ScrummerFall”. I’ve seen my own share of these teams but honestly, I don’t care. Motivation to change a bigger issue, as long a the team are trying to improve its just a question of time – you might be “AINO” but if you keep trying you will become “Kick-ass agile.” (Plus, as an agile consultant these teams are potential clients, send them to me!)
If you are learning and attempting to act on that learning you will make some false moves, you will need to undo some changes but over time you will move forward.
You need to learn in three domains: Solution domain – the tools and technology you use to craft solutions and systems; Application or problem domain – understanding the problem/opportunity you are trying to solve/exploit, understanding what customers’ need and what the market will pay for. (I tend to think of this as the demand side); and the Process domain – the way you work, your processes and practices, the most obvious place were “agile” fits in.
The boundaries between these domains are fluid you need a learning culture in all three.
More recently I realised that “the only thing you can do wrong” has a corollary:
The opposite of agile is static, not learning and not changing
20 years ago agile advocates invented Waterfall to be the enemy – sure the cascade model, Ã la Royce, was industry standard but nobody, NOBODY, called it Waterfall – believe me, I’m old enough to remember first hand. Agile was described by reference to what agile was not, and that not was named “waterfall.”
But that is wrong.
The secret is in the words: Agile implies movement and action.
Not moving is called Static, so the opposite of agile is static.
Once you accept agile means movement and change the next question is: how fast?
Rather than agile tests and “agile maturity models” we should be to measuring the speed of change and the speed of improvement: how fast are the team learning and acting on that learning? how successful are they at that?
When I floated this suggestion on LinkedIn a few days ago a few people pushed back. One argument was that I was advocating “change for change’s sake”. I’m not. You are free to not change, you are free to not change if you wish, all I’m saying is don’t call that agile, ‘cos its not, that is static.
Not changing is static, and static is not agile.
Now maybe static is the right thing for you. If your team can repeat their way of working, if they are predictable, and if the team and stakeholders are content then then change! Embrace static.
I’m doubtful such a static position is anything other than a short term Stable Intermediate Form. Static implies a stable environment, one in which at all forces are in equilibrium: nobody is asking for faster delivery, nobody is changing their ask, nobody is complaining about technical debt, overwork, predictability and so on. If people are not complaining then celebrate, you are living the dream! Just don’t call it agile.
“Finished” software is static because nobody changes it. Software ages because it stays unchanged while the world around it changes.
A second argument was that constant change was not good for people. Now I’m not arguing for constant big change, or constant top-down change. In my mind agile change is largely incremental – sure sometimes you need a big change but most of the changes are small.
I also challenge the assumption that change is top-down and that change is done to people. In my experience when those doing the work are enrolled in the change process, when they can see the potential benefits then it is a different matter. In my experience “change resistance” is more likely “resistance to being changed.”
Finally, “last 3 months”. That time frame comes from my intuition, it is a period long enough to see if change has happened without demanding that the team are never repeating themselves. I imagine the team moving from one Stable Intermediate Form to another Stable Intermediate Form over those 3 months. Feel free to suggest another time frame but if you think 3 months is not long enough to see change then how long? 4 months? 6 months? 12 months?
Subscribe to my blog newsletter and download Continuous Digital for free