[jen729w]

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.

[jdlshore]

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

[dragonwriter]

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

[MattPalmer1086]

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]

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.

[rolisz]

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

[carlmr]

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

[jayd16]

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

[carlmr]

Alignment and information sharing should happen through collaboration, PR review, and PoCs. You don't need these "planning" meetings.

[ResearchCode]

But the agile salesmen can't do code reviews.

[dragonwriter]

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

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.

[choeger]

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

[dopylitty]

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.

[agumonkey]

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.

[jen729w]

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

[agumonkey]

What I got out of this is that my next job interview I will be harassing every person to know every detail about their workflow and views on how to organize.

ps: have you ever searched about high speed / high perf teams ?

[jen729w]

Funny, I was just cleaning up dinner thinking how if I was a program manager hiring a bunch of PMs my interview question — which I would advertise ahead of time to weed out the chaff — would be simple.

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

[agumonkey]

Interesting question. Migration are key problems.

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.

[rolisz]

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