"A key contribution of DevOps was to raise awareness of the problems lingering in how teams interacted (or not) across the delivery chain, causing delays, rework, failures, and a lack of understanding and empathy toward other teams. It also became clear that such issues were not only happening between application development and operations teams but in interactions with many other teams involved in software delivery, like QA, InfoSec, networking, and more." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)
"A 'stream' is the
continuous flow of work aligned to a business domain or organizational
capability. Continuous flow requires clarity of purpose and responsibility so
that multiple teams can coexist, each with their own flow of work. 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."
"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." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)
"[…] decisions based on
org-chart structure tend to optimize for only part of the organization,
ignoring upstream and downstream effects. Local optimizations help the teams
directly involved, but they don’t necessarily help improve the overall delivery
of value to customers. Their impact might be negligent if there are larger
bottlenecks in the stream of work."
"However, in a
highly collaborative context filled with uncertainty over outcomes, relying on
the org chart as a principal mechanism of splitting the work to be done leads
to unrealistic expectations." (Matthew Skelton & Manuel Pais, "Team
Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)
"Organizations that
rely too heavily on org charts and matrixes to split and control work often
fail to create the necessary conditions to embrace innovation while still
delivering at a fast pace. In order to succeed at that, organizations need
stable teams and effective team patterns and interactions. They need to invest
in empowered, skilled teams as the foundation for agility and adaptability. To
stay alive in ever more competitive markets, organizations need teams and
people who are able to sense when context changes and evolve accordingly."
"Systems thinking focuses on optimizing for the whole, looking at the overall flow of work, identifying what the largest bottleneck is today, and eliminating it." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)
"Teams are always works
in progress, but they are also your best shot at delivering value continuously
and sustainably by aligning them with the business. Ideally, teams should be
long lived and autonomous, with engaged team members. However, teams don’t live
in isolation. They need to understand how and when to interact with each other.
And these team interactions need to evolve over time to support the distinct
phases of discovery and execution that products and technology go through
during their lifetimes."
"Teams take time to
form and be effective. Typically, a team can take from two weeks to three
months or more to become a cohesive unit. When (or if) a team reaches that
special state, it can be many times more effective than individuals alone. If
it takes three months for a team to become highly effective, we need to provide
stability around and within the team to allow them to reach that level."
"The org chart does have its uses in the context of building software systems, specifically around regulatory and legal compliance. However, in a highly collaborative context filled with uncertainty over outcomes, relying on the org chart as a principal mechanism of splitting the work to be done leads to unrealistic expectations. We need to rely instead on decoupled, long-lived teams that can collaborate effectively to meet the challenge of balancing speed and safety." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)
"The problem with taking the org chart at face value is that we end up trying to architect people as if they were software, neatly keeping their communication within the accepted lines." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)
"Trying to determine the cognitive load of software using simple measures such as lines of code, number of modules, classes, or methods is misguided. […] When measuring cognitive load, what we really care about is the domain complexity - how complex is the problem that we’re trying to solve with software? A domain is a more largely applicable concept than software size." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)
No comments:
Post a Comment