Agile Was Never Your Problem
43 points by facundoolano
43 points by facundoolano
Part 2: Agile That Doesn’t Suck
The only definition of “Agile” is the manifesto, and the manifesto has a clear purpose: it’s a lot of vague but exciting words that a bunch of professional consultants wrote to shift blame. Why is the project over budget and behind schedule? Because people keep asking for changes to what the project does or how.
And that ultimately points to the key insight that hardly anybody in the Agileverse ever admits: if you have an organization where the people with the authority to demand changes also accept responsibility for the impact on the project, things will be good. If not, things will be bad and there is no other change you can make which will cause things to be good.
Everything else that has come to be thought of as “Agile”… isn’t. For example, a lot of people seem to think “Agile” means using short iterative feedback-driven cycles to grow a software project rather than plan the whole thing up-front. But Fred Brooks was pushing that fifteen years before the Agile manifesto was published!
if you have an organization where the people with the authority to demand changes also accept responsibility for the impact on the project, things will be good
show me the world where this sort of culture of accountability (or even awareness) from management exists, and yeah, we wouldn’t have needed the agile manifesto.
But Fred Brooks was pushing that fifteen years before the Agile manifesto was published!
Ok, and? Signers on the manifesto knew of Brooks, referenced him often, and would credit him and many others who came before. XP, crystal, lean and other methodologies predate the manifesto. “Talking to the customer” or “prototyping” obviously goes back to the days of punch cards.
I’m well aware the term “Agile” (big A) has been co-opted and tarnished via certifications and corporations and nonsense, but the core ideas behind “agile” are still as relevant, valuable, and overlooked by teams and software companies today.
the core ideas behind “agile” are still as relevant, valuable, and overlooked by teams and software companies today.
The “core ideas” of “agile” are just vague platitudes wrapped up in early-2000s motivational-speaker language. One might as well have those insipid inspirational posters hanging on the wall of the office.
One might as well have those insipid inspirational posters hanging on the wall of the office.
Tempting to link to despair.com…
show me the world where this sort of culture of accountability (or even awareness) from management exists, and yeah, we wouldn’t have needed the agile manifesto.
It’s a big world out there. But if you’re in a company where your colleagues refer to any non-programmers as “the business” then run.
people with the authority to demand changes also accept responsibility for the impact on the project
Perhaps they were pointing out how much easier it is to get them to accept responsibility if you arrange the work such that:
Perhaps they were pointing out how much easier it is to get them to accept responsibility if you arrange the work such that
If you have the authority/responsibility thing sorted out, there are a ton of ways you can plan, assign, and carry out the work and it’ll be fine.
If you don’t have the authority/responsibility thing sorted out, it doesn’t matter how many Extreme Pair Story Poker Scrum Sprint Retro User Standup Points methods you use.
The comment you are replying to is specifically pointing out that there are ways to estimate whether or not you have the authority/responsibility thing sorted out.
If you don’t see the value in being able to quickly estimate whether that works, you live in a very different world from me.
For instance, if I’m considering working at an org that’s using Extreme Pair Story Poker Scrum Sprint Retro User Standup Points, but when I talk to the team, none of them can describe conversations with decision-makers… I know the authority/responsibility thing isn’t sorted out (how could they take responsibility for the impact of their decisions if they aren’t hearing from people who know what it is?).
If the org-chart has a bug, either live with it, leave, or get to work fixing it like you would any other complex system.
but when I talk to the team, none of them can describe conversations with decision-makers
My definition of “agile” does not require that everyone be in every meeting. Yours apparently does. But to be clear: it is entirely possible to build an organization where trust and a solid track record mean I can believe that someone who made a decision has been made aware of and accepted responsibility for the impact on budget/timeline/etc. without needing to have been physically present to witness that.
My definition of “agile” does not require that everyone be in every meeting
No, my definition requires that everyone contributing to the implementation have (at least occasionally) 1:1 contact with someone who understands how the software is used, and everyone with decision-making power have (at least occasionally) 1:1 contact with someone who can tell them how their behavior is affecting the project.
Neither of those functions requires a meeting to occur.
You’re still demanding that everyone be present for every decision made by the stakeholder. Otherwise they can’t describe the “conversation” to you.
I don’t think a certain amount of delegation is incompatible with my concept of what “agile” would be (balancing authority/responsibility).
You’re still demanding that everyone be present for every decision made by the stakeholder. Otherwise they can’t describe the “conversation” to you.
I’m unclear how “at least occasionally have a 1:1 conversation” has turned into “everyone is present for every decision” in your mind?
This is the third post in a row in which you’ve simply made up something I wrote and then argued against it. If this is indicative of your typical behavior, I am stunned that you’ve managed to remain employed, yet your website describes someone with serious long-term experience.
My willingness to assume good faith from you is exhausted; for the sake of the mods workload, I ask you to not interact with me in future, and I will endeavor to do the same.
I said, several comments ago:
If you have the authority/responsibility thing sorted out, there are a ton of ways you can plan, assign, and carry out the work and it’ll be fine.
Given how persistent you were in arguing with me, it seems reasonable to assume you disagreed with that. Otherwise I’m not sure why you posted a whole series of condescending comments focusing on whether people can recall having been part of conversations. It seems reasonable to assume, from this, that having the people take part in the conversations was something important to you. Now you’re backtracking and insisting that delegation of communication was always OK by you, and for some reason you’re also turning to personal attacks.
I think you should take your own advice and stop this.
I think there’s been a retcon there. The Agile Manifesto is from 2001, but I suspect “Continuous Delivery” was not coined much earlier than the 2010 book. So http://agilemanifesto.org/principles.html is likely a late addition, but like three out of the twelve principles are about Continuous Delivery (and I believe it’s the meat of the principles).
Coincidentally, I started working in 2001. My perception is that at that time, most projects had a long ramp-up time before a first working version, which was closer to years than to weeks. I soon learned that long periods without delivery were death, but I didn’t hear of Agile and stuff until 2006 or so. I remember I was glad that someone was putting names to the concepts I had in my head.
Maybe the Agile crowd coopted Continous Delivery, but I prefer to have a somewhat more charitable view that they also had Continuous Delivery in their heads, but they weren’t able to express that clearly. The Agile Manifesto was not a really focused thing, but they already had “working software” there… I kinda imagine it took time for that idea to gain weight.
In the end, I think the story behind this is interesting. I have plenty of criticism about the whole Agile movement, but I’m really glad Continuous Delivery is nowadays “a thing”.
I think there’s been a retcon there. The Agile Manifesto is from 2001, but I suspect “Continuous Delivery” was not coined much earlier than the 2010 book. So http://agilemanifesto.org/principles.html is likely a late addition, but like three out of the twelve principles are about Continuous Delivery (and I believe it’s the meat of the principles).
The Internet Archive suggests the principles were identical in 2002 to what they are today:
https://web.archive.org/web/20020403001256/http://agilemanifesto.org/principles.html
Oh, nice catch. So continuous delivery was a thing in 2002?
Well, to me that strengthens the bit about Continuous Delivery being one of the most important parts of Agile! It’s not just me wanting continuous delivery to be Agile.
note the lowercase “continuous delivery” - so it meant more the practice and culture of shipping software regularly to customers, which could be after every 1 or 2 week iteration (if you were doing well) or every month or two (much more common back then).
There were teams doing something like today’s “Continuous Delivery”, a la CI/CD: automated deployment, monitoring, and feedback on every merge to master/trunk. It was just difficult w/ the state of tooling and automation. This would be 5 years before git, ~8 years before github, no hosted CI, AWS just started in 2002, etc etc.
Plus most teams and businesses were just not ready to move that fast organizationally. It was really a different world.
My memory is a bit hazy, but at least 2001-2005 I was doing web development and much of our work was deployed quickly, I’d say monthly or faster. But precisely in that job we had a couple of projects or even big projects where ramp up was months… and they were mostly a failure.
Then I moved to a place that never acquired any significant customer, so 2006-2008 was “no delivery” for me. But then afterwards, I learned my lesson and faster delivery was common place, although it wasn’t until 2012 when I landed in a place that did Git and where the delivery pipeline wouldn’t look out of place today.
I think this separates us in two groups: those of us who have experienced insufficient delivery speed (closer to year than to weeks) and those who haven’t.
For those of us who have experienced this, Agile is meaningful- but for the others, I don’t think Agile can mean anything, because they haven’t lived through it.
And I guess some people were doing Agile before 2001, or even that some people have not done Agile in 2025… I’d like to be able to know when was the tipping point where “normal” meant sufficiently-fast delivery cycles. For me, it was somewhere between 2008 and 2012.
So my reply to:
Everything else that has come to be thought of as “Agile”… isn’t. For example, a lot of people seem to think “Agile” means using short iterative feedback-driven cycles to grow a software project rather than plan the whole thing up-front. But Fred Brooks was pushing that fifteen years before the Agile manifesto was published!
I think this short iterative feedback became mainstream at a close point to when the Agile Manifesto became mainstream. And while the Manifesto itself didn’t really hinge much on short iterative feedback-driven circles, others have shown that the Agile Manifesto included that in its principles as early as 2002.
I don’t doubt that many were doing that prior to 2001… but I certainly think it became the new normal later than 2001.
and actually make Agile feel like… well, Agile.
I wonder why it’s so important to keep calling it Agile. Or anything, really. Can’t we just call it ‘working together’? And continue to exchange examples of what worked for us in the past?
It all feels a bit like the Gang of 4 Design Patterns to me. We seem to desperately want to prescribe how we should do things, whereas we’re in a creative industry, so every situation is different.
Skills, in programming as well as in organizing teams, come with experience and from learning from others, not from blindly following a set of rules.
The design patterns analogy is a good insight I don’t think I’ve seen before.
I read the GoF book back when it was new, and I came away with the impression that the authors were proposing a kind of taxonomy of existing practices. The key goal, I thought, was to aid communication: now I could just say “visitor pattern” instead of describing it from first principles every time I wanted to talk about how my code worked. Did I learn some new techniques from the book? Yes, absolutely, but the big win of design patterns was a common vocabulary for talking about things my colleagues and I were already building.
But the industry, and especially the education system, came away with a very different interpretation than I did: design patterns as a prescriptive, predetermined list of components to memorize and use slavishly whether or not they were the best solution for a given problem. The things we used to build from first principles became the first principles.
And I think that’s an analogy, though an imperfect one, for agile: an enumeration of processes that have worked well for certain teams in certain scenarios after a period of evolution and iteration has turned into a set of rules to be followed to the letter without thinking.
Shame the couldn’t use the name “A Pattern Language”, like the architecture book they based it on.
The first fix is brutally simple—stop doing Agile theater.
I tried at my previous job. I was talking with a VP about this. Then the VP got sacked and replaced with a new VP who said “how unfortunate”. We were forced to do Enterprise Agile from on high. Not doing Agile was not an option. And upper management didn’t want to hear otherwise.
At some point you have to wonder… how come programmers don’t have unions?
My guess is that it is because, for most of the last 30 years or more, programmers have found it easy to change employment. If management imposes some unpleasant practice, just quit and work somewhere else.
Why bother with collective bargaining in a prolonged effort to improve practices when you can just let them suffer the consequences of their bad management while you go and work somewhere better?
Perhaps, if the job market truly collapses, programmers will have more of an incentive to form unions.
Unions have some upsides, but I don’t think decreased process and increased flexibility is usually what they’re known for.
Like every human organization, a union will be what you make it. It’s quite possible to set up a local union at a company and do collective bargaining with the employer, without having it turn into whatever it is employers usually paint them as. It is my belief that programmers’ wariness of unions is a successful PR campaign by the company side.
It is my belief that programmers’ wariness of unions is a successful PR campaign by the company side.
I wonder if it can also be attributed to the non-transparent nature of salary negotiations. Some may believe they could have gotten more (in which case collective bargaining helps) whereas others may feel they did better (in which case collective bargaining may hurt as others find out what they make).
I think they do what you make them do. If they can negotiate for safer workplace practice, they surely can negotiate aspects of development process. I mean, it’s not like you hire external union organizers and negotiators from a different industry who that do some preordained union stuff. It’s just you and your colleagues agreeing on your collective needs and then refusing to work unless your needs are met.