Scrum isn't perfect, but its an "industry-standard" practice that we can use to get quick buy-in from client stakeholders, and then use to apply even the most basic level of process to these teams.

As an engineer at Google or a freelance developer it never made much sense to me.

But as a manager of remote, distributed, international teams?

It makes a lot of sense.

Sounds familiar.

Back in my consultant days, we would encounter companies that wanted to be “agile”. They’d always insist they were waterfall and that it wasn’t working.

Truth is, if they’d actually been doing waterfall they’d have been performing far better. Instead, they were just chaos, reacting to one fire after another with no plan to get out.

Additionally, many teams were simply staffed with poor managers and poor engineers. There’s no consulting-fu or process-fu that was going to overcome that. You can’t win horse races with pack mules, my dad (a basketball coach) used to say.

> You can’t win horse races with pack mules, my dad (a basketball coach) used to say.

You can boil it down to saying that Scrum is either (a) micromanagement or (b) an admission that your developers and their managers suck.

Fix the problem, instead of slapping a bureaucratic band-aid on that's going to attrit any remaining quality developers.

I don’t think this is right. It’s like a sports team: your system, your philosophy, your approach matters. Like in basketball, you might utilize the flex motion offense or you might use the Tex Winters’ triangle.

Good teams can succeed with both, but depending on your personnel and what you’re up against, you might find one strategy works better than the others.

And I've seen it used exactly that way in practice at bad companies.

It's not a strawman if it's lived experience and professed corporate IT strategy at a lot of non-tech companies.

It has nothing to do with "agile" though. In fact, the agile manifesto clearly says "individuals and interactions over processes and tools". An organization that follows processes that don't make sense to its employees is not agile, despite what they claim.

But they are more than capable of putting in rules and processes that allow them to do agile. The problem is that doing agile without being agile does far more harm than good.

There's a long list but only one really needs to be mentioned:

Payroll costs $XX,XXX,XXX and is due every 2 weeks.

I've sat through "agile training" and it's the most plain grift I've ever seen.

Selling developers on a deadline-less utopia, but walking it back just enough to not make management types paying for the whole thing balk. Switching which side of the scale their finger is on based on who seems the most engaged at a given moment.

But at the end of the day, it's always predicated on the idea that developers can always provide backpressure against clients.

Well you're free to do that, and clients are free to not pay, and unless your developers will work for client IOUs that's the end of the game.

Agile mentality is great. The idea of rapidly iterating and rapidly producing feedback is great. But "Agile methodology" has evolved into a productivity ponzi scheme meant to add a place for consultants and trainers to insert themselves for $$$

I dont really blame them. They've gotta eat, and occasionally they probably do get a client who is genuinely willing to enact a real transformation. Dysfunctional upper management is the real problem.

Dysfunctional upper management: maybe.

Customers don't pay money today for products delivered on an indefinite, unspecified future timeline: definitely.

More software engineers should have to be involved with customer conversations to internalize this. Agile works best when you have a consultancy situation, and the customer can be directly involved in the construction of the product while it is being built. This rarely applies. But even then, customers tend to make ridiculous demands like "advance notice before you change the software from under us so that we can re-train our X-thousand person call center", and as soon as you do that, you've got a calendar, a deliverable and a deadline. Probably some Gantt charts in there too, because only trivial projects have a single deliverable.

Then you say "OK, let's actually be agile, break down the project timeline using iterative deliverables and clear development cycles"...now you have sprints.

They frequently do for features though. I waited a year for my bank to implement virtual credit cards.

This reality usually doesnt stop some layer(s) of management from waterfalling the shit out of everything simply because they can't conceive of an alternative.

Not the kind of feature I'm talking about -- your bank isn't contracting with you, personally, to make a credit card. Apple doesn't care at all about my opinions on when to release their next phone. Google doesn't ask me what they should name Chat this week.

Nonetheless, the stakeholders for such a project are going to be internal to the company, and there will be many: customer support, billing, compliance, marketing and legal, just to name a few. There will also be many deadlines, simply because huge numbers of people have to coordinate to turn out a complicated project.

> As a corporate user of software I have waited similar lengths of time for features I really wanted.

Again, unless you are signing the purchase order, you're not the customer, and you don't set the deadlines. Someone else is setting the deadlines for you. Also, just because you had to wait a long time doesn't mean that deadlines didn't exist for the project.

> This is why it's better for execs to treat bespoke deliveries as something radioactive

All software projects are bespoke. Some are smaller and more tightly scoped than others, but if you didn't need custom work done, you wouldn't pay an engineer to do it.

I know. I expressly declared the type of feature you were talking about radioactive.

