I am not a fan of the general commoditized one-size-fits-all management approach that goes by the modern term "Agile" (putting aside all the no-true-Scotsman debates about what 'real' Agile is for now...)

Usually I read articles like this feeling like the author missed the point, and that it's just some rehashing of the many different ways modern Agile gets it so wrong.

But this article actually impressed me a lot.

I agree very much that the one of the biggest problems with Agile is the notion of fixed-length "sprints". Even the basic language of 'sprinting' is a problem, which begets bad culture and a misunderstanding of different speeds and priorities for different teams and different paradigms of work, like the difference between people answering PagerDuty alerts and people researching a new statistical model ... Those two groups absolutely don't work the same way or at the same cadence or with the same need for planning, and there are a million other teams and work types that differ too.

It seems reasonable to use bookkeeping tools like Trello or JIRA, but the horizon of work should be customizeable and should be adaptive to specific personnel, teams, workflows, situations, times of the year, etc. If the interface artificially requires choosing one cadence length, then just make sure the company knows to ignore it and assign no meaning to it. Then let teams break things up however they choose.

The other huge one, which the author mentions, is wasting time on useless group estimation. This one is a gigantic mess and fraught with problems:

- It can become politicized among the team, seen as a chance to lobby for whose work is more valuable, or even in the worst cases to try to directly attack someone else on the team by making it look like their workload is always lighter.

- It sparks a ton of bikeshedding. People will argue about whether something is "a 1" or "a 2" in some totally meaningless Fibonacci units, like OMG who cares! You'd be better off just assigning it, starting some work, and asking for updates. You'll know when something creates a surprise blocker or involves way more work than expected.

- Managers always claim that they just want velocity numbers for ballpark understanding to aggregate up to higher level managers, but it's not true. They really want to cherry-pick statistics and charts from that nonsense to sell other managers on stories about progress, road maps, etc. So you basically turn your expensive software developers into Mechanical Turkers who are manually punching in meaningless Fibonacci numbers for no other reason that giving middle management the opportunity to datamine juvenile Excel charts. In the end, none of it corresponds to deadlines, workloads, etc.

- Agile support staff, like Scrum masters and coaches and shit, always have their own take on it that superficially sounds like it's more humane and focused on holistic workflow health, but really is just double-speak for capitulating to the stuff management wants. For example, I had an Agile coach once who swore that all our troubles with time getting wasted on story points estimation could be solved if we created "gold standard" example stories, like a canonical 1-pointer, canonical 3-pointer, etc., and just used these during our planning meeting. I could see the painful sincerity in his expression, and I couldn't help but think, "this guy doesn't know anything about software engineering at all ... he just wants us to think positively about what management is making him make us do."

On the third point that the author made, about group code ownership, I think the problem ties back in with the estimation problems. For example, the author writes,

> "Rightfully, everyone should have read access, but things go wrong when everyone has write permissions..."

It's not so much that literal write privileges are the problem. Rather it's about fluffy policies like, "everyone's opinion should could equally towards code review" or the idea that everyone has equal say in the chosen architecture, design idea, etc.

It sounds nice and democratic, but in practice it's just more surface area for bikeshedding and time wasting. I find it's a lot better to explicitly take into account who has expertise in which topics when weighting whose opinion to use. Letting people act as mini-dictators regarding a certain implementation, or have creative control over an API design, is often a lot better than trying to get consensus on everything.

Besides, the bigger picture is that you want to use code review and testing to make nice iteration loops over your code and your choices anyway. So if someone has creative control and gets an API done quickly, you can do code review and let someone else iterate on some refactoring during the next cycle, or later when there is time. Over time, the code begins to reflect a compromise among the design preferences of the team, but in a way that always maintains testability and gets checked through acceptance tests and CI.

Compared with a design project that flames out before it even starts because you have multiple competing design doc proposals and bitter arguments about whether to use OOP or functional programming or this library or that library ... Most of the time just assign it to someone with skills in that area and move on.

No story points, no two-week implied deadline or progress check in, no feeding of meaningless Fibonacci numbers to middle management, no speaking about the creative process of software design with language like "sprinting."

No time wasting with useless group discussion for assigning story points. No time wasting with bikeshedding and stylistic debates about how to solve a problem or start a design solution.

Just use common sense, and then during the rare times when your team actually flags something up for group debate about a design idea, you'll be more confident that it has a good signal-to-noise ratio, and your team's work won't be judged by arbitrary Fibonacci numbers.