3 ms·

Not really a fan of standups either, but I want to express a counter point: developers consistently over-estimate their understanding of the problem domain they

by zmmmmm 8y ago

Not really a fan of standups either, but I want to express a counter point: developers consistently over-estimate their understanding of the problem domain they are working in and the wider context it sits in. That is yes, managers don't "trust" developers - but not in quite as negative a sense as you think. There is a positive aspect of supporting the person, ensuring they are connected to the right resources to succeed and stopping them getting stuck on things that don't matter. I have a small team of devs and I consistently find that given task X they will get stuck and end up spending a lot of time on small subpart Y. And they really want to solve Y, because they are engineers and doing the "hard" stuff is what often drives them. So without some kind of input, what they will do is spend a week on Y and then report back that X was much harder than expected. When told at that point "Oh, we really actually don't need the Y part, we could just to Z instead" they will be quite disappointed, and wonder why they weren't informed that Y wasn't that important to begin with. So more regular communication of some kind is really important to avoid this. As I mentioned, I don't really like daily standups as the optimal way to achieve it ... but I don't quite accept the "leave your developers alone for weeks at a time" strategy either.

tchaffee 8y ago
I wish more devs understood what you said instead of taking it as being micro managed. In short, what good managers distrust is the ability to communicate. We are all pretty bad at it. These meetings just give us an opportunity to continually refine what it is we are actually working towards. Agile to me doesn't mean daily standups. It does mean sharing with each other what we've learned about the problem which almost always means reprioritizing. If that communication isn't happening at least a few times a week, there's something off or unusual.
cellularmitosis 8y ago
I understand that avoiding spending a week on Y is important for business value, but constantly prioritizing shipping features in the cheapest manner possible also means not investing in the long-term growth of your developers. You don't learn much of value by gluing together a handful of framework functions. You become a better engineer by really struggling with and digging into Y for an entire week. If engineers are never given the freedom to do that, they stagnate as framework glue monkeys. "Deep work" is a rare thing in scrum shops.
- zmmmmm 8y ago
  That's a really good point. I know my career has nearly entirely been steered from "non-core" activities that I undertook which never would have been justified on a week to week schedule. Businesses also are actually very poor at understanding technical opportunities which developers at the coalface can see (that is, things that are technically easy or at least feasible, possibly due to the specific skill of the engineer(s) in question, but have very high value).

by zmmmmm 8y ago

tchaffee 8y ago

I wish more devs understood what you said instead of taking it as being micro managed. In short, what good managers distrust is the ability to communicate. We are all pretty bad at it. These meetings just give us an opportunity to continually refine what it is we are actually working towards. Agile to me doesn't mean daily standups. It does mean sharing with each other what we've learned about the problem which almost always means reprioritizing. If that communication isn't happening at least a few times a week, there's something off or unusual.

cellularmitosis 8y ago

I understand that avoiding spending a week on Y is important for business value, but constantly prioritizing shipping features in the cheapest manner possible also means not investing in the long-term growth of your developers. You don't learn much of value by gluing together a handful of framework functions. You become a better engineer by really struggling with and digging into Y for an entire week. If engineers are never given the freedom to do that, they stagnate as framework glue monkeys. "Deep work" is a rare thing in scrum shops.

zmmmmm 8y ago
That's a really good point. I know my career has nearly entirely been steered from "non-core" activities that I undertook which never would have been justified on a week to week schedule. Businesses also are actually very poor at understanding technical opportunities which developers at the coalface can see (that is, things that are technically easy or at least feasible, possibly due to the specific skill of the engineer(s) in question, but have very high value).