The tragedy isnt that this type of feature exists it's that some managers cant conceive of there being any other kind and will turn every feature radioactive. Thats how we get shit software.

Yes, the Agile Industrial Complex is a total grift and nothing to do with the manifesto.

Him warning about this may or may not have an effect though.

Highly recommended.

https://youtu.be/a-BOSpxYJ9M

I just started a new role leading a 30 person Engineering team at a company doing Scrum. My very first questions to everyone was why are we doing this? Answers ranged from some expectations like regular/predictable delivery of product to "because that's how software is done." From there, it's figure out a process that makes sense and actually achieves objectives. Scrum provides a nice framework, but everyone needs to be bought into the goals of it first. (My next actions were to get rid of most of the useless workflow rules in Jira and build that accountability at the team level...it works amazingly well that way)

I agree that it's much more doable at a small company. Once companies get big enough, the need to centrally plan and coordinate seem to create an irresistible urge to apply identical processes to all teams, compare velocities, and all sorts of other bad habits.

If you are working in an optimized team, that understands the business, understands the customer, and efficiently and incrementally delivers business value building the right kind of software then these practices won't help you and as you point out may actually hurt you.

The above though is some minuscule fraction of software teams in the real world (and some may not know it).

The problem with Agile practices and Scrum is that despite their theoretical ability to improve the way we build software, and the good intentions of the original ideas, inefficient teams and companies will always find a way to adopt the practices they think are good (and therefore keep them inefficient) while rejecting the practices that may help them. That's the conundrum of pretty much any process (and funny enough "people over process" in a twisted way means people that have no clue will subvert any process that tried to push for doing things better in most orgranizations).

Really? The impression I get it's that it's geared towards internal teams who can "iterate" until the cows come home. Contractors work on a fixed time-frame and/or cost, agile doesn't jive well with that unless you're just labour augmentation.

Not sure why we still talk about it.

I don't have any evidence, but I think it's an undeniable fact that coordination effort is very expensive. We are all familiar with how fast our 1 person weekend projects go; you spend 12 hours on Saturday evenings on something, and it feels like it progresses faster than what your team of 30 people is doing at work 5 days a week. My opinion is that projects scale exponentially with complexity. A 1 person project takes 1 person. A 2 person project takes 2 people. But then, a 3 person project takes 4 people. A 4 person project takes 8 people. A 5 person project takes 16 people. By the time you are at big company sizes, you might have 30,000 people vaguely working on the same thing; by my rule above, that's a project that's 15x more complex than a 1 person project. That's why it feels like "my friends and I could make Twitter over the weekend, why do they need 30,000 employees!?" You're thinking that results scale linearly over the number of people, but it really scales logarithmically over the number of people. So now you're 1/30,000th of a 15 person project, and you don't feel as productive. You are 0.003% of the equation. If you work 10x as hard, you're 0.03% of the equation. It just doesn't fit with your mental model of productivity that you extrapolate from personal projects (where it's 100%, or 110% if you had a really good cup of coffee). That's why it feels bad, but it's also why management is not super concerned that you are spending 20 hours a week in meetings. Oh no, now you're only 0.0015% of the equation.

The final question is, why does society put up with this? The answer is, there is money in these projects that are just a bit more complicated than a software engineer's personal project. You will be remembered more for the 0.003% contribution you had to the moon landing than you will for making the absolute best ever music file organizer. It sucks, but that's how the Universe works. You can embrace it, or you can fight it. But if you want to stave off the heat death of the Universe, you might need a team and a plan and maybe a few meetings to share the plan with your team ;)

The problem I've seen is that formal agile processes substantially reduce individual engineers' autonomy—slowing everything down seems more a symptom than the core problem. (Of course, it's ultimately the symptoms that kill the patient, right?)

Coordination is both important and difficult, but a process oriented around tracking and directing individuals at a bite-sized-ticket level is not a necessary, sufficient or even particularly effective solution. It's an abstraction to make work legible in the worst way: it's restrictive to the people doing the work, encourages unhealthy patterns of top-down management, poorly reflects the ground truth while still giving managers the illusion of detailed understanding and control.

As for top-down, organizations try that approach because it seems like the problems could all be solved if people weren't coordinating with each other, but just did what they were told. It seems like it doesn't work like that; this presentation explains it pretty well (and was on HN last weekend): https://komoroske.com/slime-mold/

There’s a lot of gripers who don’t like feeling managed and attack it with all sorts of false criticism though. And of course, poorly-run Agile can be pretty annoying.

The key is to keep things minimal and fast: quick stand-ups, and as few meetings as needed. Who is leading it definitely matters too. Ideally it is a lead developer rather than a “product” or “project” person, IMO.