Scaling Scrum - Revision history

Mmusij: /* See Also */

2018-11-28T06:36:29Z

Mmusij: /* Sprint Planning */

2018-11-26T02:00:07Z

Sprint Planning

← Older revision		Revision as of 02:00, 26 November 2018
Line 69:		Line 69:

	====Sprint Planning====		====Sprint Planning====
	Sprint planning is more or less the same as using Scrum with the separation being with "Topic 1: What" where all of the teams coming together to determine what they are going to work on.		Sprint planning is more or less the same as using Scrum with the separation being with ''"Topic 1: What"'' where all of the teams coming together to determine what they are going to work on.

	"Topic 2:How" sees the teams working independently to decompose how they are going to deliver the items chosen in Topic 1.		''"Topic 2:How"'' sees the teams working independently to decompose how they are going to deliver the items chosen in Topic 1.

	A common approach is to use "Big Room Planning" where all of the teams do their sprint planning in a large single room with several table groups formed for their respective working areas.		A common approach is to use "Big Room Planning" where all of the teams do their sprint planning in a large single room with several table groups formed for their respective working areas.

Mmusij: /* Sprint Planning */

2018-11-26T01:59:45Z

Sprint Planning

← Older revision		Revision as of 01:59, 26 November 2018
Line 69:		Line 69:

	====Sprint Planning====		====Sprint Planning====
	Sprint planning is more or less the same as using [[Scrum]] with the separation being with "Topic 1: What" where all of the teams coming together to determine what they are going to work on.		Sprint planning is more or less the same as using Scrum with the separation being with "Topic 1: What" where all of the teams coming together to determine what they are going to work on.

	"Topic 2:How" sees the teams working independently to decompose how they are going to deliver the items chosen in Topic 1.		"Topic 2:How" sees the teams working independently to decompose how they are going to deliver the items chosen in Topic 1.

Mmusij: /* Large Scale Scrum (LeSS) */

2018-11-26T01:59:29Z

Large Scale Scrum (LeSS)

← Older revision		Revision as of 01:59, 26 November 2018
Line 66:		Line 66:

	===Large Scale Scrum (LeSS)===		===Large Scale Scrum (LeSS)===
	The intention with LeSS is to model and expand on the existing [[Scrum Framework]] to enable multiple [[Scrum]] teams to work together with a minimal framework, which can be added to later.		The intention with LeSS is to model and expand on the existing [[Scrum Framework]] to enable multiple [[Scrum Framework\|Scrum]] teams to work together with a minimal framework, which can be added to later.

	====Sprint Planning====		====Sprint Planning====

Mmusij: /* Avoid Component Teams */

2018-11-26T01:59:05Z

Avoid Component Teams

← Older revision		Revision as of 01:59, 26 November 2018
Line 56:		Line 56:

	===Avoid Component Teams===		===Avoid Component Teams===
	Component teams tend to be siloed teams either by skillset or knowledge. These were used a lot in traditional project management approaches as means to organise a large number of people by skillset often modelling a layered system architecture.		Component teams tend to be siloed teams either by skillset or knowledge. These were used a lot in traditional project management approaches as a means to organise a large number of people by skillset often modelling a layered system architecture.

	Although this approach looks good on paper as an org chart of teams and skillsets they tend to form strong dependencies between each other and so features cannot be completed until each of the component teams have done their bit. This can encourage a segmented view of the product leading to poor performance and a disconnected user experience.		Although this approach looks good on paper as an org chart of teams and skillsets they tend to form strong dependencies between each other and so features cannot be completed until each of the component teams have done their bit. This can encourage a segmented view of the product leading to poor performance and a disconnected user experience.

Mmusij: /* Specialist Teams */

2018-11-26T01:58:44Z

Specialist Teams

← Older revision		Revision as of 01:58, 26 November 2018
Line 53:		Line 53:
	* '''Embedded''' in the feature team for a short period for a specialist to provide some dedicated assistance		* '''Embedded''' in the feature team for a short period for a specialist to provide some dedicated assistance
	* '''Consulting''' with the feature teams for ad-hoc requests to provide some advice of quick instruction		* '''Consulting''' with the feature teams for ad-hoc requests to provide some advice of quick instruction
	* '''Sub Contracted''' to work in the specialists team on a particular problem for the feature teams. This is usually rare, but when a number of specialists are needed to work on the same problem, then sub contracting that problem or feature to them can be useful. (N.B. Try not to use this too often as it can degenerate into component team behaviour and strong dependencies, which we want to avoid.)		* '''Sub Contracted''' to work in the specialists team on a particular problem for the feature teams. This is usually rare, but when a number of specialists are needed to work on the same problem, then sub contracting that problem or feature to them can be useful. (N.B. Try not to use this too often as it can degenerate into component team behaviour and develop strong dependencies, which we want to avoid.)

	===Avoid Component Teams===		===Avoid Component Teams===

