Scale only when you need to: Difference between revisions
Jump to navigation
Jump to search
(Created page with "__NOTOC__ == Description == If you need to scale, do it as little as possible. Before adding many teams, make sure that your first few teams are highly effective –– you might not even need to add additional teams. == Rationale == A story about a telecommunications company’s failing consumer cloud product turned around by going back to basics and applying a rigorous and evolutionary approach to scaling: * Initial situation. The product was developed by multiple s...") |
(refactored text) |
||
| Line 1: | Line 1: | ||
__NOTOC__ | __NOTOC__ | ||
== Description == | == Description == | ||
If you need to scale, do it as little as possible. Before adding | Assume that you do not need to scale your system of work until you can validate that you really need to. If you need to scale, do it as little as possible. Before adding more teams, make sure that your first few teams are highly effective –– you might not even need to add additional teams. | ||
== Rationale == | == Rationale == | ||
The goal of scaling is to scale the value of the outcome rather than the size of the development system (teams, processes, governance, roles, etc.). Most organisations are already carrying a great deal of "[[Accidental Complexity]]" and adding more teams and processes only exacerbates the situation. Before scaling, first optimise the system you already have and then only scale if it proves necessary. | |||
Here is an example from a telecommunications company’s failing consumer cloud product turned around by going back to basics and applying a rigorous and evolutionary approach to scaling: | |||
* Initial situation. The product was developed by multiple silo-based teams, each responsible for a different layer of the technical architecture (back-end, iOS client, Android client, Windows client etc.). This resulted in a long time to market for new versions (1-2 releases a year) because of the large amount of coordination overhead needed to make even modest changes. There was low customer satisfaction, indicated by low user retention rate and typically 1-2 star ratings in the App stores. In addition, there was low team morale and poor performance and reliability of the product. | * Initial situation. The product was developed by multiple silo-based teams, each responsible for a different layer of the technical architecture (back-end, iOS client, Android client, Windows client etc.). This resulted in a long time to market for new versions (1-2 releases a year) because of the large amount of coordination overhead needed to make even modest changes. There was low customer satisfaction, indicated by low user retention rate and typically 1-2 star ratings in the App stores. In addition, there was low team morale and poor performance and reliability of the product. | ||
Latest revision as of 17:14, 29 January 2024
Description
Assume that you do not need to scale your system of work until you can validate that you really need to. If you need to scale, do it as little as possible. Before adding more teams, make sure that your first few teams are highly effective –– you might not even need to add additional teams.
Rationale
The goal of scaling is to scale the value of the outcome rather than the size of the development system (teams, processes, governance, roles, etc.). Most organisations are already carrying a great deal of "Accidental Complexity" and adding more teams and processes only exacerbates the situation. Before scaling, first optimise the system you already have and then only scale if it proves necessary.
Here is an example from a telecommunications company’s failing consumer cloud product turned around by going back to basics and applying a rigorous and evolutionary approach to scaling:
- Initial situation. The product was developed by multiple silo-based teams, each responsible for a different layer of the technical architecture (back-end, iOS client, Android client, Windows client etc.). This resulted in a long time to market for new versions (1-2 releases a year) because of the large amount of coordination overhead needed to make even modest changes. There was low customer satisfaction, indicated by low user retention rate and typically 1-2 star ratings in the App stores. In addition, there was low team morale and poor performance and reliability of the product.
- What was changed? Starting with one team, the transition was made to feature teams. Each team had the skills necessary to develop across the full stack from front-end to back-end, focussed on a particular channel (iOS, Android, Windows etc.). A single product backlog was introduced across all teams. Each team was trained and coached for several sprints to support the rollout of excellent Scrum + key Scrum patterns + XP development practices. This gave the business unit the means to respond quickly to data on product quality and customer satisfaction and drive the product towards success.
- What happened? After 6 months, things had improved considerably: App store ratings improved from an average of 1-2 stars to 4-5 stars, there were more active users, team morale had improved and the product was awarded first place in a review of competitive consumer cloud products (including Dropbox).