Note 05 Team Topologies

This chapter tired to explain below question .

1. How do we decide we have right team in place ?
2. Do team have necessary balance between autonomy and a support by other teams ?

Four fundamental type of teams needed to run modern software systems.

When run with effective software boundaries Bounded Context and team interaction and the restriction of these four teams acts as powerful template for effective organisation design.

1. Stream-aligned team

1. Its mission is to ensure smooth flow of work for a given stream.

2. It is the one of the core teams in the organisation to delivery value to users as quickly, safely, and independently as possible. Team should be are empowered to run independently. Since they are close to service/product they are creating they are most efficient to in reacting to system problems in near real time, steering the work as needed.

3. Service they provide should be through APIs, either for internal or external consumption. Other team should void interfacing with them directly. Team should provide API contracts, documents and other helpful artefacts which should be sufficient enough for other teams to consumer their services. In-fact it can be the measured as KPI for the their success.

4. In-order to efficently perform team require below mentioned set of skill sets and capabilities within it.

• Application Security
• Commercial and Operational Viability analysis
• Design and Architecture
• Development and Coding
• Infrastructure and Operability
• Metrics and Monitoring
• Product management and Ownership
• Testing and Quality assurance
• User Experience

5. Stream-aligned team is NOT “Product” or “Feature Team”

Usually product or feature team are focused on end-to-end delivery of a feature or piece of software. But in this world of rapidly changing business requirement based on competition and customers need, we have to be more felixible. It is not just about delivering and handing over to operational/maintainance team anymore. It is about continuous process which include continuous design based on requirements. Hence this stream aligned team is long lived.

Expected Behaviour of stream aligned team

1. Promote socio-technical safe space for experiments and adaptability from feedback.
2. Promote state of flow to deliver value.
3. Self independent and requires minimal hand-offs of work to other teams.
4. They should be in path or have achieved the path of autonomy, mastery and purpose, they three component of engaged knowledge workers.

2. Enabling team

Why this team exist ? High performing teams are continuously improving their capabilities in order to stay ahead.Since steam aligned team focuses on the flow and delivering value to the business, we need to provide a way to keep their knowledge and capabilities improving, and this where enabling team helps.

• The end goal of an enabling team is to increase the autonomy of stream-aligned teams by growing their capabilities with a focus on their problems first, not the solutions per se.
• This is not a permanent team, they cross over many teams.
• An enabling team is composed of specialists in a given technical (or product) domain, and they help bridge this capability gap. Such teams cross-cut to the stream-aligned teams and have the required bandwidth to research, try out options, and make informed suggestions on adequate tooling, practices, frameworks, and any of the ecosystem choices around the application stack. This allows the stream-aligned team the time to acquire and evolve capabilities without having to invest the associated effort.
• Enabling team has to be collaborative in nature and should understand problems of the stream aligned team in order to provide guidance.
• Team should to be a Servent leader rather than dictating technical choices. For example, the enabling team might set up a walking skeleton of a deployment pipeline or a basic test framework combining automation tools and some initial scenarios and examples.

Expected Behaviour:

• It is expected from enabling team to stay ahead of the curve in keeping abreast of new approaches, tooling and practise in their area of expertise.
• They can act as messenger to inform stream-aligned team of new technology framework introduced into the organisation or decommissioning of certain tech.
• They act as curator that facilitate appropriate knowledge sharing inside the organisation.
• They are not expected to fix problem like code quality, poor practises etc.

3. Complicated-subsystem team

A complicated-subsystem team is responsible for building and maintaining a part of the system that depends heavily on specialist knowledge, to the extent that most team members must be specialists in that area of knowledge in order to understand and make changes to the subsystem for example complex legacy applications, mainframes etc. The goal of this team is to reduce the cognitive load of stream-aligned teams working on systems that include or use the complicated subsystem.

Expected Behaviour

Prioritise and deliver upcoming work respecting the need of the stream aligned team.

4. Platform team

• The purpose of a platform team is to enable stream-aligned teams to deliver work with substantial autonomy.
• Ease of use for their services is fundamental for platform team.
• Platform they offer to others should be treated as product that can be reliably used regardless it is being used by internal or external team.
• Team should align the purpose between stream align team and their backlog.
• Platform team value should be measured by the value of the service they provide to product teams (consumer of it).
• Maintain internal pricing for infrastructure and services to regulate the domain, helping to avoid everyone asking for premium level service.

Expected Behaviour

• The mission for a platform team is to provide the underlying internal services required by stream-aligned teams to deliver higher level services or functionalities, thus reducing their cognitive load.
• Strong collaboration with stream aligned team.
• Fast prototyping and fast feedback from stream aligned team.
• Focus on usability and reliability that is treating platform as product.

A good platform is “Just Big Enough”

Care need to be taken to ensure that platform always serve the needs of consuming application and service and not the other way round

Platform team should always focus on user experience and particularly developer experience

Good platform provides standards, templates, APIs, and well-proven best practices for Dev teams to use to innovate rapidly and effectively. A good platform should make it easy for Dev teams to do the right things in the right way for the organization; this applies to all kinds of product development, not just those involving software.

In all cases, we should aim for a thinnest viable platform (TVP) and avoid letting the platform dominate the discourse. As Allan Kelly says, “software developers love building platforms and, without strong product management input, will create a bigger platform than needed.”A TVP is a careful balance between keeping the platform small and ensuring that the platform is helping to accelerate and simplify software delivery for teams building on the platform.

The most important part of the platform is that is build for developers . Developers are its customers.

Platform should not live in isolation, there should be way to provide feedbacks.

Attention to user experience developer Experience such as How-to guides and comprehensive documentation (but not verbose), up to date, and focused on achieving specific tasks, not documenting every last corner and niche of the platform.

A good test of developer experience is how easy it is to onboard a new Developer to the platform.

Platform should follow software product management and service management techniques for good developer support.

The platform, therefore, needs a roadmap curated by product-management practitioners, possibly co-created but at least influenced by the needs of users (Dev teams).

The user personas will help the platform team to empathize with the needs, frustrations, and goals of typical users of the platform. Members of the platform teams will engage with customers (Dev teams and others) regularly to understand what they need.

Platform is not just a collection of features that Dev teams happened to ask for at specific points in the past, but a holistic, well-crafted, consistent thing that takes into account the direction of technology change in the industry as a whole and the changing needs of the organisation. A good platform will also serve to reduce the need for security and audit teams to spend time with the Dev team.