Delivery

Welcome to Scaled Delivery System

The model of work is based on observation that autonomous teams that can work together in an aligned way self-organising. All the management need to do is to help and regulate the co-work introducing the framework and vision. It is a matrix model of scaled agile with focus on lean software development principles. Where systems are designed, implemented and rolled out in transparency and collaboration.

“Dealing with multiple teams in a product development organization is always a challenge! One of the most impressive examples we’ve seen so far is Spotify, which has kept an agile mindset despite having scaled to over 30 teams across 3 cities. Spotify is a fascinating company that is transforming the music industry. The company in 2012 had only existed 6 years and had already had over 15 million active users and over 4 million paying. [Now] ”.

Alistair Cockburn (one of the founding fathers of agile software development) visited Spotify and said “Nice I've been looking for someone to implement this matrix format since 1992 :) so it is really welcome to see.”

Agile Scaling Teams in a Matrix Model

The matrix model developed by Spotify[3] has been successfully adjusted to align with the specific TTC needs and guarantees achieving the below:

quick decision making and shorter time-to-market (by coherent small group targeting project goals in squads),
possibility of building big, complex products consistently and with minimum waste of time and resources (multiple squads form platform dev team),
optimised choice of technology (by chapters supporting squads with their expertise),
mitigated conflicts of interests between business and technology by squad and chapter dimensions,
reducing risks related to single points of failure (SPOFs) and keeping productive level of redundancy (by chapters and pair programming),
efficient propagation of knowledge and best practices among the project teams (by chapters and TPM support).

For the clarity, the rest of the description will rely on following base assumptions, such as:

teams build, change and maintain Platforms and integrated Systems,
the larger planned changes are tackled in operations: Projects or their groups, Programmes,
projects require decomposition to smaller, allowing short-term delivery pieces of change requests, raised in ticket of tasks, stories or spikes.

The financial goals as costs and measured/projected revenue declare goals that shape technology targets. The targets depending on granularity can be achieved in operations as per project delivery live-cycle or directly, more tactically by platform teams directly in software delivery live-cycle.

Squad as a Smallest Delivery Unit

The basic unit of the development team is a squad.

A squad is a minimal, sustainable group that can deliver a project work in a platform. A squad will typically have 4-5 people with overlapping skillsets, e.g. 2 FE developers + 2 BE developers + QA + PO + BA (in case of Full-Stack teams the optimal size is at least 3 developers + 1 QA).

Radar chart presenting skills distribution and overlap by skills' matrix T-shape profile of skills blocks and their development as per career path plan.

Thanks to the skills overlap the squads avail of wider set of competences, which in turns results in higher quality of work, e.g. efficient pair reviews, increased room for creativity and knowledge sharing. Additionally, this set up secures resources allocated to the project (e.g. annual or sick leaves) and thus guarantees timely delivery of the scope agreed.

Squads should be kept as small as possible. This will help to avoid antipatterns [**] related to information bloat due to explosion of relations and direct communication lines in teams sized above 7 people. As the squads are small, they can work in an open, informal way and thus enhance speed of communication, decision-making and delivery of the results.

Each squad is focused on a long-term mission and responsible for delivering clearly stated results within a product or a project (or in fact: the whole project), e.g. building a new website for a brand, building a new important product capability or completing software stabilisation. As the squad members can focus on one mission or product for as long time as needed to deliver the projects, they become real experts in their fields. This remarkably lessens the waste caused by the need of onboarding developers, QAs or BAs to the project they are allocated to. It's also important to note here that while working on the project, the squad strives for maintaining visibility and a conduct of practice with other squads.

The squads can be divided into two types, depending on the type of work they are doing:

Project squads - they are allocated to projects according to Strategic Planning process.
BAU squads - has a long-term mission of backing up project squads within the same platform team, so they are protected from the context-switch effect.

Scaled Management

