This series is about agile. Not AgileTM, not Big A Agile, not the type sold in three day certificate programs, not the nice neat packaged set of rules Agile, not the type mandated from above, not the religious kind.
No... this is a series about real agility. An idea, a concept that is more than a set of rules and roles. This is my contribution to help my fellow software developers out there, struggling against the frankly terrible practices being carried out in our industry in the name of Agile. This is a series about taking the power back into the hands of the real experts, the software developers. That is where agile began after all.
This is not going to be a post, a series on how I hate Agile. It will be a series on how to avoid the fate of so many failed Agile implementations. We'll look at what the common dysfunctional practices and mindsets are, how to call them out, how to identify and eliminate the endemic double-speak and how to focus on what true agility is. Ultimately it will be management you have to convince and convince them you must.
First all, please check out the Agile Manifesto and its 12 principles. It is super short, and still relevant to this day regarding agility.
Next a couple of quotes:
“Shall we start with this: This is the Agile manifesto and the 12 principles. Notice what this is and (more importantly) what it isn’t: no mention of scrum, no mention of daily meetings or sprints. It’s still possible to disagree with these statements, of course, but I think they represent a laudable set of goals for building good software in many situations.”
“See, in Scrum you have all these rules and roles like a scrum master, sprints, planning meetings, points, backlog, stand ups, retrospectives, and so on. There are rules about the “right way” to do all of those things. There are training programs and certifications that ensure that you know and follow the rules.
In fact, Scrum done “right” according to scrum isn’t agile at all. Scrum the way it is taught is a process designed not to change. That is a massive failure. It breaks the most important principle of agile.
Agile is about contextual change.
To make Scrum agile, you have to be willing to change scrum itself to fit your context. That means more than just the length of your sprint. It should mean that you might not do sprints at all, or stand ups, or points, or estimates, or stories, or epics, or anything.
In a truly agile world, nothing is sacred. You do what makes the most sense in your context to achieve whatever the goal is.”
I don't mean to single out Scrum specifically, but it is the most common flavour and also the most controlling, the most open to abuse.
True agility summed up
No process or practice or meeting is sacred. A truly self-organizing team is one that is given the freedom to adapt, to continuously improve and focus on the technical practices that we know is critical for success.
But in order to be able to focus on good technical practices, the development process must happen at a sustainable pace, a pace set by the software engineers themselves. It is hard to focus on technical practices when you are in a constant state of last minute deadlines and pressure.
The final piece of the puzzle is high quality communication and collaboration with the client. A regular feedback cycle is needed, but that cycle should not interfere with the sustainable pace set by the developers and should not be too disruptive of the makers schedule. Software engineers need unbroken time for thought, contemplation and getting into a state of flow.
Fig 1. True agility
What do we want?
Long term, sustainable productivity
to build the right software
be responsive to change
How do we get it? Real agility hangs off a handful of critical behaviours and values:
Truly self-organizing teams
Technical discipline
Positive, frequent communication
Easy access to requirements
Fake agility, double-speak and dysfunction
Let's compare that to a team that is forced to use an Agile process, one where the only relation to agility is in the name.
"Self-organizing teams" is a term that is touted by the process and bandied about along with words like "collaboration", "responsive to change" and "delivering value".
But the reality is that the team is not free to self-organize. The process and its practices are set, fixed, out of scope. The team is not free to prioritize its work and finds itself being forced to justify everything it does. Functional behaviour, "business value", is prioritized over everything else creating an architecture of quick fixes and "get it done for the demo" short cuts.
Software quality suffers, tecnical debt rises, velocity slows down. There is subtle or not so subtle pressure on the estimates. These estimates are treated as a commitment, and pressure is ever on the developers to under-estimate their work. When velocity slows, we enter a vicious cycle of slow down and more pressure on estimates.
“Perhaps the most important condition required for Agile to work is for management to be clear on the distinction between estimates (a measurement) and features (a control knob) and never push on estimates. Pushing for a low estimate is like pushing a speedometer needle higher: it doesn’t make you go any faster, and now you don’t know how fast you ARE going.”
Fig 2. A process that enables micro-mamagement and control is not agile
Developers, being unable to control their own destiny lose heart and lose motivation. Developers compensate with their own time, longer hours. This unsustainable pace combined with the short-cut mentality leads to a crisis:
developers hate their work and hate the process. Some leave, draining the business of domain knowledge and engineering muscle.
Velocity is slow
Quality is poor
Projects fail
That might sound dramatic but just do a google search on "Agile sucks", "I hate Agile", "Agile is dead" and you'll find out how many people have gone through this.
It's time to stand-up and be a professional
So what can we do about it? We can call out the bad practices for what they are: bad. We can be professionals and not let ourselves be dissuaded from doing what we think is right. We are the experts and we have a voice.
The first and most critical potential battle ground is "self-organizing teams". That's what we'll cover in the next post. Calling out the double-speak and the fakeness, fighting for true self-organization. Without that, you might as well go home now because all else hinges on it.
But some say: you can self-organize! Ok, answer me this:
Can we change the sprint length?
Can we drop sprints in favour of a continuous flow model?
Can we demo when WE are ready?
Can we stop estimating using points?
Can we stop estimates and simply break work down into small pieces?
Can we have a bit more preparation from the business side, before work starts?
Can we stop the daily stand-up? We already speak all day, every day. We'll let you know if there is an "impediment".
Can we use normal language instead of As a, I want, So that?
We don't need a Scrum Master. We already work effectively as a team.
Can we start using Acceptance Test Driven Development? For real.
Can we prioritize technical tasks and technical practices when we feel it is necessary?
Can we organize ourselves so we can get multiple days in a row without meetings, or having to explain ourselves?
Can we spend time on strategic thinking, working on architecture, performance optimization, proof of concepts when we feel it is necessary, without fighting for it?
Can we foster closer relationships with the client not based on a rigid meeting schedule?
In the next post we'll dig a bit more into what self-organization really means and how it is the first step towards true agility.