It's also worth noting that another way to reduce the cost to maintain your existing functionality (priority 0) is to actively _remove_ rarely-used or less valuable functionality
> Teams working together on a single priority ("swarming") seem to be more successful than teams where each person is doing 1-2 things on their own
It's an interesting one, same as e.g. pair programming; people (and I'm speaking for myself but I'm sure others will agree) prefer to work alone, because software engineering is difficult, brainy work, whereas swarming and pair programming are social activities. If you're like me - introverted, probably on the spectrum, etc - it's something that is well out of your comfort zone.
I think this is not referring to swarm-, or pair-programming. Think of it as the team focusing on a single feature/problem at a time. It just means the team going in the same direction.
> Teams working together on a single priority ("swarming") seem to be more successful than teams where each person is doing 1-2 things on their own
I wonder if there is a reference supporting that statement. I believe it, but it would be nice to have a reference.
You can figure out if people use or care about your service or not via observability.
Re:How To Do Less
by blacklivsmatr on Monday March 14, 2022 @02:15AM
(#30669058)
Disagree. If you followed observability no text editor would do more than Notepad
Re:How To Do Less
by bryanrasmussen on Monday March 14, 2022 @03:05AM
(#30669293)
most text editors aren't services though?
* Finishing work is more important than starting it
* Teams working together on a single priority ("swarming") seem to be more successful than teams where each person is doing 1-2 things on their own
A few subtle points in this article that made me think:
* Keeping existing features working as well as customers expect is a great zeroth priority but it can be hard to know what customers actually expect. Absolutely the worst is when you carefully maintain a very reliable, feature-rich thing that no one particularly wants or uses. In an org without a dedicated PM, I'm never quite sure how to account for time spent on the product-management work of "listen to my customers about what they want from my service".
* The article talks about engineers and stakeholders caring about "project X" and "feature Y". A bunch of literature suggests that anyone who is thinking this way is probably a bit lost -- they have lost sight of the business outcome that the team's work is supposed to be getting (more sales, quantifiably happier customers, fewer pager alerts interrupting engineers, whatever). If you can tie particular features/projects to outcomes maybe you can make it easier to explain why you've prioritized other work first (it makes bigger outcomes sooner).