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.
> 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.)
> 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.)
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!
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.
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
>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.
> 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.
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.
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).
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.
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.
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 ?
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.”
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
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?
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.
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.
“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.)
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.
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.
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.
Having fitted two kitchens, buildings are crooked... You need shimming and planning far ahead, and lots of measuring if you want to get something that is mostly straight.
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'.
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.
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.
> 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.
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.
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.
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.
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.
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.
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".
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!
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.
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.
“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.
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 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.
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.
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 certainly was more mysterious to most back then. My first experience of computing was in an air conditioned room, there were spinning tapes and flashing lights and staff wore white coats. That was in the late 1970s.
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.
> 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.)
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.
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.
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.
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.
The problem I have with your question is "agile" seems to mean anything except a pure waterfall development model.
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.
I've spent over 20 years thinking about it, and not been able to figure it out.
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?
I was using the term to find common ground. I don’t call them epics, just they are a big thing.
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
My team of 7 (inc manager and pm) does 2 stand-ups a week (doing it in slack is okay if needed), and never sprint planning or any other recurring meetings. Any other planning or meetings is done as hoc as needed. We usually have ~3 projects going on in parallel so not many cooks in kitchen and not a lot of syncing required. We use jira for tickets and have a “sprint board”, but it’s super casual just a place to track stuff and I roll the sprint once a month without any meeting or ceremony.
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.
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.