Ppugliese at 12:20, 29 January 2024

2024-01-29T12:20:39Z

← Older revision		Revision as of 14:20, 29 January 2024
Line 32:		Line 32:
	* [[Minimise unnecessary complexity]]		* [[Minimise unnecessary complexity]]
	* [[Amplify Speed and Quality of Learning Cycles]]		* [[Amplify Speed and Quality of Learning Cycles]]
	* [[Product solution ~~architecture~~ is driven from within development teams]]		* [[Product solution design is driven from within development teams]]
	* [[Technical leaders as coaches, mentors and community leaders]]		* [[Technical leaders as coaches, mentors and community leaders]]
	* [[Architectural cohesion]]		* [[Architectural cohesion]]

Ppugliese: Created page with "NOTOC == 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 r..."

2024-01-23T23:52:32Z

Created page with "__NOTOC__ == 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 r..."

New page

__NOTOC__
== 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 architecture 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]]

Start small and scale success - Revision history

Ppugliese at 12:20, 29 January 2024