update to Working Team Agreement pages

docs/devops-practices/continuous-planning/agile-development/retrospectives.md

@@ -1,8 +1,8 @@
 # Retrospectives
 
-Development teams working on [CPT](/Who-We-Are.md) projects will conduct [agile retrospectives](https://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649) for each iteration and project milestone.
+## What is an Agile retrospective?
 
-## Goals
+An Agile retrospective is a meeting that's held at the end of an iteration in Agile software development. During the retrospective, the team reflects on what happened in the iteration and identifies actions for improvement going forward.  The aim of a retrospective is to:
 
 1. Continually learn from our engagement, improving our ability to deliver value to our customers.
 1. Involve everyone in the learning and improvement.
@@ -16,44 +16,24 @@ Proposed changes coming out of iteration retrospectives should be tracked as tas
 
 ## General Guidance
 
-The [*Agile Retrospectives*](https://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649) book provides a clear script for conducting retrospectives. Every retrospective should follow some version of the script, depending on the length of the retrospective. The basic script is:
+This [*Agile playbook by Atlassian*](https://www.atlassian.com/team-playbook/plays/retrospective) provides a clear script for conducting retrospectives. Every retrospective should follow some version of the script, depending on the length of the retrospective. The basic script is:
 
+1. Prep.
 1. Set the stage.
-1. Gather data.
-1. Generate insights.
-1. Decide what to do.
+1. What we did well.
+1. What we can do better .
+1. Actions.
 1. Close the retrospective.
 
-Within that script, the facilitator can make choices with regard to which activities to use for each element.
+Within that script, the facilitator can make choices with regard to which activities to use for each element.  If it suits your team you can even run different variations of a retrospective to suit different use cases such as:
 
 ### Project or Milestone Retrospective
 
-These are the most intense retrospectives, in that they cover more project working time and should be the strictest with regard to following the ceremony described in the retrospective book. The goal of most project or milestone retrospectives is to identify proposed changes that the engineering crew or all of [CPT](/Who-We-Are.md) might try in the next project. Teams should cover the overall project or milestone, including the development phase, how the on-site hack went, how well the customer engineering team engaged, how well the wrap up activities went, how well the whole [CPT](/Who-We-Are.md) team worked together, etc.
+These are the most intense retrospectives, in that they cover more project working time and should be the strictest with regard to following the ceremony described in the retrospective book. The goal of most project or milestone retrospectives is to identify proposed changes that the team might try in the next project. Teams should cover the overall project or milestone, including the development phase, how the on-site hack went, how well the customer engagement team did, how well the wrap up activities went, how well the whole project team worked together, etc.
 
-A project or milestone retrospective will usually take **3-4 hours**, depending on how long or complex the milestone was and how many people are involved in the retrospective.
+A project or milestone retrospective will usually take **3-4 hours**, depending on how long or complex the milestone was and how many people are involved in the retrospective
 
-We recommend that project and milestone retrospectives bring in an experienced facilitator to work with the team. [CPT](/Who-We-Are.md) will maintain a list of experienced facilitators for teams to request.
-
-1. Set the stage.
-    1. Thank everyone for being here.
-    1. Walk through the standard retrospective introduction slide deck, reminding everyone of the purpose, script, and expected behaviors.
-    1. Each participant introduces themselves and their role on the project.
-    1. Do one Set the Stage activity:
-    1. Run a quick Working Agreement activity to give participants a chance to add any items to the standard working agreement.
-1. Gather Data.
-    1. Run 2-3 Gather Data activities:
-    1. See the Recommended Activity Recipes section for ideas on selecting activities.
-1. Generate Insights
-    1. Run 1 Generate Insights activity:
-    1. See the Recommended Activity Recipes section for ideas on selecting activities.
-1. Decide What to Do
-    1. Run 1 Decide What to Do activity:
-    1. See the Recommended Activity Recipes section for ideas on selecting activities.
-1. Close the Retrospective.
-    1. Run 1 Close the Retrospective activity:
-    1. See the Recommended Activity Recipes section for ideas on selecting activities.
-    1. Thank everyone for participating.
-1. Follow up on proposed changes and experiments.
+It is recommended that due to the complexity of project level milestones it is recommended that you ensure you have an experienced facilitator to run this retrospective.
 
 ### Iteration Retrospective
 
@@ -63,56 +43,23 @@ An iteration retrospective will usually take **1-2 hours**.
 
 Usually, the Process Lead or Dev Lead will conduct the first one or two iteration retrospectives. After that, it's good for the team to take turns.
 
-1. Set the stage.
-    1. Run a quick Working Agreement activity to give participants a chance to add any items to the standard working agreement.
-    1. Do one Set the Stage activity:
-1. Gather Data / Generate Insights
-    1. Run 1 Gather Data or Generate Insights activity: Alternate between them on alternating iterations or let the facilitator choose the activity that they believe will be the most helpful.
-    1. See the recommended Activity Recipes section for ideas on selecting activities.
-1. Decide What to Do
-    1. Run 1 Decide What to Do activity:
-    1. See the recommended Activity Recipes section for ideas on selecting activities.
-1. Close the Retrospective
-    1. Make sure someone is responsible for adding the proposed changes and/or experiments to work item tracking.
-    1. Thank everyone for participating.
-
 ### Single-Day Iteration Retrospective
 
 This variation assumes that the team is running an iteration per day, which is common in code-with engagements or hacks that have higher levels of uncertainty. In a single-day sprint, the team runs a 15-30 minute planning session for the day, conducts at least one standup (frequently immediately after lunch), and has a short demo, followed by a short retrospective at the end of the day.
 
 A single-day iteration retrospective will usually take **15-30 minutes**.
 
-The Process Lead or Dev Lead will conduct these short retrospectives.
-
-1. Set the stage.
-    1. Remind everyone of the team's working agreement for daily retrospectives.
-    1. Give participants a chance to propose changes.
-    1. Do one Set the Stage activity:
-1. Activity
-    1. Run 1 activity from any section of the book.
-    1. The facilitator can choose based on they think the team could use.
-1. Decide What to Do
-    1. The team should decide if they want to make any change for the next day.
-1. Close the Retrospective
-    1. Make sure someone is responsible for adding the proposed changes and/or experiments to work item tracking.
-    1. Thank everyone for participating.
-
 ### Recommended Activity Recipes
 
 Below are recommended commendations of activities to use in the slots above.
 
-#### Tough Project Milestone
-
-Give participants a chance to vent before getting into the more analytical parts of the retrospective.
+### Tough Project Milestone
 
-1. Set the Stage: Check-in, using a more emotion-oriented question
-1. Gather Data: Mad Sad Glad to bring out emotional responses
-1. Gather Data: Timeline to move toward an analytical view
-1. Gather Data: Locate Strengths to help people move toward positive
-1. Generate Insights: Five Whys or Identify Themes to dig into thorny issues or find the underlying connections in the data
-1. Decide What to Do: SMART Goals to capture what the team wants to accomplish with proposed changes
-1. Close the Retrospective: Appreciations to give people the best chance of leaving with positive energy
+Typically used when you have just had a tough period and to give participants a chance to vent before getting into the more analytical parts of the retrospective.
 
 ## Resources
 
-* [*Agile Retrospectives: Making Good Teams Great*](https://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649)
+- [Agile Retrospectives: Making Good Teams Great](https://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649)
+- [Agile playbook by Atlassian](https://www.atlassian.com/team-playbook/plays/retrospective)
+- [Chatham House Rules](https://www.chathamhouse.org/about-us/chatham-house-rule)
+- [Scrum.org - what is a sprint retrospective](https://www.scrum.org/resources/what-is-a-sprint-retrospective)

docs/devops-practices/continuous-planning/agile-development/scrum-of-scrums.md

@@ -1,12 +1,14 @@
 # Scrum of Scrums
 
+## Overview
+
 Scrum of scrums is a technique used to scale Scrum to a larger group working towards the same project goal. In Scrum, we consider a team being too big when going over 10-12 individuals. This should be decided on a case by case basis. If the project is set up in multiple work streams that contain a fixed group of people and a common [stand-up](stand-ups.md) meeting is slowing down productivity: scrum of scrums should be considered. The team would identify the different subgroups that would act as a separate scrum teams with their own backlog, board and [stand-up](stand-ups.md).
 
 ## Goals
 
 The goal of the scrum of scrums ceremony is to give sub-teams the agility they need while not loosing visibility and coordination. It also helps to ensure that the sub-teams are achieving their sprint goals, and they are going in the right direction to achieve the overall project goal.
 
-The scrum of scrums ceremony happens every day and can be seen as a regular [stand-up](stand-ups.md):
+The scrum of scrums ceremony happens every day and can be seen as a regular stand-up:
 
 - What was done the day before by the sub-team.
 - What will be done today by the sub-team.
@@ -19,7 +21,7 @@ This list of impediments is usually managed in a separate [backlog](backlog-mana
 
 ## Participation
 
-The common guideline is to have on average one person per sub-team to participate in the scrum of scrums. Ideally, the Process Lead of each sub-team would represent them in this ceremony. In some instances, the representative for the day is selected at the end of each sub-team daily [stand-up](stand-ups.md) and could change every day. In practice, having a fixed representative tends to be more efficient in the long term.
+The common guideline is to have on average one person per sub-team to participate in the scrum of scrums. Ideally, the Process Lead of each sub-team would represent them in this ceremony. In some instances, the representative for the day is selected at the end of each sub-team daily stand-up and could change every day. In practice, having a fixed representative tends to be more efficient in the long term.
 
 ## Impact
 

docs/devops-practices/continuous-planning/agile-development/sprint-planning.md

@@ -1,10 +1,10 @@
 # Sprint Planning
 
-## Goals
+## Overview
 
 During the [sprint planning](https://www.agilealliance.org/glossary/sprint-planning), the team discusses and agrees on the scope for the upcoming sprint.
 
-Goals:
+## Goals
 
 - Select the **stories** that will be implemented in the sprint.
 - Estimate the **effort** required for the stories in the sprint.
@@ -22,30 +22,30 @@ General guidance:
 
 Specific roles:
 
-- Process Lead:
-  - Facilitate the conversation.
-  - Ensure everyone is heard.
-  - Remind scrums/agile/other principles and sprint planning goals if necessary, updating the working agreement where needed to ensure a mapping between principals and what is working/not working for the team.
-- [Product owner](https://www.agilealliance.org/glossary/product-owner/):
-  - Prior to the sprint planning: performs some [backlog refinement](/Continuous-Planning/Agile-Development/Backlog-Management/Backlog-Refinement.md) to ensure that each story that they want to propose for the new sprint (*) :
-
-    - Is in the correct position in the backlog, by right priority order.
-    - Is attending the [definition of ready](/Continuous-Planning/Agile-Development/Team-Agreements/Definition-of-Ready.md)
-  - Do NOT pre-assign stories to the future sprint. This is the purpose of the sprint planning.
-  - During the meeting:
+[**The ScrumMaster**](https://www.agilealliance.org/glossary/scrum-master/):
 
-    - Clarify team's questions and improve the story accordingly, if necessary.
-    - Describe to the team the stories that they propose for the sprint.
+- Facilitate the conversation.
+- Ensure everyone is heard.
+- Remind scrums/agile/other principles and sprint planning goals if necessary, updating the working agreement where needed to ensure a mapping between principals and what is working/not working for the team.
 
-- All team members:
+[**Product owner**](https://www.agilealliance.org/glossary/product-owner/):
+
+- Prior to the sprint planning: performs some [backlog refinement](/continuous-planning/agile-development/backlog-management/backlog-refinement.md) to ensure that each story that they want to propose for the new sprint (*)  
+- Is in the correct position in the backlog, by right priority order.
+- Is attending the [definition of ready](/continuous-planning/agile-development/team-agreements/definition-of-ready.md)- Do NOT pre-assign stories to the future sprint. This is the purpose of the sprint planning.
+- During the meeting:
+  - Clarify team's questions and improve the story accordingly, if necessary.
+  - Describe to the team the stories that they propose for the sprint.
+
+**All team members**:
 
-  - Listen to the product owner story description.
-  - Ask questions to make sure everyone understands each story properly.
-  - [Estimate](/Continuous-Planning/Agile-Development/Sprint-Planning/Estimation.md the effort for each backlog item, as a team.
-  - Split each story into tasks.
-  - (Optional) self assign first task to team members.
+- Listen to the product owner story description.
+- Ask questions to make sure everyone understands each story properly.
+- [Estimate](/continuous-planning/agile-development/sprint-planning/estimation.md) the effort for each backlog item, as a team.
+- Split each story into tasks.
+- (Optional) self assign first task to team members.
 
-*(\*) some teams find useful to define a **[Definition of ready](/Continuous-Planning/Agile-Development/Team-Agreements/Definition-of-Ready.md)** that describes the list of things that needs to be done in each story before the **product owner** can propose it for a **sprint**. The list proposed here is the classic minimal definition of ready.*
+*(\*) some teams find useful to define a **[Definition of ready](/continuous-planning/agile-development/team-agreements/definition-of-ready.md)** that describes the list of things that needs to be done in each story before the **product owner** can propose it for a **sprint**. The list proposed here is the classic minimal definition of ready.*
 
 ## Impact
 
@@ -68,7 +68,7 @@ Prior to the meeting:
 
 - Set sprint goal.
 - Make sure the backlog is prioritized.
-- Make sure each story that is a candidate for next sprint is [ready](/Continuous-Planning/Agile-Development/Team-Agreements/Definition-of-Ready.md).
+- Make sure each story that is a candidate for next sprint is [ready](/continuous-planning/agile-development/team-agreements/definition-of-ready.md).
 
 During the meeting:
 
@@ -81,5 +81,4 @@ During the meeting:
 Other considerations:
 
 - Take into account off days (vacations, national holidays, unavailability).
-- When the backlog reaches a size that makes it difficult to manage by one team, you might want to split into different work streams. This might require thinking about [scrum of scrums](/Continuous-Planning/Agile-Development/Scrum-of-Scrums.md) and all related ceremonies.
-- For Azure DevOps, leverage the [Sprint Goal](https://marketplace.visualstudio.com/items?itemName=keesschollaart.sprint-goal&targetId=e254bbbe-45a2-4344-9bbd-c4ba47e66719&utm_source=vstsproduct&utm_medium=ExtHubManageList) extension to display the goal in the tab-label on every page within the sprint.
+- When the backlog reaches a size that makes it difficult to manage by one team, you might want to split into different work streams. This might require thinking about [scrum of scrums](/continuous-planning/agile-development/scrum-of-scrums.md) and all related ceremonies.