More on this book
Community
Kindle Notes & Highlights
Neither individual cubicles nor fully open-plan seating is generally suitable for teams: we need something better.
Office design for effective software delivery should accommodate all of the following modes of work: focused individual work, collaborative intra-team work, and collaborative inter-team work.
design of the office layout means that people from other squads or tribes can easily recognize aspects of other teams’ work (such as kanban boards, WIP limits, status radiators, and so on) and rapidly learn new approaches.
We based our teams loosely on the model from Spotify, so we have squads of around eight people that build specific parts of a system, and collections of squads known as tribes. Each squad has its own team area located close to other squad areas from the same tribe. This enables squads from the same tribe to talk easily to each other
Importantly, due to limits on team size (Dunbar’s number), there is an effective upper limit on the cognitive load that a single team can bear. This strongly suggests a limit on the size of the software systems and complexity of domains that any team should work with.
because communication between individuals is de-emphasized in favor of communication between teams for day-to-day work, the organization supports a wide range of communication preferences, from those people who communicate best one to one to those who like large group conversations.
The main topology is (business) stream-aligned; all other topologies support this type. The other topologies are enabling, complicated-subsystems, and platform.
The other common anti-pattern is shuffling team members. This leads to extremely volatile team assembled on a project basis and disassembled immediately afterward,
While there is a sense of higher flexibility and a perceived ability to respond faster to deadlines, the cost of forming new teams and switching context repeatedly gets overlooked (or is unconsciously factored in the project estimates).
The assumption that the software-development process has little or nothing to learn from how the software runs in the live environment is fundamentally flawed.
“we must . . . ensure delivery teams are cross-functional, with all the skills necessary to design, develop, test, deploy, and operate the system on the same team.”
following the “boy-scout rule” (leaving the code better than they found it).
A lack of ownership over shared code may result from the cumulative effects of several teams working on the same codebase unless inter-team discipline is high.
Non-blocking dependencies often take the form of self-service capabilities (e.g., around provisioning test environments, creating deployment pipelines, monitoring, etc.) developed and maintained by other teams.
there needs to be a split between the responsibility of designing the cloud infrastructure process (by the cloud team) and the actual provisioning and updates to application resources (by the product teams).
To achieve teams that have well-defined responsibilities, can work independently, and are optimized for flow, it is essential to detect and track dependencies and wait times between teams.
The “DevOps team” anti-pattern is a quintessential example. On paper, it makes sense to bring automation and tooling experts in house to accelerate the delivery and operations of our software. However, this team can quickly become a hard dependency for application teams if the DevOps team is being asked to execute steps on the delivery path of every application, rather than helping to design and build self-service capabilities that application teams can rely on autonomously.
reduced ambiguity around organizational roles is a key part of success in modern organization design.
A stream-aligned team is a team aligned to a single, valuable stream of work; this might be a single product or service, a single set of features, a single user journey, or a single user persona.
The mission of a platform team is to reduce the cognitive load of stream-aligned teams by off-loading lower level detailed knowledge (e.g., provisioning, monitoring, or deployment), providing easy-to-consume services around them.
In a modern software organization, we expect most teams to be stream aligned. The flow of work is clear, and each stream has a steady, expectable flow of work for the stream-aligned team to prioritize. This stands in stark contrast to traditional work allocation, whereby either a large request by a single customer or a set of smaller requests by multiple customers get translated into a project. Once the project is approved and funded, several teams will potentially get involved (e.g., front-end, back-end, and DBA teams) and be required to fit the new work into their existing backlog.
“autonomy, mastery, and purpose,” the three key components of engaged knowledge workers,
An enabling team is composed of specialists in a given technical (or product) domain, and they help bridge this capability gap.
An enabling team stays ahead of the curve in keeping abreast of new approaches,
I felt strongly that an engineering enablement team should plan for its own extinction from the very first day to avoid other teams becoming dependent.
To this end, we ran mob programming sessions, recorded demos, and invited every team to our showcases. We estimated that a quarter of our team’s time was spent actually implementing solutions; the rest was sharing knowledge.
Stream-aligned teams should expect to work with enabling teams only for short periods of time (weeks or months) in order to increase their capabilities around a new technology,
The purpose of a platform team is to enable stream-aligned teams to deliver work with substantial autonomy. The stream-aligned team maintains full ownership of building, running, and fixing their application in production. The platform team provides internal services to reduce the cognitive load that would be required from stream-aligned teams to develop these underlying services.
The platform team’s knowledge is best made available via self-service capabilities via a web portal and/or programmable API
“A platform team’s value can be measured by the value of the services they provide to product teams.”
A platform team relies on fast prototyping techniques
A platform team has a strong focus on usability and reliability for their services (treating the platform as a product),
A good platform provides standards, templates, APIs, and well-proven best practices for Dev teams to use to innovate rapidly and effectively.
In all cases, we should aim for a thinnest viable platform (TVP) and avoid letting the platform dominate the discourse.
These platforms have all generally succeeded in reducing the complexity of the underlying systems while exposing enough functionality to be useful to teams building on the platform. This drive to “simplify the developer’s life” (as Conway puts it)20 and reduce cognitive load (see Chapter 3) is an essential aspect of a good platform.
There should be a way to give feedback to platform developers and how the platform is doing in general.
An attention to good UX/DevEx will make the platform compelling to use, and the platform will feel consistent in the way the APIs and features work.
Feature usage is tracked with metrics and used to shape conversations about prioritization.
the ratio of stream-aligned teams to other kinds of teams should be between about 6:1 and 9:1.
The most effective pattern for an architecture team is as a part-time enabling team
Flow is difficult to achieve when each team depends on a complicated web of interactions with many other teams.
Standardizing everything in order to minimize variation simplifies management oversight of engineering teams, but it comes at a high premium.
In Accelerate, the authors mention how their research indicates that enforcing standardization upon teams actually reduces learning and experimentation, leading to poorer solution choices.2
there’s a misunderstanding that what is needed is colocation of purpose, not just colocation of bodies.
A fracture plane is a natural seam in the software system that allows the system to be split
Traditional stonemasons hit stones at particular angles to split the rocks in clean segments, taking advantage of their natural fracture planes.
It is usually best to try to align software boundaries with the different business domain areas.
Identifying bounded contexts requires a fair amount of business knowledge and technical expertise, so it’s normal to make mistakes initially.
having both business owners and technologists speaking an ubiquitous language within a bounded context.
ensuring such processes, including manual approvals or activities, are always mapped in the delivery pipeline and having appropriate access controls to the pipeline gives traceability of changes across all systems while covering most auditing requirements.
