Start small and scale success

Description

Start with a single team and grow in an evolutionary style, building on success rather than initiating the work with multiple teams in parallel. A great foundation can be established by a single team, practising collaborative group design, and building out an executable architecture focused on rapid learning and producing early value.

This principle primarily applies at a formative stage when there is still a choice as to whether scaling is required and before a given scaling approach is applied. However, the same priciple can be applied at later stages to change an existing scaled system of work.

Rationale

Starting small and organically growing the system of work:

Enables:

• Reduced coordination overhead to make rapid early progress and lower friction adaption of team processes and tools.
• A core team to evolve a coherent executable architecture collaboratively, gaining a collective understanding and ownership of the fundamental design assumptions and decisions.
• The establishment of appropriate engineering principles and practices to ensure rapid feedback loops to learn fast and sustain system-wide quality at scale.
• Just enough scaling: Grow the core team and split into multiple teams only if required, seeding them with a shared understanding of the design and the engineering practices.
• Evolution of effective and efficient inter-team collaboration as the teams expand.
• Reduced fear of change due to smaller, evidence-based evolutions to the design, organisational structures and ways of working.
• Failure as an option: Business cases can be proven non-viable without overcommiting to the cost of a scaled system of work.

Prevents:

• Scaling a mess!
• Unvalidated assumptions of the size and number of teams required as well as roles.
• Early commitment to unvalidated design assumptions driven by a need to share work across multiple teams.
• High levels of coordination overhead eating into teams’ capacity to deliver value and learn.
• Divergent and incoherent architectural decision-making arising from multiple teams having localised ownership and understanding of different aspects of the system.
• Integration challenges due to divergent design paradigms and the associated cost of workarounds and rewriting.

Related Principles

• Evolutionary over revolutionary change
• Scale only when you need to
• Minimise unnecessary complexity
• Amplify Speed and Quality of Learning Cycles
• Product solution design is driven from within development teams
• Technical leaders as coaches, mentors and community leaders
• Architectural cohesion
• Invest in quality
• Create a Learning Organisation
• Own your own approach
• Minimum Viable Product Owners
• Limit Product Owner Mental Workload
• Limit Team Mental Workload