Agile Is a Glass Cannon

https://www.tomdalling.com/blog/software-processes/agile-is-a-glass-cannon/

by boyakasha • 3 years ago

42 84 3 years ago

tomdalling.com

jpswade• 3 years ago

*shower thought

ljf5• 3 years ago

https://github.com/tomdalling/tomdalling.com/blob/main/input...

tempodox4• 3 years ago

Yep, poster should have used this link.

ljf5• 3 years ago

Good article.

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.

pflenker• 3 years ago

The comparison to home building is not a good one - houses are things which are repeated, with customizations and slight modifications, and people are deeply familiar with houses. The closest analogy in the software world would be simple websites such as blog or easy shops, where e.g. a WordPress plus some customizations would be enough.

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.

ljf5• 3 years ago

Exactly - as I say: If you know exactly what you want and are happy to wait, then an agile methodology probably isn't for you.

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'.

r_hoods_ghost• 3 years ago

I hear this a lot. The counter argument is virtually no one is going from implementing chat gpt as project 1 to implementing google maps as project 2. In fact they are going from implementing v1 of google Maps to v1.1.

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.

goodluckchuck• 3 years ago

I like to point out that very few house builders use agile methodologies to build a home.

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.

ljf5• 3 years ago

True - and yes you 'could' move in to a building that has just the structural components completed, but the value for the home owner is rarely released at that point.

nikau3• 3 years ago

heard it is faster and/or cheaper

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.

Ekaros• 3 years ago

You can build a house with agile methodology. And I think many have been...

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.

ljf5• 3 years ago

Yes you can do it, and it is exactly what my father did while living in a caravan on his land. Sorted a place to wash, then cook, then sleep for each of the children. I never said you can't do it, just it isn't how it is normally done.

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.

jen729w3• 3 years ago

Anyone else notice Agile creeping in where it has no place being?

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.

carlmr2• 3 years ago

I just started and already I’ve counted up 40 person-hours of time in ‘planning’ sessions.

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.

jayd163• 3 years ago

"Planning" meetings are also about alignment and information sharing. It's probably not about asserting dominance.

jdlshore• 3 years ago

Anyone else notice Agile creeping in where it has no place being?

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.

rolisz2• 3 years ago

Yes and no. Yes, the principles of Agile sound nice, but no, I've never seen them done properly. At every company where I've worked, when Agile got adopted, things went downhill

dragonwriter3• 3 years ago

Agile is clearly defined in the Agile Manifesto.

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.)

MattPalmer10863• 3 years ago

Oh, I completely agree that what is called Agile is about as far away from the original manifesto as can be.

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!

karmakaze• 3 years ago

It's well established that "Agile" with a capital-A has become a self-serving industry and cargo cult. The original manifesto has to be renamed to distinguish itself from that, which some call agile little-a, or agility, etc. Whenever there's a negative post on Agile, it's of the former identification and not the original motivations or methods.

dragonwriter3• 3 years ago

Anyone else notice Agile creeping in where it has no place being?

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.

blowski• 3 years ago

There are 2 methodologies with very similar names.

“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.

agumonkey3• 3 years ago

I'm not sure we feel the same but I kinda experienced high anger after seeing my team babble for hours on epics while no information of value was put out clearly and no actual design/planning was produced.

Just a bunch of paragraphs in jira. Smells like rot already.

jen729w3• 3 years ago

We feel the same. I’m ready to lose my mind.

choeger• 3 years ago

Agile as you observe it ist just double speak for micromanagement in my experience.

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).

rolisz2• 3 years ago

Yes and no. Yes, the principles of Agile sound nice, but no, I've never seen them done properly. At every company where I've worked, when Agile got adopted, things went downhill

dopylitty• 3 years ago

One thing about your comment that a lot of people are missing is that you mention that it's an infrastructure transformation project.

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.

mpweiher2• 3 years ago

success largely depends on the skill and experience of the individuals involved.

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.)

emilsedgh• 3 years ago

Young individual without enough skill/experience joins a team and fails miserably. Same individual joins another team and succeeds.

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.

mpweiher2• 3 years ago

If young individual later flourishes, same individual obviously has some skill (and/or talent).

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...

keyraycheck2• 3 years ago

I have a question to non-agile people? How do you work and get things done?

onethought2• 3 years ago

What do you mean by the question? Non-agile people? You mean people that don’t do scrum? Or do you want someone to step forward and say: “I’m really rigid and refuse to change direction once I start, this is how I get things done…”

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.

keyraycheck2• 3 years ago

I would love to know how people work. I wonder what is the alternative.

The board is far from only agile practice and nit obligatory either. Even Epic sounds like an agile term.

llanowarelves• 3 years ago

How management in corporations now use that word has almost nothing to do with what it is supposed to (OODA Loop).

ResearchCode3• 3 years ago

Probably similar to you but without "sprints" or "stand-ups" or reporting to "product owners", "agile coaches" or "business analysts". You would work on "epics", or projects as you would call them more dignifiedly.

jayd163• 3 years ago