Mmusij: /* Inter-Team */

2018-11-26T01:58:03Z

Inter-Team

← Older revision		Revision as of 01:58, 26 November 2018
Line 35:		Line 35:

	====Inter-Team====		====Inter-Team====
	Interestingly, self organising behaviour also happens between the teams as they determine what they are going to work on during [[Sprint Planning & Backlog Refinement\|Sprint Planning]], how they manage dependencies between teams and also how they coordinate their efforts towards a common goal.		Interestingly, self organising behaviour also happens between the teams as they determine what they are going to work on during [[Sprint Planning & Product Backlog Refinement\|Sprint Planning]], how they manage dependencies between teams and also how they coordinate their efforts towards a common goal.

	A good way to facilitate this inter-team interaction is to allow the teams to sit close to each other and reduce the distance between their interactions.		A good way to facilitate this inter-team interaction is to allow the teams to sit close to each other and reduce the distance between their interactions.

Mmusij: /* Cross Functional */

2018-11-26T01:57:40Z

Cross Functional

← Older revision		Revision as of 01:57, 26 November 2018
Line 26:		Line 26:

	===Cross Functional===		===Cross Functional===
	Just like regular [[Scrum]] teams, the intention is for each of our teams to be cross-functional so that they have all of the necessary skills within the team to be able to deliver a feature from a written ticket to a production ready delivered feature.		Just like regular [[Scrum Framework\|Scrum]] teams, the intention is for each of our teams to be cross-functional so that they have all of the necessary skills within the team to be able to deliver a feature from a written ticket to a production ready delivered feature.

	If all of the teams are cross functional in this way, then this will enable them to be autonomous and independent and not dependent on other teams or other skills that we get when we have those traditional silo teams.		If all of the teams are cross functional in this way, then this will enable them to be autonomous and independent and not dependent on other teams or other skills that we get when we have those traditional silo teams.

Mmusij at 01:57, 26 November 2018

2018-11-26T01:57:13Z

