More on this book
Community
Kindle Notes & Highlights
For example, perhaps we have four stream-aligned teams building different parts of the software system. One of the teams may be in collaboration mode with the platform team, undertaking some discovery work on new logging technology, while the other three teams are simply consuming the platform in X-as-a-Service mode.
it’s often difficult to have the required organizational self-awareness to detect when it’s time to evolve the team structure.
Trigger: Software Has Grown Too Large for One Team
A startup company grows beyond fifteen people (Dunbar’s number).
Changes to certain components or workflows in the system routinely get assigned to the same people, even when they’re already busy or away.
This reinforcing cycle of specialization is a local optimization (“get this request delivered quickly”) that can negatively affect the team’s overall flow of work when planning gets dictated by “who knows what” rather than “what’s the highest priority work we need to do now.”
Team velocity or throughput metrics show a clear downward variation compared to one year ago. (There is always some variation, so make sure it’s not accidental.)
no hard dependencies
Being able to self-serve new infrastructure via an internal platform is a soft dependency (assuming the provisioning self-service is maintained by a platform team).
Note that it’s also possible that delivery has slowed down because of accrued technical debt. In this scenario, the complexity of the codebase might reach a state where even small changes are costly and frequently cause regressions. That means deliveries take much longer to develop and stabilize than when the codebase was initially created.
(1) “Platformize” the lower-level services and APIs with a thin “platform wrapper” that provides a consistent developer experience (DevEx) for stream-aligned teams with things like request-tracking correlation IDs, health-check endpoints, test harnesses, service-level objectives, and diagnostic APIs. This “outer platform” is built on a still lower-level platform, but that remains hidden from stream-aligned teams.
Modern software delivery must take a completely different approach: the operation of the software should act as and provide valuable signals to the development activities.
Treat Teams and Team Interactions as Senses and Signals
Have we misunderstood how users need/want to behave? Do we need to change team-interaction modes to enhance how the organization is working? Should we still be building thing X in house? Should we be renting it from an external provider? Is the close collaboration between Team A and Team B still effective? Should we move toward an X-as-a-Service model? Is the flow of work for Team C as smooth as it could be? What hampers flow? Does the platform for teams D, E, F, and G provide everything those teams need? Is an enabling team needed for a period of time? Are the promises between these two teams
...more
To sustain a fast flow of software changes, organizations must invest in organizational sensing and cybernetic control.
Instead of trying to optimize for lowest cost in so-called “maintenance” work, it is essential that organizations use signals from maintenance work as input to software-development activities.
Systems thinking: optimize for fast flow across the whole organization, not just in small parts Feedback loops: Development informed and guided by Operations Culture of continual experimentation and learning: sensing and feedback for every team interaction
no deja muy claro que es lo q mide Operaciones...
Operations thus becomes an input to design.”
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.
Having separate teams for “new stuff” and BAU tends to prevent learning, improvements and ability to self-steer. It is a non-cybernetic approach.
it is much more effective to have one team responsible for new services and BAU of an existing system side by side.
A cybernetic approach to maintaining older systems has a single stream-aligned team (or pair of teams) developing and running the new service and the older systems, enabling the team to retro-fit newer telemetry to the older system and increase the fidelity of the sensing from both systems.
In effect, each stream-aligned team should expect to look after one or more older systems in addition to the newer systems they are building and running. This helps them learn about a wider range of user and system behaviors, and avoid repeating mistakes made in earlier systems.
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.
Instead of the IT-operations service desk being staffed with the most junior people, it should be staffed with some of the most experienced engineers in the organization, either exclusively or in tandem with some of the more junior members.
The reason so many organizations experience so many problems with software delivery is because most organizations have an unhelpful model of what software development is really about.
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.
Other team types can be actively harmful to an organization.
polemico. El concepto de Leading Team de LeSS es muy interesante
Stream aligned: a team aligned to the main flow of business change, with cross-functional skills mix and the ability to deliver significant increments without waiting on another team. Platform: a team that works on the underlying platform supporting stream-aligned teams in delivery. The platform simplifies otherwise complex technology and reduces cognitive load for teams that use it.
The Team Topologies approach treats the team as the fundamental means of delivery, where a team is not simply a collection of individuals with the same manager but an entity with its own learning, goals, mission, and reasonable autonomy.
This “team-sized architecture” focuses on people first, and is a more sustainable and humane approach to software architecture than either monolithic or microservices architectures, both of which focus on the technology first.
to be able to deploy different parts of the system independently, with a short lead time, and we decide to use small, decoupled services in order to do so, we need to make our teams similarly small and decoupled, with clear boundaries of responsibility.
A healthy organizational culture: an environment that supports the professional development of individuals and teams—one in which people feel empowered and safe to speak out about problems, and the organization expects to learn continuously. Good engineering practices: test-first design and development of all aspects of the systems, a focus on continuous delivery and operability practices, pairing and mobbing for code review, avoiding the search for a single “root cause” for incidents, designing for testability, and so on. Healthy funding and financial practices: avoiding the pernicious
...more
A lack of clarity in business vision is akin to asking a horticulture team to “create a garden” without any indication of the purpose of the garden. Should we grow fruit or vegetables? Should we aim for colorful flowers all year round or just in summer? Is the garden to be used for meditation or for another purpose?
Act and operate as an effective team? Own part of the software effectively? Focus on meeting the needs of users? Reduce unnecessary cognitive load? Consume and provide software and information to other teams?
Citizen-oriented tasks for government online services: applying for a passport, paying taxes, or registering for a set of healthcare options (task-oriented streams). Business banking products: online money management, automation of bank transactions, invoicing clients (role-oriented streams). Online ticket purchasing: searching for tickets, purchasing tickets, managing “My Account” and refunds (activity streams). Regional products: European market, North American market, Asian market, etc. (geographical streams). Market segment: consumer, small and medium business, enterprise, large corporate
...more
After you have identified the most relevant streams for your organization, identify the services needed to support a reliable, swift flow of change in those streams.
Remember: technology is only ever a part of the platform; roadmaps, guided evolution, clear documentation, a concern for DevEx, and appropriate encapsulation of underlying complexity are all key parts of an effective delivery platform for stream-aligned teams.
Service management (for all kinds of teams and areas, not just for production systems)
No serious sports team would consider not employing coaches and trainers, and no serious organization should be without coaches and trainers either.
Emphasize the humanistic aspects of Team Topologies: the focus on the team, the explicit limits on cognitive load, the reduction in noise and interruptions due to team-fist office space, and a limit on free-for-all communications. Identify the focus on fast flow of change for the core business streams, supported by a “thinnest viable platform” and related teams and coaching.
bounded context: a unit for partitioning a larger domain (or system) model into smaller parts, each of which represents an internally consistent business domain area.
Brooks’s law: law coined by Fred Brooks which states that adding new people to a team doesn’t immediately increase the capacity of a team.
Conway’s law: law coined by Mel Conway that states that system design will copy the communication structures of the organization which designs it.
facilitating mode: team(s) helping (or being helped by) another team to clear impediments.
fracture plane: a natural “seam” in the software system that allows it to be easily split into two or more parts.
joined-at-the-database monolith: composed of several applications or services all coupled to the same database schema, making them difficult to change, test, and deploy separately. monolithic build: uses one gigantic continuous integration (CI) build to get a new version of a component.
monolithic thinking: “one-size-fits-all” thinking for teams that leads to unnecessary restrictions on technology and implementation approaches between teams.
platform team: enables stream-aligned teams to deliver work with substantial autonomy.