Kinda misses the entire point of 'agile' which is a way to adjust to and gather changing requirements in an iterative process. It's a risk _mitigation_ strategy.

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?

nikau3• 3 years ago

gather changing requirements in an iterative process.

But you can't have processes, after all its "individuals and interactions over processes and tools".

bramblerose• 3 years ago

"That is, while there is value in the items on the right, we value the items on the left more."

Gupie• 3 years ago

No, it says you can have processes but that individuals and interactions are more important. It does not say that you can't have processes.

dragonwriter3• 3 years ago

“X over Y” does not mean “X instead of Y”, it means “Y serves X rather than vice versa”.

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.)

jayd163• 3 years ago

The process is iterated on by the people. The people tweak the process so it works for them instead of adhering to some dogma.

boyakasha• 3 years ago

It's a risk _mitigation_ strategy.

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.

eek2121• 3 years ago

FWIW, I've seen good Scrum and bad Scrum. The company I work at currently actually does an amazing job with Scrum. Cases like these help me have faith in Agile as a whole.

Previous companies? Oh boy...

perelin• 3 years ago

It's the McDonalds of processes

LMAO :) Im going to steal that!

drewcoo2• 3 years ago

Fair enough.

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.

MattPalmer10863• 3 years ago

Well, not sure process hell was eradicated, although it ironically moved to the very people who were supposed to be freed of it!

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.

drewcoo2• 3 years ago

Well, not sure process hell was eradicated

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.

mongol2• 3 years ago

I think it is crazy we are debating Agile more than 20 years after it was coined. After such long time, a successful idea should not need constant debate about its advantages and disadvantages. We should be on the next thing now, post-Agile, whatever that would be.

saiya-jin• 3 years ago

Because its not very intuitive until you start doing it (at least some parts). I mean having meeting for 10 mins every day vs 1x weekly hourly one works for every project I've ever seen. Shorter sprints work generally better too, tighter interaction with stakeholders is simply reasonable.

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.

ResearchCode3• 3 years ago

Those 10 minute meetings are 5 hours of lost time for deep work each week. Daily status reports are excessive. "Sprints" in general don't work in my experience, they are unnecessary overhead. You want to work in something more towards half-year projects, not two week "sprints".

therealdrag02• 3 years ago

Note that’s a specific flavor of Agile related to Scrum, not the only flavor.

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!

tempodox4• 3 years ago

IMO one thing that makes it still interesting to discuss is that it has become something of a poster child of cargo cult. That phenomenon persists, whether it's Agile or something else.

redpenguin101• 3 years ago

I think you have that exactly backwards. ONLY successful ideas are being debated more than 20 years after they are proposed. Only successful ideas spawn reaction and counter-reaction, which lead to its evolution - which you say is not happening, but certainly is, as evidenced by the tree of methodologies that branched from it.

In that respect (which might not be the one the coiners hoped for), capital A agile has been extremely successful.

mongol2• 3 years ago

If it was successful, it would be so normal that there would be no argument about it. It would be taken for granted as the platform which other improvements are built on. It would be like water to fish. That is not what I see.

tempodox4• 3 years ago

That article makes a lot of sense. I've seen several mediocre shops that treated their version of Agile like it was a magic wand that makes everything better, when all they wanted was more control and another fashionable buzzword. Even if they knew how to hire folks who could do real agile development, they wouldn't want to because it would mean relinquishing some of that control.

nathants• 3 years ago

agile is one of those things where if you have to say it, your probably not.

readthenotes1• 3 years ago

With the right clay, you can make anything.

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.

S4mb• 3 years ago

I just wanna toot a horn for good old prince2 here. I know it's not the cool new thing on the bloc but I would prefer it for stuff like infrastructure or organizational change projects any day.

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.

tempodox4• 3 years ago

That looks very process-heavy with a lot of specialized vocabulary.

GoToRO• 3 years ago

"On the previous team, when you picked up a card it had everything you needed to do a good job. On this team, the cards are a mess."

So managers just push to implement cards that are not ready, because they are too lazy to do their job. What else is new?

fwlr2• 3 years ago

“It works when engineers and management are both highly skilled” is hardly a glowing recommendation for a management process. Only a management system so bad that it is tantamount to sabotage would not work when everyone involved is highly skilled. The most productive management system I ever operated under was “the founder DMs ‘how’s it going’ whenever he remembers to” and that worked great because we were all skilled too.

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

Particular management styles don’t really matter in the top left or bottom right square. The most salient criticism of Agile from this perspective is that in the top right square it multiplies bad management’s capacity to make good engineering sad.

donio• 3 years ago

How would you end up with good mgmt and bad eng? I suppose it could happen as a temporary situation when new mgmt takes over a failing organization.

pg_1234• 3 years ago

... with a small budget.

fwlr2• 3 years ago

If engineers are making the hiring decisions, as was the trend for a while, and they make bad hiring decisions. Or if the hiring department is bad. Or if managers are good at managing but bad at hiring. Lots of ways, hiring is hard.

Agile Is a Glass Cannon

Related Stories