Agile Is a Glass Cannon
tomdalling.com
tomdalling.com
I’m suffering on an infrastructure transformation project — migrating complex apps to Azure — which insists on being Agile. It’s preposterous. I just started and already I’ve counted up 40 person-hours of time in ‘planning’ sessions.
I spent two hours in a room with an architect and a whiteboard and then one single day myself on Thursday building a schedule gasp for one of these apps that already contains 100x more information than the entirety of their Azure DevOps boards.
They’re shoe-horning infrastructure transformation in to ‘epics’ and ‘features’ and ‘sprints’ and who knows what the fuck they’re doing and next week I think I’m going to actually lose my shit and tell them they’re maniacs.
But hey. Who can be bothered actually planning a thing. Sounds hard! Let’s just make shit up every two weeks.
Agile done wrong is just people sliding Post-It® notes across the table at each other hoping that the thing will get done.
I mean this is what always bothered me about every implementation of "agile" I've seen. Agility has a definition, planning everything in minute detail is not in any way reconcilable with that definition. Scrum is the worst at this.
If you want to convince me of agile it has to be harmonious with the word definition. E.g. creating PoCs, playing around with actual code, iterating with the customer. As soon as you try planning everything you're not agile. You have a problem with being controlling. Point.
Eh, not really. Agile is barely practiced by any companies.
What most practice is a gawdawful abomination of micromanagement and iterative waterfall that they have the audacity to call it “Agile.”
Agile is clearly defined in the Agile Manifesto. (Don’t forget the principles on a second page.) All you have to do is treat it like a checklist and you’ll see it’s barely practiced anywhere. (“Individuals and Interactions over Processes and Tools? No. Customer Collaboration over Contract Negotiation? No.” Etc.)
Maybe I’m getting jaded.
Vague principles for Agile are laid out in the Manifesto, and slightly less vague in the Principles. But honestly, clear definition isn’t really something that the Agile prime movers did (the best ideas for operationalizing Agile principles, IMO, were in the Lean Software movement, but unfortunately “Agile” instead ended up getting associated – and I think the lack of operationalization of the principles in the core documents contributed to this – with rote application of one of a handful of methodologies some of the founders were associated with, which eventually settled mostly on Scrum, and then on not even Scrum-by-the-Scrum-Guide but a weird set of particular tools and things that had accreted around Scrum, each of which is useful in the right context, but they’ve become this giant consultant-reinforced cargo-cult mass of rituals divorced from their purpose in exactly the way of the ossified practices that the Agile movement was a reaction against.)
It could only really work in exploratory, high trust, high performing environments in my opinion. I've seen that rarely.
Contracts are pretty much in direct opposition to agile practices. Most organisations won't sign an open ended committment to get something without that being defined up front.
What companies call agile seems to be a synonym for faster releases, and faster time to market for the business. It is more agile from their perspective, just not for the practitioners!
I rarely even see Agile creeping in where it does belong and is being advertised as being practiced.
> I’m suffering on an infrastructure transformation project — migrating complex apps to Azure — which insists on being Agile. It’s preposterous. I just started and already I’ve counted up 40 person-hours of time in ‘planning’ sessions.
If you’ve just started and you’ve counted up 40-hours of person-time in planning sessions on one team and not also 600+ person-hours of substantive working time, whatever it is, its not “Agile”.
> They’re shoe-horning infrastructure transformation in to ‘epics’ and ‘features’ and ‘sprints’ and who knows what the fuck they’re doing and next week I think I’m going to actually lose my shit and tell them they’re maniacs.
“Epics”, “Features”, and “Sprints” do not appear in the Agile Manifesto or Principles; a team which is Agile might use them, but using them isn’t a sign of being Agile.
“Agile” is recommended by big consultancies. It aims to improve managers’ control of processes and costs by removing autonomy from those doing the implementation. It does this using templates, hierarchies and policies.
“agile” (small a) as practised by Kent Beck. It aims to improve outcomes by handing more control to the implementers through collaboration. It does this through good communication and focus.
The insight of this submission is that when those implementers are capable and motivated to deliver a good outcome, this will deliver the best possible outcome. But if they’re not, then nobody is in control, and you just have chaos.
Big A Agile still has crappy outcomes but the lines of accountability are at least clearer.
Just a bunch of paragraphs in jira. Smells like rot already.
ps: have you ever searched about high speed / high perf teams ?
“Here’s an engineer/architect, a scope statement, and a whiteboard. Show me how you’d create your initial high-level migration plan.”
For organisation, Johnny.Decimal. :-)
btw, our messages crossed, so asking here:
have you ever searched about high speed / high perf teams ?
How to metaprogram your team workflow to optimize processes on multiple layers so everything is soft and fluid.
What we experience is a caste of highly paid managers that a) don't understand the work their subordinates are doing, b) don't trust them and thus c) cannot understand the risks of a project for their personal careers.
Their, quite ingenious, response is "agile": Micromanage everything to mitigate b), but wrap that micromanagement in a "industry standard" process that hides everything behind double speak (scrum). In particular put an emphasis on the point that "the team decides" and "there are no deadlines in agile", while essentially driving all decisions informally (e.g., by prioritizing the backlog) and enforcing deadlines whenever you see fit. Thus, there's no overt responsibility left for a manager, effectively eliminating c).
I think that's important because agile as I've seen it doesn't work well for infrastructure (networking especially). The core ideas of agile just don't fit.
For one there really isn't a customer who can test an infrastructure project in small increments. Imagine trying to deploy a network in small chunks. Who is the customer who would be 'testing' the chunks? How would that even work?
For two infrastructure really does have to be designed end to end because the cost of rework is so high. Especially once actual applications are running on it. Sure you can make tweaks here and there as the project evolves but you can't release it to business applications until you're pretty sure it's going to be stable.
I'm sure there's some methodology that would work better than waterfall for infrastructure projects but I haven't seen an agile methodology that would fit it.
I'm not sure I agree that anything is a glass cannon because it could work but you could also do it wrong so it could fail. If a team can't pull off agile what do they think would have been a safer strategy?
But you can't have processes, after all its "individuals and interactions over processes and tools".
That doesn’t mean no processes and tools, you need to have those. It means the processes and tools aren’t canned processes and tools imposed on the team, it means they serve the team and the way they work, are owned by the team, and that the team is free to adjust them according to its developing understanding of its needs. (And, ideally, that the team is frequently checking in and evaluating whether and how it should be changing them.)
It's designed to mitigate _delivery_ risk, not _organisational_ risk.
> If a team can't pull off agile what do they think would have been a safer strategy?
I would probably argue that Scrum (which I barely consider to be "agile") is more resilient to inexperience, and therefore lower risk. It's the McDonalds of processes. You're not going to get amazing results, but it will still operate despite hiring a bunch of inexperienced people into it.
Previous companies? Oh boy...
LMAO :) Im going to steal that!
I think the issue is the often 'higher ups' want 'Agile' as they've heard it is faster and/or cheaper - missing the part that it is faster and cheaper to fail with agile. If you know exactly what you want and are happy to wait, then an agile methodology probably isn't for you.
If you need to test something out or scratch an itch now, then agile might be a good fit (depending on the skills/buy in/experiences/interest of the team(s)). Forcing people to be Agile! does not work.
-
I like to point out that very few house builders use agile methodologies to build a home.
But, if there was a storm tonight and you lost your home, then you might use an agile approach of borrowing a tent, then buying a trailer, then getting a static caravan, while you start building a basic toilet block, then adding on a kitchen and building a home iteratively, adding and releasing value early, that way.
The result would cost more than just building a house, but you'd have value sooner in terms of a place to sleep, wash and eat.
Software is completely different though. Building chatgpt is vastly different from building Google Maps, for instance. And on top of that, most interesting software projects are not mere copies of other projects, so the whole idea of the customer knowing what they want does not apply.
I think you missed my point, (sorry if it wasn't clear). An agile way of working can be right if you want to test and learn and you need to unlock value quickly (or more quickly than building a whole).
But the industry I work in, even 'agile' projects come with 6 month planning 'sprint zero', and then basically just use sprints to work through a waterfall plan. Getting no value from 'agile'.
When I worked as a kitchen fitter there was a much greater difference between projects that anything I've experienced with a single employer as a dev. Fitting a top end kitchen in a listed 500 year old cottage is vastly different to fitting a budget kitchen in a new build, to fitting a period appropriate kitchen in a 1930s town house. Building out the next version of an API or writing a rendered, not so much.
I think a lot of Devs have a vastly inflated sense of the "uniqueness" of what they are implementing, and I think a lot of that derives from the industries obsession with reinventing the wheel, NIH syndrome and fashion driven development.
Home construction often has milestones that are fairly comparable: 1) competition of the structural components, 2) drying in, 3) utilities, 3) drywall and Paint, and 4) Finishing.
Each of these are phases where they could theoretically stop. There are times in history and places in the present where people live in structures that don’t have windows and doors, or without utilities, etc.
However I would agree that they’re not marketed as viable until they’re close to finished.
This has been my experience with agile - it works OK if you have more expensive experienced staff who can make smart decisions and work autonomously.
The problem is the company wants to hire/outsource the cheapest staff possible who do better with defined processes and standards.
You might be able to live in one, but surely you don't want to buy one. As these are probably not legal in this day and age and mostly done by do-it-yourself self-builders. That is they are not code compliant. Like electricity might or might not burn down the house, there might or might not be leaks all over the place. And mold and so on is probably common... Also I doubt every door closes or is straight and so on...
Actually that really describes most of software we use.
But it is not what is normally done, as it comes with its own costs. The benefits to him were clear, but most people just want to move in once it is built and not have the extra expense of iterative 'releases' of their house.
That's mostly what I've seen adopted, not much more. Its a bit painful if you ever need to go back, but entirely possible. Some people actually perform quite well with old ways.
Personally I do 2 stand-ups a week, and a monthly sprint board (Kanban like?) with no sprint planning or any other process/system meetings. Any other meeting is as-hoc on demand. Working well!
In that respect (which might not be the one the coiners hoped for), capital A agile has been extremely successful.
One can imagine a 2x2 grid like so:
good mgmt bad mgmt
good anything eng is
eng works sad
bad mgmt is nothing
eng sad works
Agile was a response to heavy process. And systems where people's jobs were all about adding more process to the already heavy process. Process hell.
In the couple of decades since little "a" agile really got adoption:
1. many people have not seen v-model or spiral model and their attendant process wonks
2. agile was turned into Agile and became a way to micromanage, first micromanagement with no rules, then later, more and more "Agile rules"
So now we have SAFe, which is sort of the worst of both worlds: micromanagement plus a smothering blanket of process.
But back to the point . . . the intention was never to create the ultimate system that was totally amazing but only when staffed with complete experts who were also psychically connected. The intention was to ditch process hell.
What has changed is that the business expects to be able to push new features through quickly with faster releases. In the past, it took a long time for the business to get changes made.
Part of that I think was that highly technical departments had more control over their output and schedule. It was all mysterious to everyone else. If the business wanted to do something, there would be meetings and documents and analysis and approval decisions. It was hard, it was complex.
As technology has become commoditised and less mysterious I think the power of the techical wizards has waned. So the business likes the idea they can just ask for stuff and it gets released fairly quickly and with much less ceremony and negotiation from their perspective.
My point is that process hell was not eradicated. And in most instances, we ended up with process hell plus micromanagement.
> the business expects to be able to push new features through quickly with faster releases
Oh, I f'in' wish . . . Not enough companies want rapid release, a.k.a. low-risk, customer-centric culture. If more did, I'd have more work because I can do that really well, but managers assume provably true things are magic, because . . . professional managers.
> As technology has become commoditised [sic] and less mysterious
That is a whole ton of crap, son. Tech is not lumber or oranges or coal. It's not a g'damned commodity because we are not commodities. Much as far-distant managers of funds would like to think otherwise. (Or think what they do is different from what we do, in fact.)
Nor is it mysterious. It's more logical than most professions, even the (other?) degreed ones! Ask me to write code to do FOO while robbing BAR to pay BAZ and I can do that and prove to you that it works. This ain't physics or psychology or philosophy . . . I can make it work and prove it works. No hand-waving. No nonsense. Works. Period.
It has gradually become less of a bastion of technical wizards and more of a commodity service to the business and society at large, like getting electricity and water.
Yes. Well sort of. The key insight here is that in software at least, this is a pre-requisite anyhow. If you don't have skilled and/or experienced people, nothing will save you.
So you might as well tailor your process around the expectation of a certain amount of skill, because although you can't use process to save you, you can use process to f-ck up a team that would otherwise perform well.
However, my practical experience with agile includes taking a team of so-called low-performers and turning the team into one of the highest performing teams within the organisation. Using agile. (No fauxgile, no scrum, no standups, etc.)
Skills and/or experience are _not_ prerequisite for every single individual. You need enough skillful/experienced people to create a process/culture that allows less experienced engineers to join and flourish.
> for every single individual.
I didn't write "every single individual", and for good reason. Note the story in the second part of my comment...
If you want to get an impression check out this doc about a prince2 project initiation document: https://prince2.wiki/management-products/project-initiation-...
In case it comes accross a little bit to advertisy: I am not affiliated with the prince2 publisher. Just someone who suffered through a lot of unnecessary agile, has been working in a prince2 org for two years now and really likes it.
So managers just push to implement cards that are not ready, because they are too lazy to do their job. What else is new?
Process is a second order effect. Team (not individual unless you work by yourself) competency rules.
Boehm noted that in Software Engineering Economics many decades ago.
If you mean no scrum, simple, no card wall, tasks are epics, trust people to know what to do and let them do it. Help people when needed.
The board is far from only agile practice and nit obligatory either. Even Epic sounds like an agile term.
Even modified waterfall seems to be described as agile.
As a sole developer of a software product, I haven't figured out how the agile principles even apply to me.
"Individuals and interactions over processes and tools" doesn't work when there's only one person.
"Working software over comprehensive documentation" Does that mean ship code but don't provide comprehensive documentation to my users? No, it means internal process documentation. Which isn't applicable since it's just me.
"Customer collaboration over contract negotiation". That only applies for contract software development. I sell a software product.
"Responding to change over following a plan". I don't have much of a plan, so I guess I do this one. But I do have a long-term vision, since that's essential to figuring out what groundwork to have.
Personally, I learned RAD (rapid application development) when I was a young programmer back in the 1990s, and that's what I still use.
The software vendor sells a software product, not the developer.
Assuming your definition makes sense, what are the "interactions ... processes and tools" between me-the-vendor and me-the-developer?
What is the comprehensive documentation that I'm supposed to avoid?
What is the contract negotiation?
Since it's clear to you, perhaps you can clarify how the Agile Manifesto applies to software product sales when there's a single developer and once-per-year product cycles?
But if "a process" is all that's needed to be Agile then waterfall is Agile.
Why not once a year? Does Agile require a higher delivery frequency than that?
That is, how is your question relevant to the topic?
Yeah, that's what Agile seems to mean to most people. Courtiers to the Emperor, praising the new clothes none can see.
Scrum reminds me of the old adage about measuring a beach, you can measure it by sight, or by using a yardstick, or by counting grains of sand in a row. Scrum sits too close to counting sand, I prefer to be at the yardstick level.
There is an idiocy to scrum that involves/wastes the whole team on simple planning tasks that could be more effectively done by a single person. This is compounded with practices like mobbing… It removes craft from software and just makes it lowest common denominator.
Agile manifesto is still great and relevant. But that’s not what people mean when they say Agile