5 ms·

Error 42. Scrums are not about what to work on. I have witnessed the incredible effectiveness of what are now called scrums. Maybe we call this "A tale of Two

Error 42. Scrums are not about what to work on. I have witnessed the incredible effectiveness of what are now called scrums. Maybe we call this "A tale of Two Teams". Team A built a product and the manager held these annoying meetings once a week where people talked about what they worked on. It was stupid. Or so I thought at the time. Ultimately, this team shipped products, time after time. Team two was at a database company which did a rewrite of its product. Each team went off for months and worked on the rewrite. At the end each team brought its contribution to the table and lo and behold, none of parts worked with the other parts. These teams never had meetings with the other teams, so of course the pieces did not work together. The assumptions that each team made, and the decisions they made, ensured that no two pieces would or could interact. The whole process was a fiasco and months of time were wasted. This company did not exist for much longer. So no matter what you call it, no matter what you think it is supposed to do, the simple fact is * Meetings of the entities working on a single project to share what they are doing is effective. * Very effective. Complex Adaptive Systems.

SideburnsOfDoom 3y ago
> * Meetings of the entities working on a single project to share what they are doing is effective. * In other words, these things are very valuable: Individuals and interactions, Working software, collaboration, Responding to change. https://agilemanifesto.org/ https://agilemanifesto.org/
sgarland 3y ago
Nothing stops you from talking to other teams under any other system. And frankly if an adult on Team A needs to be told "you should find out what Team B is doing so your products work together," you have larger problems.
horsawlarway 3y ago
I call this the "group project" problem (there's probably a catchier term kicking around out there), mainly from watching it happen time after time in group projects as a TA in school, but it plays out mostly the same in companies. Stated simply: If you split up a task and assign parts to team members, you are only 30% done when all members have completed their part of the task. 70% of the work is in combining the parts back into a coherent whole. So the teams that fail horribly are the ones that work in isolation and believe that combining the output of that work is easy. The teams that actually get a product out the door focus on the majority of the work (making a coherent whole out of disparate parts) as SOON as possible. That means sharing back with the group at the earliest possible moment, and then as often as possible as you update and change your part. Now... scrum is hardly the only way to make that happen, but I think the processes it encourages follow the same trend: Work alone for very short periods, share often, adapt as needed in response to what else is shared. The problem with scrum is just all the rest of it (especially scrum masters... those certifications are a black mark on your resume in my opinion).
adrianmsmith 3y ago
A third approach (not endorsing it, merely adding it here for the sake of completeness) is to have a software architecture role which defines how the components interact. Each time is free to do whatever they want within their component, but they have to meet their interface spec. When the components are put together, there'll be small problems/bugs for sure, but if they've followed the architecture (and the architecture team/person has been making sure of that) then they should basically fit together.
- smcleod 3y ago
  That doesn’t have to be a silo, you can have the capability rather than a role and agree on specs / contracts as to how your tools/apis will interact and work with the bigger picture or the product.
ebiester 3y ago
Meetings are a poor indicator of continuous integration. Instead, build a steel thread. Make the simplest thing that can go through every team first. Every team working on the project goes to build that initial slice of functionality. When done, you have the infrastructure and tests necessary to make sure each next slice is functioning. It means that you have a low level friction through the project, but it is much smaller than the overall friction at an integration phase. Then, use meetings to discuss the clarification of the specification and the technical design. Any status meetings can be at the EM/PM/Lead level as necessary but you will have the feedback to know how things are progressing quickly.

SideburnsOfDoom 3y ago

> * Meetings of the entities working on a single project to share what they are doing is effective. * In other words, these things are very valuable: Individuals and interactions, Working software, collaboration, Responding to change. https://agilemanifesto.org/ https://agilemanifesto.org/

sgarland 3y ago

Nothing stops you from talking to other teams under any other system. And frankly if an adult on Team A needs to be told "you should find out what Team B is doing so your products work together," you have larger problems.

horsawlarway 3y ago

I call this the "group project" problem (there's probably a catchier term kicking around out there), mainly from watching it happen time after time in group projects as a TA in school, but it plays out mostly the same in companies. Stated simply: If you split up a task and assign parts to team members, you are only 30% done when all members have completed their part of the task. 70% of the work is in combining the parts back into a coherent whole. So the teams that fail horribly are the ones that work in isolation and believe that combining the output of that work is easy. The teams that actually get a product out the door focus on the majority of the work (making a coherent whole out of disparate parts) as SOON as possible. That means sharing back with the group at the earliest possible moment, and then as often as possible as you update and change your part. Now... scrum is hardly the only way to make that happen, but I think the processes it encourages follow the same trend: Work alone for very short periods, share often, adapt as needed in response to what else is shared. The problem with scrum is just all the rest of it (especially scrum masters... those certifications are a black mark on your resume in my opinion).

adrianmsmith 3y ago

A third approach (not endorsing it, merely adding it here for the sake of completeness) is to have a software architecture role which defines how the components interact. Each time is free to do whatever they want within their component, but they have to meet their interface spec. When the components are put together, there'll be small problems/bugs for sure, but if they've followed the architecture (and the architecture team/person has been making sure of that) then they should basically fit together.

smcleod 3y ago
That doesn’t have to be a silo, you can have the capability rather than a role and agree on specs / contracts as to how your tools/apis will interact and work with the bigger picture or the product.

ebiester 3y ago

Meetings are a poor indicator of continuous integration. Instead, build a steel thread. Make the simplest thing that can go through every team first. Every team working on the project goes to build that initial slice of functionality. When done, you have the infrastructure and tests necessary to make sure each next slice is functioning. It means that you have a low level friction through the project, but it is much smaller than the overall friction at an integration phase. Then, use meetings to discuss the clarification of the specification and the technical design. Any status meetings can be at the EM/PM/Lead level as necessary but you will have the feedback to know how things are progressing quickly.