5 ms·

You're not the only one. I work with quite a few above-average and bright guys. Even something as simple as "you make this module, you make this module, I make

You're not the only one. I work with quite a few above-average and bright guys. Even something as simple as "you make this module, you make this module, I make this module and they all communicate through this core interface" is far from trivial. In something like Scrum, the emphasis seems to be more on "everyone works on this little piece of this module", which bloats the communication overhead required and I get into the same problem you describe: implementation details need to be made concrete much faster, as now people need to know them to proceed instead of a general idea what data they'll be getting. NB: I know this is not specific to Scrum, and Scrum does not enforce this. Yet I can't help but feel there is some sort of correlation.

lmilcin 6y ago
To be fair the while the need for communication is inflated the goal of Scrum is also to make that communication cheap. That's why work in small, tightly knit teams, on the same feature. That's why refinings, plannings, standups, etc.
- BlargMcLarg 6y ago
  Is it? Often times I feel Scrum was more invented as a way to centralize communication under the lofty goal of increasing its quality, and decreasing the quantity of communication (make all activities central to reduce decentralized meetings with loads of people). Which to me says the opposite of making communication cheap. In practice, I feel the opposite tends to happen too. Not only does the quantity increase, but the quality of these centralized activities is questionable at best, and high quality decentralized activities slowly disappear due to the increased overhead. In tight knit teams, I find many of the centralized activities are unnecessary, since we deal with them as we go anyway. If we don't, someone will end up blocked for a day if not multiple days. The only exceptions being large design choices and assuring everyone works towards the same goal. If you need to sync on that every day in your average CRUD webapp dev team, I highly question how tightly knit the team is.
  - rightbyte 6y ago
    Ye having Jira-tickets for everything and stand ups are a form of centralization. Things are not supposed to go under the radar. I am in a team of 5 right now where stand-up style meetings is kinda fine due to few members in the meeting, though. I would like some readme-style changenotes.txt instead of tickets for a release. There is not way you dig down the ticket pile anyway after the sprints are done so the traceability is quite overrated. The tickets are lost like a friends scream for help in your Facebook feed when the march continue.
  - Mauricebranagh 6y ago
    Err you know SCRUM DSDM RAD or what have you explicitly prioritise speed over all and its not a 121 replacement for waterfall
TeMPOraL 6y ago
This resonates. I find it to be the worst when the piece of work is something substantially new in the team - like developing a new application, different from other projects the company has done. > Even something as simple as "you make this module, you make this module, I make this module and they all communicate through this core interface" is far from trivial. Yup. So the other day, we had to develop a completely new GUI app based on customer's initial wishlist, and we wanted to split the work along those lines - and I really agonized over that, because at the early stage none of this is stable. Especially not the "core interfaces" - which tend to stabilize somewhere close to MVP. So here I am, trying to wring out some sense out of a superposition of 20 different design ideas in my head, and I'm being asked to split work. We ended up splitting the project into big subdomains, and designing interfaces along those subdomains - becoming a poster child of Conway's law - and I hated it. But we made it work. I could derive two lessons from that project. One, design isn't going to be perfect up front - everything will end up being repeatedly redesigned as the project progresses, so there will be opportunities to fix bad decisions. So you may as well pick the least bad split and get the work going. Two, actually, if you instead let a single person mull over that design in their heads for two weeks instead of forcing them to "just split work already" on a project that took a year to get to MVP, maybe this would have saved a lot of redesigns down the road.

lmilcin 6y ago

To be fair the while the need for communication is inflated the goal of Scrum is also to make that communication cheap. That's why work in small, tightly knit teams, on the same feature. That's why refinings, plannings, standups, etc.

BlargMcLarg 6y ago
Is it? Often times I feel Scrum was more invented as a way to centralize communication under the lofty goal of increasing its quality, and decreasing the quantity of communication (make all activities central to reduce decentralized meetings with loads of people). Which to me says the opposite of making communication cheap. In practice, I feel the opposite tends to happen too. Not only does the quantity increase, but the quality of these centralized activities is questionable at best, and high quality decentralized activities slowly disappear due to the increased overhead. In tight knit teams, I find many of the centralized activities are unnecessary, since we deal with them as we go anyway. If we don't, someone will end up blocked for a day if not multiple days. The only exceptions being large design choices and assuring everyone works towards the same goal. If you need to sync on that every day in your average CRUD webapp dev team, I highly question how tightly knit the team is.
- rightbyte 6y ago
  Ye having Jira-tickets for everything and stand ups are a form of centralization. Things are not supposed to go under the radar. I am in a team of 5 right now where stand-up style meetings is kinda fine due to few members in the meeting, though. I would like some readme-style changenotes.txt instead of tickets for a release. There is not way you dig down the ticket pile anyway after the sprints are done so the traceability is quite overrated. The tickets are lost like a friends scream for help in your Facebook feed when the march continue.
- Mauricebranagh 6y ago
  Err you know SCRUM DSDM RAD or what have you explicitly prioritise speed over all and its not a 121 replacement for waterfall

TeMPOraL 6y ago

This resonates. I find it to be the worst when the piece of work is something substantially new in the team - like developing a new application, different from other projects the company has done. > Even something as simple as "you make this module, you make this module, I make this module and they all communicate through this core interface" is far from trivial. Yup. So the other day, we had to develop a completely new GUI app based on customer's initial wishlist, and we wanted to split the work along those lines - and I really agonized over that, because at the early stage none of this is stable. Especially not the "core interfaces" - which tend to stabilize somewhere close to MVP. So here I am, trying to wring out some sense out of a superposition of 20 different design ideas in my head, and I'm being asked to split work. We ended up splitting the project into big subdomains, and designing interfaces along those subdomains - becoming a poster child of Conway's law - and I hated it. But we made it work. I could derive two lessons from that project. One, design isn't going to be perfect up front - everything will end up being repeatedly redesigned as the project progresses, so there will be opportunities to fix bad decisions. So you may as well pick the least bad split and get the work going. Two, actually, if you instead let a single person mull over that design in their heads for two weeks instead of forcing them to "just split work already" on a project that took a year to get to MVP, maybe this would have saved a lot of redesigns down the road.