Improving collaboration from the computer networking perspective
Some time ago, I had really unusual sprint retrospective, which turned out to be whole Scrum retrospective where we asked questions if retros even work.
Which made me thinking so much that I decided to write. Because writing is thinking and it helps to save time of your coworkers during retro meeting. When you think about some point during the meeting you don't have enough time to thing and properly formulate the thought because of the time limit of the retro and you waste time of your colleagues which are waiting for you to formulate the thought. With writing, thought is already prepared and polished. Maybe I'll need to write my talks before the meeting more often. I procrastinated quite for some time to turn my notes into somewhat publishable article, but better later then never.
So, sprint guide says:
The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.
During the Sprint Retrospective, the team discusses:
- What went well in the Sprint
- What could be improved
- What will we commit to improve in the next Sprint
What do we improve? Our output, that means how many problems and how good, we solve for our stakeholders.
And personal improving is usually out of scope. You could learn more React or CSS or some other tools and develop front-end or whatever you are building better and faster. You could sleep better, eat better, exercise, concentrate better and then think better.What could team improve? Usually every improvement comes to communication.
Teams are like parallel processes. They require synchronization. Retros are like trying to optimize parallel program.
Synchronization adds overhead and limits scaling. There is theoretical limit of number of people who could work on project (without organization and splitting it to the projects).
You could achieve perfect productivity when you have embarrassingly parallel problem. That's something that requires no synchronization, like sweeping the street. Every neighbor could just sweep the section near their house, and then the whole street would be cleaned in parallel very fast.
But most of complex problems are not embarrassingly parallel, so to reduce communication overhead you should somehow make sure that only necessary information is communicated.
In computer networks that is achieved by introduction of the switch. Before switch all of the nodes of the network use the same medium (for example, cable or multiple cables connected to network hub), and when two nodes try to simultaneously send packages, signal interference would destroy the information. So they wait for random amount of time and try again, second one should then wait for the one that "speaks" first. That method of controlling access to medium is called CSMA/CD (Carrier-sense multiple access with collision detection) and it is employed, for example, in Ethernet.
Similar protocol is used by humans. When people are in the same room, usually everyone (polite) listens and waits for others to stop talking, to say his phrase. When two or more persons start talking simultaneously, they stop, wait for a random time and try again. Different medium and time scale, but same principle.
But it is inefficient and has limit on number of nodes in a network/persons in a room. In a big room (for example, during a party) there would never be a moment of silence.
So, in modern networks we add bridge or switch, where we split network in halves and put bridge between them, or just connect every node to switch. Then switch is forwarding packages only to the ports where it knows addressed receivers are connected. Because unlike a dumb hub that just amplifies and re-transmits signals, switch maintains a forwarding information base (aka forwarding table) of who is connected where.
Gigabit Ethernet and faster networks do not even use CSMA/CD and rely exclusively on switches.
In same way when we split teams into sub-teams, we could use somebody (2nd-level manager? envoy? I don't know if such role exists) as a bridge to route information between sub-teams, so everybody has less stuff to talk about, and only relevant "packets" of information are shared.
Then, instead of having 2 hours of sprint planning where every developer looks at 20 tasks from which they have clue only about 10, they could have 1 hour planning and look at 10 tasks relevant to them.
But of course everything is trade-off. Introducing switches obviously means increasing number of network hops and more latency. In the same way, receiving a message from your manager saying "manager of other team said their employee complained about something not working as it should", would mean that you ask "what is not working?" your manager, they ask this question manager of other team, and finally question reaches actual employee who had a problem. So good manager also filters tickets ensuring they have enough context.
If something like some bug is complex, then it might be beneficial to stop playing broken telephone and go meet directly, so getting feedback for debugging is faster.