[sanedigital]

You have been blessed to work on self-organizing and self-managing teams. When we come into client orgs, they typically have no process in place and cannot understand why they're not shipping features.

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.

[trentnix]

> When we come into client orgs, they typically have no process in place and cannot understand why they're not shipping features.

Sounds familiar.

Back in my consultant days, we would encounter companies that wanted to be “agile”. They’d insist they were waterfall and 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.

[hef19898]

As my current, very pragmatic scrum master told me: we try to cover the failure to plan woth agile and wonder why nothing gets done (or something along that line). Well, now our chaos is agile...

[ethbr0]

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

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