1. Images
1.1. 4 Types of team and 3 interactions modes
1.2. Obstacles to fast flow
1.3. Dunbar
1.3.1. Team < 10 people
1.3.2. Families / Tribes < 50-100 people
1.3.3. Divisions / P&L lines < 150-500 people
1.4. Self sufficient cross-functional stream aligned team
1.5. Org Size vs Soft Scale
1.6. Four fundemental topologies
1.7. Interaction modes
1.8. Summary
2. Further reading
2.1. Reinventing Organizations as Frederic Laloux
2.2. Guide to Organisation Design: Creating High-Performing and Adaptable Enterprises,
2.3. Building Successful Communities of Practice, Emily Webber
2.4. Brain of the Firm, Stafford Beer
2.5. Principles of Product Development Flow, Don Reinertsen
3. Part 1: Teams as the Means of Delivery
3.1. Ch 1: The Problem with Org Charts
3.1.1. Reverse Conway's manouver
3.1.1.1. Design teams to match desired architecture
3.1.2. Teams should be long-lived and autonomous
3.1.3. Ensure that teams are intrinsically motivated and are given a real chance of doing their best work within a system
3.1.4. Rely on decoupled, long-lived teams that collaborate effectively to meet the challenge of balancing speed and safety
3.1.5. "Team structures must match the required software architecture or risk producing unintended designs."
3.1.6. Dan Pink's 3 elements of intrinsic motiviation
3.1.6.1. autonomy
3.1.6.2. mastery
3.1.6.3. purpose
3.2. Ch 2: Conway's Law and Why it Matters
3.2.1. Communication
3.2.1.1. Requiring everyone to communicate with everyone else is a recipe for a mess.
3.2.1.2. Limiting communication paths to well-defined team interactions produces modular, decoupled systems.
3.2.1.3. More communication is not necessarily a good thing
3.2.2. Too often teams structure is based on technology choices
3.2.3. Conwey and Microservices vs Monoliths or Siloes
3.2.4. Tech components good practices
3.2.4.1. Loose coupling
3.2.4.2. High cohesion
3.2.4.3. Clear and appropriate version compatibility
3.2.4.4. Clear and appropriate cross-team testing
3.2.5. Architects
3.2.5.1. "More than ever I believe that someone who claims to be an Architect needs both technical and social skills, they need to understand people and work within the social framework. They also need a remit that is broader than pure technology—they need to have a say in organizational structures and personnel issues"
3.3. Ch 3: Team-First Thinking
3.3.1. Main points
3.3.1.1. The team is the most effective means of software delivery, not individuals
3.3.1.2. Limit the size of multi-team groupings within the organization based on Dunbar’s number.
3.3.1.3. Every part of the system needs to be owned by exactly one team
3.3.1.4. Remove team toxic people
3.3.1.5. Main problem in IT - ever increasing size and complexity of codebases
3.3.1.5.1. It org responsibility to reduce cognitive load
3.3.1.6. "“Minimize cognitive load for others” is one of the most useful heuristics for good software development.
3.3.2. Good team-mate practices (aka "team over individual")
3.3.2.1. Arrive on meetings on time
3.3.2.2. Keep discussions and investigations on track
3.3.2.3. Encourage a focus on team goals
3.3.2.4. Help unblock other team members before starting new work
3.3.2.5. Mentor new or less experienced team members
3.3.2.6. Avoid "winning" arguments, instead agree to explore options
3.3.3. Diversity
3.3.3.1. Recent research in both civilian and military contexts strongly suggests that teams with members of diverse backgrounds tend to produce more creative solutions more rapidly and tend to be better at empathizing with other teams’ needs.
3.3.4. Cognitive load
3.3.4.1. initrinsic cognitive load
3.3.4.1.1. training
3.3.4.1.2. choice of tech
3.3.4.1.3. good hiring
3.3.4.1.4. pair programming
3.3.4.2. extrenous cognitive load
3.3.4.2.1. automate boring tasks
3.3.4.3. germane cognitive load
3.3.4.3.1. challanging problem at hand
3.3.5. Random
3.3.5.1. Case of Adstream
3.3.5.2. More abstractions might mean smaller but not necesarilly simpler codebase (cognitive load still stays)
4. Part 2: Team Topologies that Work for Flow
4.1. Ch 4: Static Team Topologies
4.1.1. Main points
4.1.1.1. Don't structure team according to tech skills, but rather according to business area (i.e no "frontend team")
4.1.1.2. Teams are mostly organized according to ad-hoc needs
4.1.1.2.1. Antipattern: ad-hoc team design
4.1.1.3. Need for feedback loop: live software -> development (thus case against silos and handovers)
4.1.1.4. Teams should be self-sufficient (non-blocking)
4.1.1.5. Handovers / dependencies inevitable lead to delays (different cadences etc)
4.1.2. Reading
4.1.2.1. Scaling Agile @ Spotify
4.1.3. Random
4.1.3.1. Tracking dependencies (knowledge, task or resource)
4.1.3.1.1. Checks. whether dependencies are inter-tribe (fine) or between tribes (potential problem)
4.2. Ch 5: The Four Fundamental Team Topologies
4.2.1. Topologies
4.2.1.1. Stream-aligned team
4.2.1.1.1. Small highly skilled team is more agile than large one
4.2.1.1.2. Favors more generalists rather than specialists
4.2.1.1.3. Behaviours / Outcomes
4.2.1.2. Enabling team
4.2.1.2.1. Collaborative in nature
4.2.1.2.2. Avoid "ivory tower"
4.2.1.2.3. Checks
4.2.1.2.4. Plan for it's own extinction (DevOps)
4.2.1.2.5. Behaviours / Outcomes
4.2.1.3. Complicated-subsystem team
4.2.1.3.1. Behaviours / Outcomes
4.2.1.3.2. Never sits in the flow of changes, only provide services (no handoff)
4.2.1.4. Platform team
4.2.1.4.1. Ease of use is fundamental for platform adoption
4.2.1.4.2. Idea of internal pricing
4.2.1.4.3. Behaviours/Outcomes
4.2.1.4.4. Fractal structure - Platform team may be composed of different topologies internally
4.2.1.4.5. DevEx is crucial
4.2.1.4.6. Platform is just a product - use product management techniques
4.2.2. Insight
4.2.2.1. Reduced ambiguity around organizational roles is a key part of success in modern organization design
4.2.2.2. 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.
4.2.2.3. Fixing engineering issues
4.2.2.4. Single area of expertise
4.2.2.5. Simplicity due to no single functional team members
4.2.2.6. Examples of successful platform
4.2.2.6.1. 8086 processor
4.2.2.6.2. Linux and Windows operating systems
4.2.2.6.3. Borland Delphi
4.2.2.6.4. Java Virtual Machine
4.2.2.6.5. .Net Framework
4.2.2.6.6. Pivotal Cloud Foundry / Microsoft Azure
4.2.2.6.7. Kubernetes
4.2.2.7. Dissolve teams based on tech component (e.g frontend team)
4.2.2.8. Main role of stream aligned team
4.3. Ch 6: Choose Team-First Boundaries
4.3.1. Monolith aspects
4.3.1.1. Application monolith
4.3.1.2. Joined-at-the-database monolith
4.3.1.3. Monolithic builds
4.3.1.4. Monolithic (coupled) releases
4.3.1.5. Monolithic Model (Single View of the World)
4.3.1.6. Monolithic thinking (overly standarized)
4.3.1.7. Monolithic workplace (open-plan for all)
4.3.2. Fracture planes
4.3.2.1. Bounded context
4.3.2.2. Regulatory compliance
4.3.2.3. Change cadence
4.3.2.4. Team location
4.3.2.5. Risk
4.3.2.6. Performance isolation
4.3.2.7. Technology
4.3.2.8. User personas
4.3.2.9. Overall goal
4.3.2.9.1. Does the resulting architecutre support more autonomous team with reduced cognitive load?
4.3.2.9.2. Natural facture plane that would allow the resulting parts to evolve independently
4.3.3. Inisight
4.3.3.1. Adoption of open office actually reduced face to face interactions
5. Key thoughts
5.1. The goal for a “DevOps Team” should be to put itself out of business by enabling the rest of the org.
5.2. A dedicated architecture team is usually an anti-pattern to be avoided.
5.3. Collaborate on potentially ambiguous interfaces until the interfaces are proven stable and functional. [then switch to X-as-a-service]
5.4. “We need to be alert for the white space between the roles, gaps that nobody feels responsible for.”
5.5. Additional ingredients of success
5.5.1. A healthy organizational culture
5.5.2. Good engineering practices
5.5.3. Healthy funding and financial practices
5.5.4. Clarity of business vision
6. Part 3: Evolving Team Interactions for Innovation and Rapid Delivery
6.1. Ch 7: Team interaction modes
6.1.1. Key thoughts
6.1.1.1. Dynamics between teams changes constantly
6.1.1.2. Autonomy and well defined interactions
6.1.1.2.1. Collaboration vs team other team as providing a service
6.1.1.3. It is key to try avoid a need for all teams to communicate with all other teams in order to achieve their ends
6.1.1.4. While there is some correlation between system size in terms of lines of code or features, it is the limit on cognitive capacity to handle changes to the system in an effective way that is most of concern here.
6.1.1.5. A long-lived, high-performing product team should be able to steadily improve their delivery cadence as they find ways to work more efficiently together and remove bottlenecks in delivery. However, a pre-requisite for these teams to flourish is to grant them autonomy over the entire life cycle of the product.
6.1.1.5.1. Alas it is common in organization to reduce autonomy with time rather than opposite
6.1.2. Collaboration types
6.1.2.1. Collaboration
6.1.2.1.1. General
6.1.2.1.2. Pros
6.1.2.1.3. Cons
6.1.2.1.4. Limits
6.1.2.2. X-as-a-service
6.1.2.2.1. General
6.1.2.2.2. Pros
6.1.2.2.3. Cons
6.1.2.2.4. Limits
6.1.2.3. Facilitating
6.1.2.3.1. General
6.1.2.3.2. Pros
6.1.2.3.3. Cons
6.1.2.3.4. Limits
6.2. Ch 8: Evolve Team Structures with Organization Sensing
6.2.1. Key thoughts
6.2.1.1. Collaboration is good for rapid discovery and avoiding hand-offs and delays, but the downside is a higher level of cognitive load.
6.2.1.2. X-as-a-Service is best for situations where predictable delivery is more important than rapid discovery.
6.2.1.3. This deliberate use of a change in team interaction to force a beneficial change in delivery capability is the essence of strong, strategic technology leadership.
6.2.1.4. Topologies are in constant evolution
6.2.1.4.1. If a team needs to explore part of the technology stack or part of the logical domain model currently handled by another team, then they should agree to use collaboration mode for a specific period of time.
6.2.1.4.2. "Discover to establish"
6.2.1.5. Ops as key input
6.2.1.5.1. 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. By treating operations as rich, sensory input to development, a cybernetic feedback system is set up that enables the organization to self steer.
6.2.1.6. Increasingly, software is less of a “product for” and more of an “ongoing conversation with” users.
6.2.1.7. By separating the maintenance work from the initial design work, the feedback loop from Ops to Dev is broken, and any influence that operating that software may have on the design of the software is lost
6.2.2. Triggers for evolution
6.2.2.1. Software has grown too large for 1 team
6.2.2.1.1. Team grew beyond 15 people (Dunbar's number)
6.2.2.1.2. Other teams spend lots of time waiting on a single team to undertake changes.
6.2.2.1.3. Changes to certain components or workflows in the system routinely get assigned to the same people, even when they’re already busy or away.
6.2.2.1.4. Team members complain about lack of system documentation.
6.2.2.2. Delivery Cadence is Becoming Slower
6.2.2.2.1. Team members qualitatively feel it takes longer to release changes than it used to.
6.2.2.2.2. 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.)
6.2.2.2.3. Team members complain that the delivery process used to be simpler, with fewer steps.
6.2.2.2.4. Work in progress keeps increasing, with many changes waiting for another team’s action.
6.2.2.3. Multiple Business Services Rely On a Large Set of Underlying Services
6.2.2.3.1. Stream-aligned teams have limited visibility of end-to-end flow within their service area.
6.2.2.3.2. It becomes difficult to achieve a smooth and rapid flow of change due to the number and complexity of subsystem integrations.
6.2.2.3.3. Attempts to “reuse” an existing set of services and subsystems becomes more and more challenging.
6.2.3. Signals to track
6.2.3.1. Have we misunderstood how users need/want to behave?
6.2.3.2. Do we need to change team-interaction modes to enhance how the organization is working?
6.2.3.3. Should we still be building thing X in house? Should we be renting it from an external provider?
6.2.3.4. Is the close collaboration between Team A and Team B still effective? Should we move toward an X-as-a-Service model?
6.2.3.5. Is the flow of work for Team C as smooth as it could be? What hampers flow?
6.2.3.6. 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?
6.2.3.7. Are the promises between these two teams still valid and achievable? What needs to change to make the promises more realistic?
6.2.4. Three Ways of Devops for High Performing organizations
6.2.4.1. Systems thinking
6.2.4.1.1. Optimize for fast flow across the whole organization, not just in small parts
6.2.4.2. Feedback loops
6.2.4.2.1. Development informed and guided by Operations
6.2.4.3. Culture of continual experimentation and learning
6.2.4.3.1. Sensing and feedback for every team interaction