[endymi0n]

I've come to dread any formalization of Agile. Agile development is fine. I've built a 40+ engineering team with it. I can vouch for its effectiveness when applied to small, excellent teams.

For reference, here's all the Agile you need, it's 4 sentences:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

The real problem is that capital-A Agile is not agile at all, but exactly the opposite: A fat process that enforces following a plan (regular, rigid meeting structure), creating comprehensive documentation (user stories, specs, mocks, task board) and contract negotiation (estimation meetings, planning poker). It's a bastardization of the original idea, born by process first people who tried to copy the methods of successful teams without understanding them.

[9dev]

> […] when applied to small, excellent teams.

Isn't that the biggest issue here, though? I think all of us can agree on the four sentences you wrote, but this only works in a team of professionals with shared goals (and alignment on them!), each individually competent and motivated.

That is the case for a small founder team and maybe a while after that if you're lucky, but IME the more people join a company, the more the alignment and median expertise lessen. At some point, you need to introduce control mechanisms and additional communication tools to rake in the outliers.

I don't really have a better answer, though…

[Balinares]

I've had good success in both high-skill teams (in one case, almost half the team's engineers ended up at Google at some point or other) and... teams that were still in the process of skilling up. I've found people generally want to do good things and have some room to grow even if they're not yet at your desired level; and when you have demotivated people around, the causes tend to be systemic. Which, thankfully, implies possibly fixable.

[lamasery]

Yeah, managers adopt agile to try to un-fuck their organization but it doesn't actually do that. You need an un-fucked organization first.

It's not a system of management and it won't work if the way you're managing sucks. Nothing targeted at a similar "level" as the various "agile" systems will either, though.

[Cthulhu_]

That's it, "excellent teams" are a needle in a haystack; the mythical 10x developer, if you will.

But at one point you need not one team, but a hundred.

[mpweiher]

> this only works in a team of professionals with shared goals (and alignment on them!), each individually competent and motivated.

Counterpoint: I learned a variant of agile in exactly this type of environment, long before any of this was publicized. Which is another point: agile wasn't something new, certainly not at the time of the manifesto, which was a compromise document. But not even before the manifesto. XP, arguably the first agile methodology, very clearly and deliberately stated that this is nothing new, just a distillation of things that experience has shown to work well.

Anyway, at my next job I introduced agile (small-a-agile) to a team that was anything but skilled. In fact, that team was where the leftovers of that particular development organization had been shunted (public company, very difficult to get rid of people). When I arrived, the team was as non-functional as the software it was responsible for. Well...

We rocked.

And all the team member improved dramatically in skill during my tenure there. Including myself.

We did not do Agile. No scrum, no standups, no sprints, none of that BS. We were agile. We focused on the technical practices. Test first. Red-green-commit. To trunk, obviously. Because if it's green why on earth would you not? Do the simplest thing that could possibly work. We had a design for a database and then never found a need to put it in...so we didn't.

It took a while for the other parts of the org to adapt to this. The answer to the common question "well, when can you deploy?" was always "now". Well after a quick look that the tests were, in fact, green. So they stopped asking. The tests were rarely not green, and when it did happened there was usually a quick "Oops, I'm sorry" and they went green again a couple of minutes later. Our ops team got bored very quickly. Put jar on box. Start. Forget about it.

What made the experience scientifically interesting is that we had a control group: the main team, much larger, working on the "important" software with all the "good" engineers started with a new project about the same time we did.

They did Agile. Capital-A. Scrum, sprints, standups.

They did not deliver and in fact the project had to be completely reset about two years in. My team-lead (we were co-lead, I did mostly internal/technical, he external/managerial) then got to take over that team as I left for Apple.

TFA, incidentally, is just about as good summary of misunderstandings of agile as I've seen.

[psini]

Not much to add just wanted to say I share the sentiment and it matches my experience :-) . I'm not smart enough to NOT keep it simple; 90% of stuff I work on at $company is really a CRUDbox and I do NOT want to "astronaut-architect" the whole thing. Comprehensive test-suite, push to prod multiple times a day, feedback, dev.

That's it really.

[mpweiher]

Thanks!

> I'm not smart enough to NOT keep it simple

Yeah, sometimes I feel that most of my "amazing architecture skills" is not understanding what 90% of that stuff is supposed to do or why, and hey, maybe we can just do without it?

For reference: what we did was replace an existing system, which was running over a hundred processes on about a half dozen boxes. We replaced it with a jar.

The jar was around 1000x faster, 100x more reliable, 10x less code while handling around 10x more of the domain.

[9dev]

Not to take away from your point, but that sure does sound competent, aligned, and motivated to me!

[mpweiher]

Yeah: as a result of doing small-a-agile for a while.

Not at the start.

I guess if the point is that agile doesn't work for incompetent teams because teams become much more competent through agile, then I'll concede the point.

[BobaFloutist]

I'm wondering how many production strategies strictly can't work with "excellent teams", small or otherwise, barring gross incompetence or intentional sabotage.

[yobbo]

They are conditions to be met. It's not enough to proclaim them as "your process" and expect results.

When playing piano, the condition you are measured by is acoustic harmonies in the air, not finger movements. The only reasonable advice is either practice more or give up. If you are tone-deaf, it's not reasonable to expect you will learn to play the piano.

[operatingthetan]

I can't count how many times I've seen "agile" projects that were just actually waterfall due to demands from stakeholders.

[t43562]

Absolutely! "You're going to do agile .... and this list of features will be ready on September 20th."

"Oh, feature no 32 is going to take months and we realised that users can just...."

