3 ms·

Yes, that means disruptions, but being on the same page/unblocking others is usually more important. The real problem is often that people are getting blocked

Yes, that means disruptions, but being on the same page/unblocking others is usually more important. The real problem is often that people are getting blocked so easily in the first place. I'm sure I've seen every excuse imaginable for why organisations need a constant stream of pings via Slack or Teams or whatever they use. There is usually some underlying claim that everyone should respond to those pings quickly and accept the endless random interruptions that cripple their individual productivity because it's somehow better for the team as a whole. But if you make the effort to plan things and coordinate properly to begin with and you allow your people to concentrate and get on with their work then sudden, completely blocking problems should be unusual and your processes can be chosen accordingly.

The_Colonel 3y ago
> But if you make the effort to plan things and coordinate properly to begin with That assumes something like this is even possible, won't be completely wrong immediately after the plan is finished, and won't take weeks / months to finish. This is what we used to do in waterfall - architects created a detailed specification which was obsolete / wrong / pipe dreams the moment they hit the Send/Publish button.
- Silhouette 3y ago
  That's true, it does assume that. I have never seen a project where this common hypothetical actually became reality so until proven otherwise I'm OK with assuming that Bigfoot is a myth. I have however seen many projects where management did understand their product and their market well enough to plan strategy more than 24 hours in advance. Their developers could then be reasonably confident about what they'd be working on for a while and act accordingly. If your organisation is functional on this basic level then getting the right people together early to gather information and consider alternatives and sketch out a design is useful for the same reasons that getting peer review when the code is done is useful or that having more than one person writing tests or doing QA is useful. It's far more efficient to identify and correct problems early in software development. If you skip the up-front discussions and planning entirely then you miss several useful opportunities to do that. Typically in that scenario the problems are either identified and corrected during code review at the earliest or - worse - they are not identified and corrected at that stage either because the right people didn't have the right information to see the problem or because they did see it but it was judged too expensive to fix by then - and so the resulting bugs and tech debt make it through.

The_Colonel 3y ago

> But if you make the effort to plan things and coordinate properly to begin with That assumes something like this is even possible, won't be completely wrong immediately after the plan is finished, and won't take weeks / months to finish. This is what we used to do in waterfall - architects created a detailed specification which was obsolete / wrong / pipe dreams the moment they hit the Send/Publish button.

Silhouette 3y ago
That's true, it does assume that. I have never seen a project where this common hypothetical actually became reality so until proven otherwise I'm OK with assuming that Bigfoot is a myth. I have however seen many projects where management did understand their product and their market well enough to plan strategy more than 24 hours in advance. Their developers could then be reasonably confident about what they'd be working on for a while and act accordingly. If your organisation is functional on this basic level then getting the right people together early to gather information and consider alternatives and sketch out a design is useful for the same reasons that getting peer review when the code is done is useful or that having more than one person writing tests or doing QA is useful. It's far more efficient to identify and correct problems early in software development. If you skip the up-front discussions and planning entirely then you miss several useful opportunities to do that. Typically in that scenario the problems are either identified and corrected during code review at the earliest or - worse - they are not identified and corrected at that stage either because the right people didn't have the right information to see the problem or because they did see it but it was judged too expensive to fix by then - and so the resulting bugs and tech debt make it through.