More on this book
Community
Kindle Notes & Highlights
Read between
January 17 - February 27, 2022
In this chapter, we explore three core team interaction modes that simplify and clarify the essential interactions needed between teams building software systems: collaboration, X-as-a-Service, and facilitating.
“The roots of Toyota’s success lie not in its organizational structures but in developing capability and habits in its people.”
the team doing the facilitating helps to define and clarify the communication between other teams based on the system desired architecture.
Is the component boundary in the right place? Is the component API well specified? Is the component easy enough to use? Does the complicated-subsystem team have a missing capability within the team, such as UX or DevEx?
It’s important to recognize that neither mode is better or worse than the other; they simply are useful for different kinds of work.
Collaboration is good for rapid discovery and avoiding hand-offs and delays, but the downside is a higher level of cognitive load. Each side of the collaboration needs to understand more about the other side, so the team members have to retain more in their heads. However, this “collaboration tax” is worth it if the organization wants to innovate very rapidly.
Accelerate Learning and Adoption of New Practices
This “deliberate collaboration” is particularly useful where two groups have very different prior experience due to the prevailing practices around their respective technologies.
Collaboration is costly but good for discovery of new approaches, and X-as-a-Service is good for predictable delivery; so teams can be set up to match the needs of each area of the software system and each team.
At any one time, different teams within an organization will have different interaction and collaboration needs.
Trigger: Software Has Grown Too Large for One Team
Changes to certain components or workflows in the system routinely get assigned to the same people, even when they’re already busy or away. Team members complain about lack of system documentation.
A key aspect of this sensory feedback is the use of IT operations teams as high-fidelity sensory input for development teams, requiring joined-up communications between teams running systems (Ops) and teams building systems (Dev).
“Project sponsors looking to reduce cost opt for a different team of lower-cost people for maintenance work. This is false economy. It hurts the larger business outcome and reduces IT agility.”
Increasingly, software is less of a “product for” and more of an “ongoing conversation with” users.
The team providing this “design and run” continuity of care also needs to have some responsibility for the commercial viability of the software service; otherwise, decisions will be made in a vacuum separate from financial reality.
Sriram Narayan, author of Agile IT Organization Design, says “separate maintenance teams and matrix organizations . . . work against responsiveness.”
Instead, it is much more effective to have one team responsible for new services and BAU of an existing system side by side.
people in IT operations need to be able to recognize and triage problems quickly and accurately, providing accurate, useful information to their colleagues who are focused on building new features.
An obsession with “feature delivery” ignores the human-related and team-related dynamics inherent in modern software, leading to a lack of engagement from staff, especially when the cognitive load is exceeded.
Similarly, many organizations are unaware of how a poorly chosen “reorg” can destroy an organization’s strategic capability for innovation and sustainable software delivery.