Team of people need leadership. In order to scale squads into the larger teams we need to review some of well defined management roles such as: Product Owners (POs), Product Managers (PMs) and Technology Managers (TMs).

Everyday work of a squad is overseen by Product Owner (PO) who is responsible for the following:

creating and clearly communicating product backlog,
ordering and prioritization of the backlog items,
ensuring that the product backlog is transparent, visible and understood,
developing and explicitly communicating the product goals that are aligned with Strategic Planning and active projects,
manages direct allocation of particular tasks to the squad team members when necessary and consulted with TM (see BAU work),
reporting and delivering value for the business.

In other words, the PO decides what is done by the development squad, however not how it’s done. Of course, in case of two or more squads working on the same or related product or functionality, there will occur natural dependencies. To address them, facilitate communication and ensure sufficient allocation of resources, such squads are organised into platforms, e.g. customer-facing platform or utility platform.

A platform team can be made up of two or more squads working on a platform. If the dependencies impact the pace of delivery, there are a number of options available to handle the situation, e.g. reviewing of priorities, amending the platform team members’ allocation, making changes in architecture or other technical solutions.

A platform stability is overseen by Technical Manager (TM), who is responsible for both, technology and people, and specifically: line management to the technical staff of the platform teams, resource planning for squads, allocating developers to projects, managing rotation between squads, accepting holidays, managing OOH duties, ensure roadmaps and stakeholder expectations are managed defining requirements of QA/QE allocation for a project/BAU squad, organising/reorganising the work of a platform team, choosing the optimal technical solutions applied in their platform, checking platform stability including security standards, defining non-functional requirements, setting technical deployment standards.

The TM is responsible for the platform on the tactical level and makes sure the squads have the right environment to do their work. However, TM should not organise day-to-day tasks of the dev team nor impose the methodology in which the squads work. Also, the Product Owners do not report to TMs, but to their managers, typically associated closer with the business needs. Both roles are absolutely critical to prepare well-defined goals and backlog of work for the dev team by providing required alignment between the business needs (PO) and technical stability of the platform and team career paths (TM).

Some of the needs expressed by the business stakeholders may be in conflict with each other. Additionally, the TM and the PO may present their own requirements. It is the PO's duty to work out such a vision of the backlog that will give the best possible alignment with all the needs. For this to happen, it is essential that the PO and the TM cooperate closely and directly and negotiate the priority of needs. Such negotiations, well executed in trust and respect, are also key elements of the duty.

Product Manager (PM) is a role in that allows for good alignment between the realms of technology and business, especially in larger operation where many platforms require a change. A person in this role: overlooks the work of all the POs in the given platform, will typically act as a PO for one of the squads and conducts analysis of the most complex requirements (this allows the PM to be still in touch with the realities, needs and day-to-day challenges of the team), acts on the strategic level and shapes the product roadmap - together with the senior business management, other TMs and POs, cooperates very closely with the TM of the platform.

It's worth looking a bit closer at how the roles of a TM and PO complete each other:

* TMs are experts in the field of technology, and they will make the decisions regarding the architecture of the platform. They are also responsible for the team members' allocation and their career growth.

* POs need to possess a good deal of a technical understanding, but responsibilities gravitate towards Business. That means that they will have a wider view on the new, emerging or planned initiatives within the platform and will negotiate with the business under supervision of Technology Director any big functional changes to be introduced. Tight cooperation between PO and TPM will allow for efficient planning of the work and squad allocations within the platform.

Literature

[1] Fowler, Martin, and Jim Highsmith. "The agile manifesto." Software development 9.8 (2001): 28-35. -- https://agilemanifesto.org/

[2] Poppendieck, Mary, and Tom Poppendieck. "Lean software development: An agile toolkit:" Addison-Wesley, 2003.

[3] Kniberg, Henrik, and Anders Ivarsson. "Scaling agile@ spotify."UCVOF (2012). -- agileleanhouse.com/HenrikKniberg/SpotifyScaling.pdf