Mob Programming - Revision history

Mmusij: /* Equipment Setup */

2018-12-21T23:35:38Z

Equipment Setup

← Older revision		Revision as of 23:35, 21 December 2018
Line 43:		Line 43:
	* 1 x board to host a [[Visualising The Flow\|Card or Task Board]]		* 1 x board to host a [[Visualising The Flow\|Card or Task Board]]
	* 1 x board to host a [[Story Mapping\|Story Map or Backlog]] if needed		* 1 x board to host a [[Story Mapping\|Story Map or Backlog]] if needed

			==Getting Started==
			When using this approach for the first time, it is recommended that teams build up from spending a few hours at first using Mob Programming and then extending the time spent collaborating together. This allows the team to get used to the format and also learn how to actively collaborate, share ideas and create a safe space for each other.

	==See Also==		==See Also==

Mmusij: /* One Driver & Multiple Navigators */

2018-12-21T23:33:49Z

One Driver & Multiple Navigators

← Older revision		Revision as of 23:33, 21 December 2018
Line 9:		Line 9:
	==One Driver & Multiple Navigators==		==One Driver & Multiple Navigators==
	The person with the keyboard is termed as the '''''Driver''''' and takes direction from the rest of the team who are the '''''Navigators''''' and do the thinking in the group.		The person with the keyboard is termed as the '''''Driver''''' and takes direction from the rest of the team who are the '''''Navigators''''' and do the thinking in the group.

			Every so often change the driver. A recommendation when first starting out is to set a timer for 5 minutes and switch drivers when the timer alarm sounds.

	If using this approach the temptation as a ''Driver'' to take control and be the only one doing the thinking, as this excludes the contributions from the rest of the team and also can place some stress on the driver to get the right answer in front of everyone else. To avoid the stress of coding in from of others use the ''Navigators'' to collaborate instead and pass instructions to the ''Driver'' on what to do. This also has the side benefit that even non coders can get a chance at writing some code with the support from the rest of the team.		If using this approach the temptation as a ''Driver'' to take control and be the only one doing the thinking, as this excludes the contributions from the rest of the team and also can place some stress on the driver to get the right answer in front of everyone else. To avoid the stress of coding in from of others use the ''Navigators'' to collaborate instead and pass instructions to the ''Driver'' on what to do. This also has the side benefit that even non coders can get a chance at writing some code with the support from the rest of the team.

Mmusij: /* Equipment Setup */

2018-12-21T23:31:47Z

Equipment Setup

← Older revision		Revision as of 23:31, 21 December 2018
Line 39:		Line 39:
	* 3 x large screens e.g. 84" LCD displays		* 3 x large screens e.g. 84" LCD displays
	* 1 x hand sanitizer		* 1 x hand sanitizer
	* 1 x board to host a [[Visualising ~~the~~ Flow\|Card or Task Board]]		* 1 x board to host a [[Visualising The Flow\|Card or Task Board]]
	* 1 x board to host a [[Story Mapping\|Story Map or Backlog]] if needed		* 1 x board to host a [[Story Mapping\|Story Map or Backlog]] if needed

Mmusij: /* Equipment Setup */

2018-12-21T23:30:56Z

Equipment Setup

← Older revision		Revision as of 23:30, 21 December 2018
Line 33:		Line 33:

	==Equipment Setup==		==Equipment Setup==
			Here is a basic setup for the equipment:
			* 1 x computer / laptop
			* 2 x keyboard
			* 2 x mice
			* 3 x large screens e.g. 84" LCD displays
			* 1 x hand sanitizer
			* 1 x board to host a [[Visualising the Flow\|Card or Task Board]]
			* 1 x board to host a [[Story Mapping\|Story Map or Backlog]] if needed

	==See Also==		==See Also==

Mmusij: /* No Meetings */

2018-12-21T23:27:54Z

No Meetings

