Skip to content

Latest commit

 

History

History
33 lines (25 loc) · 7.78 KB

team-topologies.md

File metadata and controls

33 lines (25 loc) · 7.78 KB
Raw

Team Topologies team interactions check

Part of the Multi-team Software Delivery Assessment (README)

Copyright © 2018-2021 Conflux Digital Ltd

Licenced under CC BY-SA 4.0 CC BY-SA 4.0

Permalink: SoftwareDeliveryAssessment.com

Based on selected criteria from the following books:

The Team Topologies area on GitHub contains many free and open tools and templates for helping teams to define behaviors and interactions.

Purpose: Assess the approach to well-defined team interactions within the software system. 

Method: Use the Spotify Squad Health Check approach to assess the team's answers to the following questions, and also capture the answers:

Question Tired (1) Inspired (5)
1. Team Type - Is the type of your team clear to you and to other teams around you? We do not really have "types" of teams. We are very clear about the type of team we are and we make this clear to other teams around us.
2. Long-lived Teams - How durable (long-lived) is your team? When will the team be disbanded? Our team will be disbanded or shuffled within 2-3 months AND/OR Our team will be disbanded when the project finishes. Our team is durable (long-lived) and will be disbanded only when the software and services we build & run are decommissioned.
3. Changing Team Members - How are team members added or removed from the team? What informs the process? Managers decide when to add or remove people from the team. Team members are expected to start being productive immediately. We use the principles and practices from Dynamic Reteaming to help build and rebuild teams in a structured, informed way that brings team cohesion, trust, and fresh perspectives.
4. Team API - How do you define the remit and focus of the team? People can look in our backlog or ticket list to see what we're working on. We use the Team API concept from Team Topologies to define, broadcast, and update our team's mission, current focus, and interaction details. We update our Team API on a regular cadence (at least every 2 weeks).
5. Team Interactions - How do you define, plan, and explore the interactions between your team and other teams? We interact with other teams when needed (on-demand) OR We don't really define or plan interactions with other teams. We use the team interaction modes from Team Topologies to define/plan/explore interactions with other teams to help us work together and improve our product roadmaps.
6. Inter-team Dependencies - What approach to you take to tracking dependencies between teams? We discover dependencies once every planning cycle OR We do not track inter-team dependencies. We use the team dependency tracking principles from Team Topologies to explore and remove inter-team dependencies that block the flow of change. We update our team dependency tracking information at least every week.
7. Team Workspace - In what ways does your physical and/or online team space contribute to a sense of team cohesion and empowerment? We do not have anything that feels like a team space OR Our team space does not feel empowering. Our physical space in the office feels empowering as "our" space AND/OR Our online space feels empowering as "our" space.
8. Team Cohesion - How cohesive does your team feel? How much trust is present inside the team? Our group does not really act as a team, but more like a collection of individuals with the same manager OR Our team really feels like several sub-teams: we hand off work from one person to another inside the team. Our team feels like a single cohesive unit. We all work together and help each other (and challenge each other in a good way) . We prioritize the team goals over individual goals.
9. Team Cognitive Load - How does team cognitive load affect the team's work? Our cognitive load is high OR We do not measure or think about team cognitive load. We assess team cognitive load and aim to limit the size of our software to the cognitive load that the team can deal with. We know that if our cognitive load limit is exceeded, we will not be able to build and run our software properly. "Team-sized software" is a design principle for this organization.