The Teams' Perspective - Revision history

Ppugliese at 21:18, 21 May 2024

2024-05-21T21:18:18Z

← Older revision		Revision as of 23:18, 21 May 2024
Line 162:		Line 162:
	*[[Maximise Team autonomy]]		*[[Maximise Team autonomy]]
	*[[Maximise team empowerment and localised decision making]]		*[[Maximise team empowerment and localised decision making]]
	*[[Favour Teams with broader Business Domain ~~Accountability~~]]		*[[Favour Teams with broader Business Domain Competence]]
	*[[Self-managed teams]]		*[[Self-managed teams]]
	*[[Self-managed Team of Teams]]		*[[Self-managed Team of Teams]]
Line 324:		Line 324:
	*[[Maximise Team autonomy]]		*[[Maximise Team autonomy]]
	* [[Favour Teams with broader Solution Accountability]]		* [[Favour Teams with broader Solution Accountability]]
	* [[Favour Teams with broader Business Domain ~~Accountability~~]]		* [[Favour Teams with broader Business Domain Competence]]

	*[[Maximise team empowerment and localised decision making]]		*[[Maximise team empowerment and localised decision making]]

Ppugliese at 21:17, 21 May 2024

2024-05-21T21:17:15Z

← Older revision		Revision as of 23:17, 21 May 2024
Line 66:		Line 66:
	* [[Maximise Team autonomy]]		* [[Maximise Team autonomy]]
	* [[Favour Teams with broader Solution Accountability]]		* [[Favour Teams with broader Solution Accountability]]
	* [[Favour Teams with broader Business Domain ~~Accountability~~]]		* [[Favour Teams with broader Business Domain Competence]]


Line 406:		Line 406:
	# Design the Product and team structures so that they align closely with the business and customer Value Stream.		# Design the Product and team structures so that they align closely with the business and customer Value Stream.
	#*[[Organise around value streams]]		#*[[Organise around value streams]]
	#*[[Favour Teams with broader Business Domain ~~Accountability~~]]		#*[[Favour Teams with broader Business Domain Competence]]
	# Optimise the team structures and skills mixture to minimise interdependencies with other teams whilst staying true to number 1.		# Optimise the team structures and skills mixture to minimise interdependencies with other teams whilst staying true to number 1.
	#*[[Maximise team empowerment and localised decision making]]		#*[[Maximise team empowerment and localised decision making]]

Ppugliese: /* Autonomous and Empowered */

2024-01-29T12:23:09Z

Autonomous and Empowered

← Older revision		Revision as of 14:23, 29 January 2024
Line 128:		Line 128:
	* [[Support autonomy with clear boundaries]]		* [[Support autonomy with clear boundaries]]
	* [[Leadership supports rather than drives the work]]		* [[Leadership supports rather than drives the work]]
	* [[Product solution ~~architecture~~ is driven from within development teams]]		* [[Product solution design is driven from within development teams]]
	* [[Maximise engagement]]		* [[Maximise engagement]]
	* [[Maximise Team autonomy]]		* [[Maximise Team autonomy]]
Line 193:		Line 193:
	* [[Maximise Team autonomy]]		* [[Maximise Team autonomy]]
	* [[Cultivate learning between teams]]		* [[Cultivate learning between teams]]
	* [[Product solution ~~architecture~~ is driven from within development teams]]		* [[Product solution design is driven from within development teams]]
	* [[Create a Learning Organisation]]		* [[Create a Learning Organisation]]

Line 333:		Line 333:
	* [[Collective responsibility for complete product development]]		* [[Collective responsibility for complete product development]]
	*[[Support autonomy with clear boundaries]]		*[[Support autonomy with clear boundaries]]
	* [[Product solution ~~architecture~~ is driven from within development teams]]		* [[Product solution design is driven from within development teams]]
	*[[Invest in quality]]		*[[Invest in quality]]

Line 412:		Line 412:
	#*[[Favour teams with maximised cognitive diversity]]		#*[[Favour teams with maximised cognitive diversity]]
	# Avoid external subject matter experts injecting design decisions into teams. This requires that the team membership includes the relevant competencies and has the authority to emerge design from within the team.		# Avoid external subject matter experts injecting design decisions into teams. This requires that the team membership includes the relevant competencies and has the authority to emerge design from within the team.
	#*[[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]]

Ppugliese: /* Optimise a Single Team */

2024-01-24T07:45:15Z

Optimise a Single Team