← Older revision		Revision as of 23:27, 21 December 2018
Line 23:		Line 23:

	Also, when working on a feature with multiple perspectives, the team can also be thinking about how the product is shaping from a customers perspective and how the team can improve the way they are doing things, and so rather than have explicit [[Showcase]]s or [[Kaizen & Continuous Improvement]] sessions, the team perform a continuous and analogue appreciation of the product and their processes and continually update their approaches.		Also, when working on a feature with multiple perspectives, the team can also be thinking about how the product is shaping from a customers perspective and how the team can improve the way they are doing things, and so rather than have explicit [[Showcase]]s or [[Kaizen & Continuous Improvement]] sessions, the team perform a continuous and analogue appreciation of the product and their processes and continually update their approaches.

			==Attendees==
			Ideally we want all of a cross functional team in the room that can contribute to all perspectives of adding in a new feature into the product from concept to production. In addition to the team we might also want the [[Product Owner]] or similar who can work continuously with the team to represent the customers' needs and provide information to the team about which features are of higher priority than others, and what level of completion of the feature is appropriate for now.

			==At Scale==
			Working with multiple teams at the same time and managing dependencies is much easier when all of the teams are sat near each other and in an open collaborative space. Here teams can simply walk other to each other as dependencies or issues are discovered and begin to resolve them as they happen.

			In addition, teams can also coordinate their efforts and high level perspectives continuously in the shared environment.

	==Equipment Setup==		==Equipment Setup==

Mmusij: /* Multiple Perspectives */

2018-12-21T23:21:52Z

Multiple Perspectives

← Older revision		Revision as of 23:21, 21 December 2018
Line 18:		Line 18:

	It is quite normal to work on a feature at a time and so also work on all of the perspectives of that feature at the same time. This then leads to a holistic understanding in the team about the product and how the new feature fits into it.		It is quite normal to work on a feature at a time and so also work on all of the perspectives of that feature at the same time. This then leads to a holistic understanding in the team about the product and how the new feature fits into it.

			==No Meetings==
			The general idea is that all of the team are in the room collaborating at the same time on all perspectives of a new feature, and so with the continuous share knowledge that is being used and extended in the close team, everyone should already know the state of the work and what as a team they need to do next, and so there is no need for a [[Daily Standup]] for example.

			Also, when working on a feature with multiple perspectives, the team can also be thinking about how the product is shaping from a customers perspective and how the team can improve the way they are doing things, and so rather than have explicit [[Showcase]]s or [[Kaizen & Continuous Improvement]] sessions, the team perform a continuous and analogue appreciation of the product and their processes and continually update their approaches.

	==Equipment Setup==		==Equipment Setup==

Mmusij: /* One Driver & Multiple Navigators */

2018-12-21T23:15:01Z

One Driver & Multiple Navigators

← Older revision		Revision as of 23:15, 21 December 2018
Line 13:		Line 13:

	As ''Navigators'', try to focus on collaborating and helping the ''Driver'' by actively thinking as a group about a high level direction where the product needs to go and also a low level direction on what to do next simultaneously. As the next steps are done, we might learn something from them and so we can adjust the high level direction with the new knowledge. Similarly, having a higher level direction provides context and a way forwards for the next steps. Thinking of both high level and low level at the same time then allows these perspectives to compliment each other.		As ''Navigators'', try to focus on collaborating and helping the ''Driver'' by actively thinking as a group about a high level direction where the product needs to go and also a low level direction on what to do next simultaneously. As the next steps are done, we might learn something from them and so we can adjust the high level direction with the new knowledge. Similarly, having a higher level direction provides context and a way forwards for the next steps. Thinking of both high level and low level at the same time then allows these perspectives to compliment each other.

			==Multiple Perspectives==
			It can be easy to think that all the team are doing is just coding the feature and that ''Mob Programming'' is just an approach for software developers, but the idea is to have a holistic approach to the product as it is refined, and so incorporating other activities such as writing automated tests, deployment scrips, refining the customer experience, devising the user interface and even documentation should all be done in this way.

			It is quite normal to work on a feature at a time and so also work on all of the perspectives of that feature at the same time. This then leads to a holistic understanding in the team about the product and how the new feature fits into it.

	==Equipment Setup==		==Equipment Setup==

