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.

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.

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.

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

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

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.

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"

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.

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.

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

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.

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

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.

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.

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