← Older revision		Revision as of 09:45, 24 January 2024
Line 261:		Line 261:

	=== Optimise a Single Team ===		=== Optimise a Single Team ===
	Before moving to a multi-team scaled model, first, implement options to improve the delivery capabilities of the single team. This strategy will result in increased value delivery by the team and additionally provide valuable empirical data on which to base the decision on the need to scale beyond a single team.		Before moving to a multi-team scaled model, first, implement options to improve the delivery capabilities of the single team. This strategy will result in increased value delivery by the team and additionally provide valuable empirical data on which to base the decision on the need to scale beyond a single team.

	However, in many cases, it is necessary to have several teams collaborate on the same product development. For example, the complexity and diversity of the technical or business domains may exceed the cognitive capabilities of a single small team.		However, in many cases, it is necessary to have several teams collaborate on the same product development. For example, the complexity and diversity of the technical or business domains may exceed the cognitive capabilities of a single small team.

Ppugliese at 07:16, 24 January 2024

2024-01-24T07:16:29Z

← Older revision		Revision as of 09:16, 24 January 2024
Line 315:		Line 315:
	* While knowledgeable Teams can develop end-to-end parts of a solution independently, they still need to integrate their contributions. This problem also exists for Component Teams, but in the case of Feature Teams, the probability of colliding changes is higher because they are more likely to apply changes in the same places as other teams. How problematic this is in practice depends on how the development is organised. In software, for example, there are several practices and technologies that help to reduce this issue a lot: continuous integration/continuous delivery, modern development tools, collective code ownership, ..., so that for properly organised software development, this point is de facto irrelevant (though the investment many companies have to do to reach that point is huge!) In other disciplines, your mileage might vary. The section on [[Craft]] describes several options.		* While knowledgeable Teams can develop end-to-end parts of a solution independently, they still need to integrate their contributions. This problem also exists for Component Teams, but in the case of Feature Teams, the probability of colliding changes is higher because they are more likely to apply changes in the same places as other teams. How problematic this is in practice depends on how the development is organised. In software, for example, there are several practices and technologies that help to reduce this issue a lot: continuous integration/continuous delivery, modern development tools, collective code ownership, ..., so that for properly organised software development, this point is de facto irrelevant (though the investment many companies have to do to reach that point is huge!) In other disciplines, your mileage might vary. The section on [[Craft]] describes several options.

	We suggest this option is the preferred one, though sometimes, in very large product development, Component Teams may have to be considered as part of the team model design. If you are including Component Teams, we suggest to keep looking for ways to implement more and more Feature Teams and optimise towards the relevant ~~ScaleAgility~~ principles.		We suggest this option is the preferred one, though sometimes, in very large product development, Component Teams may have to be considered as part of the team model design. If you are including Component Teams, we suggest to keep looking for ways to implement more and more Feature Teams and optimise towards the relevant ELSE principles.

	''Related Principles:''		''Related Principles:''
Line 476:		Line 476:
	* Although boundary constraints define the limit of team and Value Stream autonomy, they are open to challenge whenever they appear to impede value flow.		* Although boundary constraints define the limit of team and Value Stream autonomy, they are open to challenge whenever they appear to impede value flow.
	*Maximise learning within and between teams - the value of your teams is in their knowledge and capabilities!		*Maximise learning within and between teams - the value of your teams is in their knowledge and capabilities!
	*Continuously evolve your team structures and models of collaboration using the ~~ScaleAgility~~ Principles as a guide.		*Continuously evolve your team structures and models of collaboration using the ELSE Principles as a guide.

Ppugliese: Created page with "NOTOC == Introduction == “In the long history of humankind (and animal kind, too) that those who learned to collaborate and improvise most effectively have prevailed.” – Charles Darwin The evolutionary pressure in the world has never been more volatile and uncertain. Surviving and thriving requires organisations to respond rapidly, adapt and navigate complex challenges. An Agile organisation addresses these challenges by nurturing and supporting Agile teams..."

2024-01-23T23:37:27Z

Created page with "__NOTOC__ == Introduction == “In the long history of humankind (and animal kind, too) that those who learned to collaborate and improvise most effectively have prevailed.” – Charles Darwin The evolutionary pressure in the world has never been more volatile and uncertain. Surviving and thriving requires organisations to respond rapidly, adapt and navigate complex challenges. An Agile organisation addresses these challenges by nurturing and supporting Agile teams..."

Show changes