Mmusij: /* One Driver & Multiple Navigators */

2018-12-21T23:10:50Z

One Driver & Multiple Navigators

← Older revision		Revision as of 23:10, 21 December 2018
Line 8:		Line 8:

	==One Driver & Multiple Navigators==		==One Driver & Multiple Navigators==
	The person with the keyboard is termed as the ~~driver~~ and takes direction from the rest of the team		The person with the keyboard is termed as the '''''Driver''''' and takes direction from the rest of the team who are the '''''Navigators''''' and do the thinking in the group.

			If using this approach the temptation as a ''Driver'' to take control and be the only one doing the thinking, as this excludes the contributions from the rest of the team and also can place some stress on the driver to get the right answer in front of everyone else. To avoid the stress of coding in from of others use the ''Navigators'' to collaborate instead and pass instructions to the ''Driver'' on what to do. This also has the side benefit that even non coders can get a chance at writing some code with the support from the rest of the team.

			As ''Navigators'', try to focus on collaborating and helping the ''Driver'' by actively thinking as a group about a high level direction where the product needs to go and also a low level direction on what to do next simultaneously. As the next steps are done, we might learn something from them and so we can adjust the high level direction with the new knowledge. Similarly, having a higher level direction provides context and a way forwards for the next steps. Thinking of both high level and low level at the same time then allows these perspectives to compliment each other.

	==Equipment Setup==		==Equipment Setup==

Mmusij at 22:56, 21 December 2018

2018-12-21T22:56:45Z

← Older revision		Revision as of 22:56, 21 December 2018
Line 1:		Line 1:
	[[Category:Agile:Illustrations]][[Category:Agile]]		[[Category:Agile:Illustrations]][[Category:Agile:XP]][[Category:Agile]]
	[[File:Mob_Programming.jpg\|~~700px~~\|Scaling Scrum]]
			Mob programming is a practice devised by Woody Zuill where the whole team continuously work together over a single product and consider all aspects of the development approach from coding, user experience, testing, deploying and even documenting.

			The approach is very simple, in that, there is only one machine, two keyboards, two mice and a huge amount of screen real estate to share between the whole team who sit together and work to refine the product. The story goes that initially a team that Woody was working with experienced a production issue and so like most organisations they got all of the necessary people together in a room and hooked up a machine to try to figure out where the problem was and how to fix it. As the day went on they resolved the problem in their triage or war room, (apparently they had to change rooms every so often when other people had it booked,) and generated a lot of momentum through close collaboration with each other. At the end of the day, one of the participants asked the team if they would like to work this way all of the time, and this then paved the way for Mob Programming.

			[[File:Mob_Programming.jpg\|500px\|Scaling Scrum]]

			==One Driver & Multiple Navigators==
			The person with the keyboard is termed as the driver and takes direction from the rest of the team

			==Equipment Setup==


			==See Also==
			* [[Extreme Programming (XP)]]
			* [[Pair Programming]]

			==References==
			* Mob Programming: A Whole Team Approach, Zuill W, Meadows K, 2016
			* [https://www.youtube.com/watch?v=dVqUcNKVbYg A Day of Mob Programming 2016], youtube.com, accessed 22 December 2016

Mmusij: Created page with "Category:Agile:IllustrationsCategory:Agile Scaling Scrum"

2018-11-18T03:41:32Z

Created page with "Category:Agile:Illustrations Category:Agile 700px|Scaling Scrum"

New page

[[Category:Agile:Illustrations]][[Category:Agile]]
[[File:Mob_Programming.jpg|700px|Scaling Scrum]]