← Older revision		Revision as of 01:57, 26 November 2018
Line 61:		Line 61:

	The general guidance is to try to avoid using component teams when working in a scaled fashion and opt for cross-functional feature teams instead.		The general guidance is to try to avoid using component teams when working in a scaled fashion and opt for cross-functional feature teams instead.

			==Frameworks==
			There are several scaling frameworks around at the moment with the most popular ones being [http://less.works Larg Scale Scrum (LeSS)] and [https://www.scaledagileframework.com/ Scaled Agile Framework (SAFe)].

			===Large Scale Scrum (LeSS)===
			The intention with LeSS is to model and expand on the existing [[Scrum Framework]] to enable multiple [[Scrum]] teams to work together with a minimal framework, which can be added to later.

			====Sprint Planning====
			Sprint planning is more or less the same as using [[Scrum]] with the separation being with "Topic 1: What" where all of the teams coming together to determine what they are going to work on.

			"Topic 2:How" sees the teams working independently to decompose how they are going to deliver the items chosen in Topic 1.

			A common approach is to use "Big Room Planning" where all of the teams do their sprint planning in a large single room with several table groups formed for their respective working areas.

			====Daily Scrums====
			These are very similar to the Scrum framework and are often done in parallel, which allows team members to join other [[Daily Scrum]]s if needed.

			====Sprint Review====
			These are also very similar in format to the Scrum framework, although if a number of teams are working in the same area they may opt to demonstrate their work collectively. If the teams are working independently and on independent features then it is common to use a "Feature Bizaar" or "Feature Market Place" approach where each of the teams can demonstrate their wares and obtain feedback from stakeholders.

			====Sprint Retrospective====
			Unlike the other events, these are very much the same as when using the Scrum framework, in that, each team will do their own retrospective and inspect their processes to derive improvements. Each team has been on their own journey, and so it seems fitting that they should also do a retrospective on their own for their context.

			=====Overal Sprint Retrospective=====
			Although the [[Sprint Retrospective]]s are done independently, it still might be beneficial for the teams to learn from each others' insights and so a separate forum for them to learn from each other is part of the LeSS framework.

			===Scaled Agile Framework (SAFe)===
			The intention with SAFe is to provide an all encompassing scaled framework for the enterprise with all of the tools in the toolbox already. This tends to be adopted by large corporate organisations that have multiple programs that need to be coordinated.

			==See Also==
			* [http://less.works Larg Scale Scrum (LeSS)]
			* [https://www.scaledagileframework.com/ Scaled Agile Framework (SAFe)]

Mmusij at 01:39, 26 November 2018

2018-11-26T01:39:14Z

← Older revision		Revision as of 01:39, 26 November 2018
Line 24:		Line 24:

	This underpinning idea is to promote teams that are self-propelled, confident in their approaches, and also yielding accurate solutions that delight the customer. The leader or managers' roles are essentially to get out of the way and provide a supporting platform that allows the teams to realise their potential.		This underpinning idea is to promote teams that are self-propelled, confident in their approaches, and also yielding accurate solutions that delight the customer. The leader or managers' roles are essentially to get out of the way and provide a supporting platform that allows the teams to realise their potential.

			===Cross Functional===
			Just like regular [[Scrum]] teams, the intention is for each of our teams to be cross-functional so that they have all of the necessary skills within the team to be able to deliver a feature from a written ticket to a production ready delivered feature.

			If all of the teams are cross functional in this way, then this will enable them to be autonomous and independent and not dependent on other teams or other skills that we get when we have those traditional silo teams.

	===Self Organising Behaviour===		===Self Organising Behaviour===
Line 40:		Line 45:

	==Team Types==		==Team Types==
	===~~Cross Functional~~===		===Feature Teams===
	~~Just like regular [[Scrum]]~~ teams, the ~~intention is~~ for ~~each~~ of ~~our~~ teams to ~~be cross~~-~~functional so that they have all~~ of the ~~necessary skills within~~ the team to be ~~able~~ to ~~deliver~~ a ~~feature from~~ a ~~written ticket~~ to a ~~production ready delivered feature~~.		Feature teams are the "front line" teams that deliver features and are cross-functional, autonomous and independent.

			===Specialist Teams===
			From time to time the feature teams may need the assistance of specialists such as architects, DBAs or customer experience for example. These skills are not needed all of the time and so didn't make sense to include them on a full time basis in the feature teams. An alternative is to form a group or "team" of specialists that may work in several modes:

			* '''Embedded''' in the feature team for a short period for a specialist to provide some dedicated assistance
			* '''Consulting''' with the feature teams for ad-hoc requests to provide some advice of quick instruction
			* '''Sub Contracted''' to work in the specialists team on a particular problem for the feature teams. This is usually rare, but when a number of specialists are needed to work on the same problem, then sub contracting that problem or feature to them can be useful. (N.B. Try not to use this too often as it can degenerate into component team behaviour and strong dependencies, which we want to avoid.)

			===Avoid Component Teams===
			Component teams tend to be siloed teams either by skillset or knowledge. These were used a lot in traditional project management approaches as means to organise a large number of people by skillset often modelling a layered system architecture.

			Although this approach looks good on paper as an org chart of teams and skillsets they tend to form strong dependencies between each other and so features cannot be completed until each of the component teams have done their bit. This can encourage a segmented view of the product leading to poor performance and a disconnected user experience.

	~~If all of the~~ teams ~~are~~ cross functional ~~in this way, then this will enable them to be autonomous and independent and not dependent on other teams or other skills that we get when we have those traditional silo~~ teams.		The general guidance is to try to avoid using component teams when working in a scaled fashion and opt for cross-functional feature teams instead.

← Older revision		Revision as of 06:36, 28 November 2018
Line 93:		Line 93:
	* [http://less.works Larg Scale Scrum (LeSS)]		* [http://less.works Larg Scale Scrum (LeSS)]
	* [https://www.scaledagileframework.com/ Scaled Agile Framework (SAFe)]		* [https://www.scaledagileframework.com/ Scaled Agile Framework (SAFe)]

			==References==
			# Large Scale Scrum: More With LeSS, Addison Wesley Signature Series (Cohn), Larman C., Vodde B., 2017