3 ms·

> The problem that engineers have with it is that it does make things slower. The problem I've seen is that formal agile processes substantially reduce individ

> The problem that engineers have with it is that it does make things slower. 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.

jrockway 4y ago
I think the process is poor at accommodating generalists, since most people are not generalists. You might want to design a new feature one day, talk to customers the next, and then refactor your CI system on the third. The org really has no way to accommodate that; the cost to bring you up to speed on all the details is too high and your request is too weird. There is already a product team, support team, and testing team. Nobody has ever wanted to do all those things; all they want to do is show up, work on some technical mumbo jumbo, and disappear at 5pm. Moving the business forward what that at the bottom is what the process focuses on. (And, yes, this is why startups exist and do so well. If you can figure out Capital One or Twitter and pick the 10% that actually matters, you're back to a 2 person team. It ain't easy, though.) 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/ https://komoroske.com/slime-mold/

jrockway 4y ago

I think the process is poor at accommodating generalists, since most people are not generalists. You might want to design a new feature one day, talk to customers the next, and then refactor your CI system on the third. The org really has no way to accommodate that; the cost to bring you up to speed on all the details is too high and your request is too weird. There is already a product team, support team, and testing team. Nobody has ever wanted to do all those things; all they want to do is show up, work on some technical mumbo jumbo, and disappear at 5pm. Moving the business forward what that at the bottom is what the process focuses on. (And, yes, this is why startups exist and do so well. If you can figure out Capital One or Twitter and pick the 10% that actually matters, you're back to a 2 person team. It ain't easy, though.) 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/ https://komoroske.com/slime-mold/