We are uncovering better ways of developing
The First lines of the agile manifesto
software by doing it and helping others do it.
Since the adoption of the agile manifesto, we’ve spawned dozens of ‘agile’ methodologies[0], in pursuit of better ways of developing software. Given the staleness of software today, it’s evident we haven’t uncovered better ways of working.
Computers microprocessors (such a quaint word, given where we are today) are thousands of times faster than what we had available when the agile manifesto was written, and yet I write this on WordPress’s online block editor, on a MBA 2019 model, in Firefox, and the cursor is very slow. It takes ten seconds to paint 12 characters. I’ve force-quit everything I could, and only one tab is open.
23 years ago, the major problem facing software teams was the planning process. Software Development methodologies looked a lot like manufacturing methodologies: capability research, capacity planning, design, development, testing, and maintenance. Each step was discrete and carried into the next. The folks that met at Snowbird saw this process as the enemy of good software; and for a time[1] they were right. For a time the ability to take an idea and put it into production in weeks instead of months and years was the greatest improvement in the delivery of software. Instead of conquering that mountain and moving on to the next, we’ve stayed there, built a city, and let it decay.
Software delivery times have decreased[citation needed], and software has gotten worse to use. We’ve spent so long optimizing for delivery that we’ve completely forgotten the purpose of software: To make our lives better.
Cory Doctorow calls the decay of software enshittification, and he explains that it’s due to platform lock-in[2]. Even without platform lock-in, we’d be in this mess. The incentives are the same in all cases — a desire for faster, cheaper software — but the problem is culture, not market position. It’s endemic to how we create software. We’ve drilled it into ourselves that we have to do things cheaply and faster than fast. Since most software organizations have adopted agile in its various forms (sigh: Scrum), then I’m going to blame our current predicament on our over-reliance of agile as the answer to our problems in developing software[3].
It’s 22 years old, it can take it.
I accidentally touch my trackpad (also a quaint word) and the block editor dialog menu pops up. I move my cursor across the page and the editor menu pops up over the words I’m reading. Frustrated, I have to move the page and click further down to get the editor to stop popping up over the words I’m trying to proofread.
The company that makes wordpress dot com, and who makes this block editor is Automattic. Automattic is valued at over $7.5 billion. $7.5 billion! I hope they would spend a mere fraction of a fraction of that on fixing the problems with this editor. The wordpress dot com block editor editor is more downtrodden than a Dickensian protagonist in the first act.
There is one common theme that unites the software process of teams at tech unicorns, mom and pop shops, and startups, Agile. Popularized by the agile manifesto (yes, yes, I know, the Scrum folks will claim they were first, but the wheel by itself wasn’t popular until someone put it on a wheelbarrow), agile has come to mean any iterative software development process that ideally pays lip service to the principles of the manifesto[4].
Agile was an iterative software process codified in the year 2001 by mostly programmers and consultants, at a ski lodge and focused on the areas of agreement, along with principles for software teams and businesses to follow in the development of software.
What emerged was the Agile ‘Software Development’ Manifesto. Representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven, heavyweight software development processes convened.
From “About the Manifesto“
Far better than the waterfall methods that preceded it, the agile manifesto focused on producing working software in weeks instead of months.[5]
Agile’s tenets are simple[6]:
1. Get working software in front of a customer on regular, short intervals.
2. Use the feedback from customers to iterate on it.
3. Inspect how you build software and adapt to change brought on by the your customers, the market, stakeholders, and the changing skill-sets in your own team.
4. Make adjustments to your process, and rinse, lather, and repeat — indefinitely.
The process itself relies on a focus on the team building the software, with a bit of ignorance towards the processes that businesses need to survive. It all but ignores the cost of producing features in favor of just doing it. It ignores the cost of long term maintenance, of saying yes, in favor of a process that says yes and delivers in short intervals. It does not elevate the creation of software to the realities of the business that relies on that software, and instead posits that somehow if you inspect and adapt enough, you’ll be a better software feature widget maker and that is what your business needs.
Agile delivery pairs perfectly with a sales-driven feature factory, where new features drive new sales, until all of it collapses on the weight of itself and the business is forced to sell itself or start over from scratch. IT Projects are either too simple to be useful, or too complex to be delivered (or replaced) successfully, all while the team inspects and adapts every two weeks, like clockwork.[7]
Of course, it’s not supposed to be this way. One of those cute little things we say but rarely practice is, “Agile is the art of maximizing the work not done”, where you can be agile by saying “no”, and where saying “yes” creates commitments, which wears down the team’s ability to move… well.. agily.
Is this agile’s fault? Yes. If the rules of the game are vague enough to drive a truck through, the rules are at fault. If the rules of the game regularly produce outcomes that are sub-optimal, then it’s up to the rules of the game to be fixed.[8]
Agile has several truck-sized vagaries that we ignore at our own peril:
- There’s a cost to being agile. There’s a cost to delivering that widget that the CEO or the sales team says the customer wants. To delivering what someone asks for, and not looking deeper into their expensive problems and seeing if it should even be solved how they’re asking. This has to be the cornerstone of any software process: uncovering the root of the symptoms the customer talks about, and digging deep into that, and its first order causes and second order effects. If you thought you’ve dug deep enough, you probably haven’t. I like Jonathan Stark’s Why Conversation for this; because it tries to talk the person out of that thing they say they want and uses three questions: Why This?, Why Now?, and Why Are We the ones that need to solve it?
A process that optimizes for quick-turnaround, for learning through iteration, encourages us to stop at the level of “produce what is asked for, not what is needed”.
2. Inspecting and Adapting is not nearly enough. You can’t solve the right problem without being in the room where the problems are discussed. By the time the problem has gotten to the ‘agile team’, it’s become a directive with a solution. The idea of a cross-functional team doesn’t take into account budgetary and business considerations. Those become inputs that the product manager or “Product Owner” uses to decide what to build that fits those parameters, without the team being fully involved in the business problem definition process and the budget process. If the team isn’t talking budget numbers, they aren’t close enough to the business processes that define success and failure.
How many times have we seen a matrix of decision making? The Product Manager decides what to build, the developers decide how to build it, and the business decides how to use that to solve its problems. Those divisions have caused more harm to our industry than any other singular mindset.
Businesses don’t make line teams part of the budget or business goal planning process. By the time the realities of the business get down to the teams, it’s purely an exercise in specific features or at best KPIs/OKRs that need moving. This is a fundamentally broken process that agile encourages in part of its origins of being development team focused.
3. Features are promises realized. Likewise, broken features break trust. The idea of deliver, then iterate presupposes two conditions that are not universally true:
- That the broken feature will be improved until it’s good (instead of “good enough”), and trust regained as the feature improves.
- That you can make up the loss of trust brought on by broken features with more features.
While this problem has existed long before agile, agile normalized delivering broken features and iterating on it until it wasn’t broken any more. It did this for good reason — that it’s better to deliver something half-baked early than it is to deliver the perfect thing months too late. And the sentiment holds truth: if you want to know whether a feature will be used, ship the feature. But the realities of software development have made this mantra a punchline.
As I keep the browser window open that I’m typing this into, WordPress’s cursor and text being painted into the editor is taking longer and longer, with me waiting 10s of seconds for it to catch up to me, and futilely moving my cursor to correct a spelling mistake because WordPress was 10 seconds behind me by the time I stopped typing.
Move fast and break things
Facebook internal motto until 2014
The agile world has brought us a world where broken is normalized, where Perfect is the enemy of the good has become a rallying cry for agile software delivery. This is where I align with Cory Doctorow. Customer lock-in is an easy path to repeatable profits, and VC money means there’s a new market to chase, and no need to keep the existing market segment happy, and that the fundamental practice of making good software is shunned in favor of finding new ways to extract attention from folks. Our whole process for creating software is optimized for this world[9].
4. The gulf between the software team and the team making the business decisions grows wider each year.
Ben Affleck: “Wouldn’t it be easier for NASA to train astronauts how to drill rather than training drillers to be astronauts?”
DVD Commentary, Ben Affleck on the premise of the movie Armageddon
Michael Bay: “Shut up.”
There’s one key ingredient that’s missing from software teams, and that’s the budgetary authority and responsibility for the software that’s produced.
Teams don’t control their own Profit and Loss, they don’t control their own headcount, and they are often the last to know about any strategic changes in the software they’re charged with delivering. While this practice makes (some) sense in developed industries like Construction and manufacturing; it falls flat when you try to apply that to a software team. Software teams don’t have a known cost for a feature. The budget for a block editor (like wordpress’s block editor) could range from a few hundred dollars a year and forty hours of developer time to several hundred thousands — or even millions of dollars. There’s a whole ton of context around the budget that the developers have that most other folks won’t have. In some companies, getting that budgetary authority requires the CTO to step in, and often it becomes a negotiation (at best) with the CEO and CFO to allocate a pot of money. By the time it gets down to the team, there’s no discretion or authority to change from an obviously bad approach.
It’s sort of like 20 privates trying to tell congress how to run the Army. Yea, they’re in deep, and yea, they understand the ‘on the ground’ problems, but the Army’s on the ground problems and their strategic problems are miles apart in theory, even if they aren’t in practice.
The second biggest issue — besides the wrong framing for trying to fix the problem — is the lack of institutional buy-in from the business side. Agile requires business folks to buy in to the idea of incremental delivery, frequent introspection, developers being as close to the customer as possible, and maximizing the amount of work not done. And I mean really buy in. Owners of businesses will often fashion themselves after Steve Jobs and believe they’re a good proxy for the customer. They aren’t.
CEOs will often claim incremental and iterative delivery is in their best interest, and then want a delivery plan for the next quarter, or 6 months, or a year.
It’s impossible to have an accurate, or even 50% accurate, delivery plan for a year in an industry where priorities change weekly or even monthly, and yet software folks are expected to stick to their estimates as gospel quotes.
Even if agile is a perfect software delivery process (it doesn’t claim to be), the problem lies not in agile, but in our reliance on agile as the be all and end all to creating software.
We’re doing things the same way we did them 23 years ago.
“Agile” is 20+ years old, SAFe is taking the enterprise world by storm, Scrum Masters are being laid off while the Scrum industry deals with fallout from the broken promises of Scrum. Experienced software folks have moved on from Scrum to kanban or “scrum, but” (we do scrum, but we don’t do X, Y, or Z from the Scrum guide — or my personal favorite — we do the parts of scrum we like but we haven’t actually read the scrum guide recently), folks are still calling “scrum events” ‘ceremonies’ or ‘rituals’, and we live in this bastardized world where the rules are made up and the story points don’t matter — except to the executives that take them as gospel truth.
This is not a great place to be.
We’ve known story points were bad for over a decade now; and the last four years it’s become mainstream enough you’d think we’d have dropped them, but we haven’t.
We’ve known developers can’t estimate unless you break down ‘stories’ so small that it becomes trivial to estimate each part, and we also know there’s very little value in spending enough time on breaking down stories that small you can estimate them, but we still have business folks pressuring software folks for estimates and then holding them to those estimates.
We’ve known that focusing on feature delivery severely undermines both the user experience and quality of the software being delivered; and yet the idea of ‘slack’ in capacity is seen as a cardinal sin. If reading this doesn’t make your skin crawl, you and I probably won’t agree on much. I wish you well.
And yet, in 2023, these very serious flaws in development are alive and well and present in just about every “agile” team out there, and even if they aren’t, it’s a fight against entropy and business trying to control the situation by bringing up these very flawed ideas.
We thought Scrum would save us, it did not. We thought Kanban would save us, it did not. The conventional wisdom now is that ShapeUp will save us. Spoiler alert: it will not.
The problem is none of these methodologies take into account the realities of how decisions get made. By the time you’ve gotten to improving software delivery, the decisions have been made and are (for all intents and purposes) cast in stone. These methodologies are pretty good when it comes to behaviors of the team making the software itself; but somehow ignores the entire business process before the act of creating and delivering software. They miss that there’s this pot of money that has to be allocated, and they treat that money allocation as a given, and as a limitless resource. These methodologies also miss that business priorities do not align neatly to features, they align neatly to problems, but at the moment the software team becomes involved, we’ve skipped past the problem and are solutioning.
It just so happen that that solution looks a lot like things the management team wanted anyway.
Another common problem is that teams don’t know how to talk about money with the business; or communicate the carrying cost and opportunity cost associated with certain courses of action. And when we do talk about these problems, we phrase them as ‘technical debt’, which not only obfuscates their impact, but uses a term from the financial world that misses the actual problems faced by teams when dealing with technical debt.
‘debt’ is a two-dimensional term, financially speaking. I’m either paying to alleviate that debt through reduction of the principal, or I’m paying just interest on the debt. But at no point do I find out that I can’t even start my car because I’ve taken out this debt to buy the car. Debt doesn’t affect the current operation of the thing I bought with it. It affects what I buy, but it doesn’t affect my ability to go about my day-to-day business of what I’ve already bought.
That’s not true for technical debt. How many times have you had to deal with the problems arising from technical debt keeping you from doing a simple bug fix? Or adding a new feature? Or not even being able to adopt a new style of working because of the ‘technical debt’ the team took on? Or existing features become impossible to maintain because of the debt you took on? Sometimes it feels like building software is negotiating with a sentient and malevolent being hell-bent on your mental destruction, manifested as no more than text files on the ethereal plane.
So when we try to talk technical foundations in business terms as software developers, we get it wrong. When we focus on optimizing software delivery and ignore the alignment of business, finances, and economic realities before us, we get it wrong.
The point is this:
Agile is not (and never was) sufficient to produce software that folks love to use and that meets the goals for which it was created. We spend more time creating churn and problems for ourselves, our businesses, and our customers through our over-reliance on agile than the benefits we get from optimizing software delivery with agile methodologies.
It’s time to look past agile. It’s time to focus on a holistic software creation process that aligns with budget realities and the realities of business. A software creation process that aligns what software creation is with what we need it to be: A way to improve people’s lives and enrich our culture. A source of joy, not frustration.
We’ve optimized software delivery. Now let’s focus on the realities surrounding software creation. Let’s optimize the next 20 years optimizing for the purpose of software: To make people’s lives better. We can’t do that until we fully align software development with the underlying business realities funding it.
Endnotes:
[0]: Scrum, Kanban, XP, Lean, LESS, SAFe. KPIs. OKRs. Knolway. You may ask why KPIs and OKRs are in this list. They have all the same characteristics as other ‘agile’ methodologies. The chief distinction between a waterfall/pre-planned approach to developing software is the ability to point to a goal outside of building the software itself, and iterate towards that goal, knowing the conditions that will consider that goal met (inspect and adapt). KPIs and OKRs provide an iterative framework to achieve a goal, and to inspect and adapt to reach that goal. At the most basic level, all agile methodologies seek to do that exact same thing, for that exact same reason. Just because some guys didn’t come up with it at a ski resort doesn’t make it any less agile.
[1]: So there’s data here; and I haven’t dug into it deeply (yet), but a cursory glance suggests that in 1995, 83.7% of software projects can be considered ‘failures’ in 1995 (“the project is completed on-time and on-budget, with all features and functions as initially specified.”), and the Project Management Institute survey suggests (edit: 8/20/2024, link updated) that around 69% are failures today (“Do not meet their goals”). Now, data-wise this is not a big jump, and not enough to tell businesses to, “adopt this approach because you’re 14% less likely to fail”.
This ungodly long opinion piece is not about whether agile was ever right, just that it’s past time to look at “What’s next”, and treat agile the same way Waterfall was treated 30 years ago; as standard, but insufficient in creating good software that people love to use and brings joy to their life.
[2]: Cory Doctorow is a luminary in tech. But, I see a particular blind-spot with his way of thinking, and that is it reduces our problems to a specific economic model, whereas if this problem were only about the economics of VCs and startups and “Get big fast and corner the market”, then it wouldn’t be endemic to all software. But as I write this, it’s hard to find software that hasn’t allowed this entropy to set in (even as I hesitate to call it ‘entropy’ because that pre-supposes that it’s inevitable, and I don’t think it is, as it’s entirely in our power to maintain quality and joy of use. Nothing is stopping us, except us).
[3]: The problem was never the mechanics of software delivery. When that’s the easy thing to blame (and the easiest to fix politically!) we focus on that. I haven’t gathered the data to back this up (this is a wake up call, not a research paper), but I’m willing to bet we’ve been looking in the wrong places for answers all these years. Optimizing software delivery has turned into the goal, the game, where the game all along should have been alignment of capital, direction, and purpose, and delighting the folks using our software.
[4]: Even more ‘fun’ (if you’re into that sort of thing) is that folks will tell you how the slightest deviation from those principles means you aren’t agile, and that somehow all these processes that derive from agile aren’t actually agile (Except theirs, of course). I will concede the folks that hate on SAFe have a bit of a point, however.
[5]: There’s that word. working. Not great. Not amazing. Not “Software you’ll be proud of”. Working software. That’s a low bar, but when you compare it to what came before — software that was produced for months and years but never saw the light of day because it was obsolete before being shipped — it was a godsend.
[6]: Feels weird to reword the tenets of agile for the purposes of this post, but I’m doing so because if I use the same words they use, it would defeat the purpose of trying to improve our understanding of the problems at play.
[7]: we have traded one level of software purgatory for another. Either we spend months building a thing that ultimately is obsolete when it’s shipped, or we spend weeks, ship it, realize it’s broken, fix it just enough to not be apparently broken, and move on once the opportunity cost is greater than the value to us to fix it. We’re still left with a process that disconnects us from the desires of the person using our software, and substituting our own process as a barometer instead of that desire. We’ve disconnected software creation from the mechanisms that determine how much runway we have, and wonder why the plane runs out of gas right after we take off.
[8]: Or find a different game to play. At some point you can’t trim around the edges any more and you have to fundamentally change the type of game you’re playing. If you just keep adding rules on top of rules to address the vagaries, you end up with American football, where you have to have 25-30 $100,000 cameras fixed at ungodly angles to determine whether someone caught a football.
[9]: I can’t tell if that’s a good thing or not that we’ve optimized how we build software for the realities of the industry around us, but I find it depressing that we’ve normalized building crap, but it’s comically rare that we build good software that brings joy to people’s life.
Author’s note: This post is the culmination of a writing process that took place over 5 months in 2023 and up until the time of publishing. I’ve spent so long writing and re-writing and editing it that it may come across as rushed. Ironically, it’s better to get the ideas out there and let them ruminate in the world than to keep working on this one post until it’s polished enough to be what I hoped for it to be when I started writing it. This is the beginning of the conversation, not the end. As an aside, once I upgraded to a 2023 MBP M2, the block editor started behaving again. That’s one way to socialize the losses from ineffective software development: Make your customer pay for better hardware to get a good experience.
