Is it agile? Is it Agile? Is it not? What is agile? Is agile scrum? Is scrum agile? Should you be agile? Is waterfall dead? Or is it not that bad?
Sure is a lot of debate all around. Debates around semantics. Debates around methodologies. Debates about whether something should be considered agile if it didn’t receive the blessings from one of the original founders. Debates around estimates (spoiler: there’s universally despised). Debates around whether it scales, or whether it Scales. Debates around capitalization or not of the A. And more generally, debates around whether the well has been poisoned and should be abandoned, or even, whether it’s never been good to begin with.
What is agile? Agile is a set of 4 values, and 12 principles, that a bunch of devs listed as what they observed worked the best to build software. A lot of people might argue that it’s much more than that now, and yeah, call me a dick for shitting on historians and semantologists to then become one. At the very least, that’s how it started.
The values are pretty straight forward: talk to people, cut the bureaucracy, adapt to change. The principles are pretty much just an extension of that, release often, build stuff that brings value, satisfy your customer, hire the right people and trust them, write good code, continuously improve, do it in a humane way. I don’t know what’s to be angry about from that.
The problem comes entirely from badgile1, the maladaptation of agile’s derivatives, mainly scrum, and sometimes as of late, SaFe and its friends. A mixture of not giving a shit, cargo cult to various degrees, FOMO, envy, industrialization, and then denaturation. It all started with people implementing scrum without understanding that the point was to iterate on working software that was valuable for the customer. Emphasis on estimates, emphasis on backlog, hey what’s Jira? Oh cool I can make my process rigid again! Next thing you know you’ve got two weeks v-cycles on very much waterfal organizations. Marginal success increased penetration, to the point that now enterprises were getting itchy on what their little sibblings are all doing, which somehow seemed to be somewhat working better than what they were doing.
Individuals and interactions over processes and tools
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
But hey! Enterprises have very different problems! Your process doesn’t scale! Our needs are different! We’re professionals here, we can’t do with wishy-washy “it’s gonna be ready when it’s gonna be ready”. We need guarantees. We need plans. We need stamps. We need control. We need accountability.
Responding to change over following a plan
Any semblance of trusting people gone through the window, the very agility that was the NAME of it, through the drained, to this day, doesn’t even make anyone blink that their agile roadmap is 1 to 3 years long. Story points! Awesome! We’re gonna be able to measure progress! (Wait, progress is measured by how many points you release, right?). Sprints!! AWESOME! We need to go fast!! Certifications! Training! COOL!
Next thing you know everyone, from the most enlighted startup to the oldest waterfall gaz company claims to be agile, so long as they have 2 weeks sprints. Suddenly the thing has a bad name.
How to be agile: use your brain
The last of the principles is probably one of the most important:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
When you read this as “meet yourself in a room for 1/2h every other week, fill in the quadrants, check that box we’re Agile”, you lost. The cadence is good, but if you think that all that needs improving is marginal bits of the process, you’re missing the point there.
The best architectures, requirements, and designs emerge from self-organizing teams.
The point is, the point always has been, organize yourselves around what you’re doing, and find how to do it best. Maybe read books, they might give you ideas, structure your thoughts, provide tools. Start with lean. Don’t justify implementing something because it’s written in the certified process guideline, or because it’s best practice. You’re just doing cargo cult. Instead, your default should be to not include something. Understand why something is proposed, and include it only if it applies to you. Wait, I think there was something about that in the manifesto?
Simplicity–the art of maximizing the amount of work not done–is essential.
Don’t post-rationalize process tid-bits. Understand why they’re here, and if they don’t bring more value than what they cost, get rid of them.
If your default response to improve anything is to add more bureaucracy maybe pause for a moment and look into the mirror.
How to scale agile? More autonomous teams, decoupled architecture that supports it, less bureaucracy. Structure your organization and architecture to support your process. And vice-versa. If everything depends on everything, then yeah, dependency hell and all that.
Or maybe not, I’ve never seen autonomous teams and decoupled architecture in a large org. I’ve always seen the logical opposite of that, long negotiations on roadmaps, plans for dependencies established years prior, approvals that go all the way up, etc. Easy to comment from my vantage position of a non accountable pawn! If you throw enough money at it, it might even look like it’s working. Is it optimal? Whenever I managed somehow to get a team to be somewhat autonomous though and escape that process, it’s always resulted in massively increased results. So I have my doubts about that.
Stop throwing the baby with the bath-water
Are you looking at metrics every two weeks and adjusting a plan? Are you having bi-weekly meetings with customers where they provide feedback? Cool! Do scrum. Or don’t. Just, be aware of the price you pay for process, either in time or rigidity, and adapt accordingly.
You can’t do without dates, you need to be able to report on progress? Sure. Use burn-down. (Do you really need dates though? Maybe start with that.)
The Principle of Quantified Cost of Delay: If you only quantify one thing, quantify the cost of delay.
~ The Principles of Product Development Flow: Second Generation Lean Product Development, Donald G Reinertsen (NOT SaFe as internet would have you believe)
There are bad estimates. There are good estimates. Where they’re good and bad at varies. Estimates that help decisions are useful. You need to determine a budget, you can’t do everything: you need to prioritize. Starting with small and very valuable is better than starting with expensive and not so valuable. You can’t decide about that if you don’t know how much stuff costs (I’m talking capacity planning-level here). Estimating as an exercise to get devs to talk together and simplify their designs? Why not, if it works for you! When estimates start migrating into progress tracking, or worse, performance tracking, they’re becoming worthless2. They add to bureaucracy at best, participate to the illusion of control.
Is it agile? Should we do agile? I don’t think we should care about the semantics. What we should care about is understanding what we are doing, why we are doing it, and improving. It annoys me when people want to throw agile as a whole, because despite the wrong implementations, there’s still so much good in what has been created in that trend. At the very least, the manifesto gives you a good set of values and principles to ground your progression and continuous-improvement, the methodologies can give you some tools to instrument your process, and everyone in that sphere can give you ideas and motivation to do better.
Just stop with the story-points, and with the bureaucracy. You don’t need it.