"No"

[magicalhippo]

> "You're going to do agile .... and this list of features will be ready on September 20th."

Well often the real world forces it upon you. As in customer will switch invoicing system on September 20th, integrations have to be ready by then.

We have a lot of this, and hard cut-off is very frequent. If we ain't got all those deliverables implemented by then we will lose customers.

[ezekiel68]

It is difficult to explain to a division director that they do not have sufficeint capacity (enough qualified programmers) to compete features within a set time budget. The old joke goes, "It takes one woman nine months to produce a baby. But: what if we just put nine women in a room for one month!?"

[operatingthetan]

In my professional consulting experience I've found most of those purported "hard deadlines" as mentioned above were usually arbitrarily defined, in other words: completely made up.

[magicalhippo]

That's an important point. It may be a hard cut-off when the switch happens, but the date for the switch may be malleable.

This is crucial to get surfaced early, along with how painful it is to actually move said date if possible.

[magicalhippo]

Yeah that never gets old. But it may be some features can be delivered in stages, maybe some can be solved other ways than intended that require less work.

If the org focuses on the customers one can work together to find a way.

[t43562]

What has happened to me in those cases is that Architects lumped on a lot of extra nice to have things which would certainly have made us fail the time constraints. It was completely un-agile and I only got things done on time by demonstrating very clearly that time sensitive work is not the place for grand refactoring and at last winning over the main architect.

When there's a time constraint one has to be able to winnow out the real must-haves from everything else.

[magicalhippo]

Right, that's deadly. We try to do small refactorings when we can, but for hard deadlines everyone is reminded to keep their focus on what's required for go-live. And if it starts to slip, one has to be dynamic and be ready to search alternate, perhaps temporary, solutions.

[mytailorisrich]

> "You're going to do agile .... and this list of features will be ready on September 20th."

That's OK, the latter is not incompatible with the former. Agile vs waterfall is orthogonal with having to commit to deadlines to deliver features.

[t43562]

Some tasks may simply not be possible or not in the time available. Agile just sort of tells you that - you can see how things are going and if they're going right or not.

Then you have a choice - find something to cut out or accept a later date. This is a mode of thinking that I find non developers have difficulty accepting. They want it all and they want it now and their modus operandi is to keep pretending that it's possible and suggesting that if they shout and stamp a bit that it will somehow rescue the situation.

[mytailorisrich]

Sure but that's life, not an issue with Agile. In fact, because Agile values "working software" in principle you should have more "working software" at the deadline than if you had gone waterfall-ish and spent your time writing detailed docs upfront.

[prerok]

I've seen that too, though I have to say that none of those were as waterfally as the actual waterfall process we used to follow. Back then it was quite literally 0 lines of code until spec (100s of pages) is complete.

[steinsgatezero]

Which ironically makes Agile even worse at times by forcing developers to implement incomplete spec, parts of which are often rewritten over and over again everytime the PM talks to the client.

[ryandrake]

A lot of managers confuse "Agile" with fast and think that "agile" teams are going to deliver software faster. In reality, it's often slower than waterfall. If you have a single feature that's never going to change, and you absolutely positively need it by Date X, then you're probably better off with waterfall.

[mpweiher]

In most of the industry "Agile" is just "doing waterfall really quickly", and for some reason nobody understands you have to stand during your daily micromanagement meetings.

It's a farce.

[codeduck]

Ah yes, the old Agile-as-drunken-waterfall pattern

[Cwizard]

Yes, exactly. It works great. But it is not cookie cutter enough for most orgs to adopt which is what led to Scrum, SAFE and what else. And then organisations take those frameworks (often change them to get even more agility out) and adopt them like it is gospel.

I have worked at an org where team members were not allowed to create tickets because that was the scrum master's job and the product owner had to approve all tickets etc. Who can even think that is a good idea??

Not sure what the solution is. There might not be any.

[yc-kraln]

> Working software over comprehensive documentation

this is 100% backwards for anything safety-critical or that needs to be maintained past a butterfly's lifetime. this is what encourages yolo-driven-development instead of considering what actually should be done, and this is why agile or Agile or whatever formalization or bastardization of it can not be considered software engineering, but merely code monkeying.

[phba]

Yeah, I don't understand why it has to be agile XOR waterfall. Agile development simply doesn't work in projects that have so many externally imposed constraints that there is barely any flexibility left.

[qwertytyyuu]

If it’s good enough for a space program it’s good enough for pretty much anything

[globular-toast]

I never really got the "Individuals and interactions over processes and tools" one. What processes and tools is it talking about? Surely it's not saying I should talk to a colleague to track a change rather than use version control? I feel like I'm missing some context of what "tools and processes" it is talking about.

The others I get, but only after having already spent years in software. I guess like many things you have to see the other way before you can appreciate the better way.

[59nadir]

One example of this would be that it's better to go over to your buddy in QA to talk about the feature you just pushed instead of jumping into Jira and activating your overwrought, weirdly scripted kanban flow that requires 3 asynchronous steps to be taken for it to actually be picked up by anyone who can finally give a damn.

[mytailorisrich]

It is the usual and old advice that instead of, for instance, doing back and forth over emails, Jira, whatever it is more effective to just go discuss with the relevant person directly.

[Cthulhu_]

Yeah we work agile, just look at this diagram, it's super agile. https://framework.scaledagile.com/safe-6-0-configurations/

It's got loops and infinity markers, AND iconography representing humans!

[ryandrake]

I almost threw up looking at that. Please mark things like that NSFW!