diff --git a/docs/devops-practices/continuous-planning/agile-development/retrospectives.md b/docs/devops-practices/continuous-planning/agile-development/retrospectives.md index 45bbd3f..6844d80 100644 --- a/docs/devops-practices/continuous-planning/agile-development/retrospectives.md +++ b/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) \ No newline at end of file +- [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) diff --git a/docs/devops-practices/continuous-planning/agile-development/scrum-of-scrums.md b/docs/devops-practices/continuous-planning/agile-development/scrum-of-scrums.md index 3d7af74..31f7a13 100644 --- a/docs/devops-practices/continuous-planning/agile-development/scrum-of-scrums.md +++ b/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 diff --git a/docs/devops-practices/continuous-planning/agile-development/sprint-planning.md b/docs/devops-practices/continuous-planning/agile-development/sprint-planning.md index 9f59bb6..7a04451 100644 --- a/docs/devops-practices/continuous-planning/agile-development/sprint-planning.md +++ b/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. diff --git a/docs/devops-practices/continuous-planning/agile-development/stand-ups.md b/docs/devops-practices/continuous-planning/agile-development/stand-ups.md index b895324..7bbfcee 100644 --- a/docs/devops-practices/continuous-planning/agile-development/stand-ups.md +++ b/docs/devops-practices/continuous-planning/agile-development/stand-ups.md @@ -1,11 +1,13 @@ # Stand-ups +## Overview + The stand-up is a time-boxed ceremony that is held each day of the sprint. In this ceremony, each contributor in the Development Team will answer three simple project questions and an optional social question. This will repeat until each contributor has answered the following questions. 1. What did you work on yesterday that contributes to meet the sprint goal? 2. What are you working on today that will contribute to meet the sprint goal? 3. Do you have any impediments/blockers or need any help? (defer discussion / resolution to "the parking lot", described below) -4. An [optional social question](/Continuous-Planning/Agile-Development/Stand-Ups/Social-Question.md), e.g. "would you rather see the past or the future?" +4. An [optional social question](/continuous-planning/agile-development/stand-ups/social-question.md), e.g. "would you rather see the past or the future?" During the stand-up, additional discussions may arise. Make sure that someone adds them to the parking lot for after meeting discussion. @@ -26,7 +28,7 @@ The participation in the parking lot discussion is optional for all members exce The entire team should attend the stand-up. Anyone that worked on a task towards the sprint work should answer the three questions. It would be up to the team to decide if they would like updates from members that are not directly working against sprint task work (i.e. Product Owners and Program Managers). -- Process Lead (Required) +- ScrumMaster (Required) - Product Owner (Optional) - Program Manager (Required) - Dev Lead + Contributors (Required) @@ -65,7 +67,7 @@ How many tasks are being generated after the stand-up that didn't exist before? ## Facilitation Guidance -The Process Lead should facilitate the stand-up meeting. +The ScrumMaster should facilitate the stand-up meeting. ### Speak to Tasks @@ -88,7 +90,7 @@ Ensure discussion leaders call out necessary parties for their discussion points ### Social question -Teams are frequently geographically distributed and include members who have not worked on projects together previously. Social interactions facilitate the development of trust between team members and lower the barriers to collaboration. A social question-of-the-day that has a one-sentence answer contributes to trust development over the course of many stand-ups, with a minimal additional time commitment. The answer to the social question should be brief and follow the project questions answer. The facilitator may choose the social question or take a suggestion from the room. Description of what makes a good question, and a list of starter questions are available within the [social question](/Continuous-Planning/Agile-Development/Stand-Ups/Social-Question.md) page. +Teams are frequently geographically distributed and include members who have not worked on projects together previously. Social interactions facilitate the development of trust between team members and lower the barriers to collaboration. A social question-of-the-day that has a one-sentence answer contributes to trust development over the course of many stand-ups, with a minimal additional time commitment. The answer to the social question should be brief and follow the project questions answer. The facilitator may choose the social question or take a suggestion from the room. Description of what makes a good question, and a list of starter questions are available within the [social question](/continuous-planning/agile-development/stand-ups/social-question.md) page. ### Start On Time @@ -117,3 +119,4 @@ If any team member is working remotely, plan to run stand-ups through conference ## Resources - [Daily Scrum - Tips & Tactics](https://www.scrum.org/resources/blog/daily-scrum-tips-tactics) +- [Atlassian guide to Stand-ups](https://www.atlassian.com/agile/scrum/standups) diff --git a/docs/devops-practices/continuous-planning/agile-development/team-agreements.md b/docs/devops-practices/continuous-planning/agile-development/team-agreements.md index d11a327..b1cb1fc 100644 --- a/docs/devops-practices/continuous-planning/agile-development/team-agreements.md +++ b/docs/devops-practices/continuous-planning/agile-development/team-agreements.md @@ -1,12 +1,12 @@ # Team Agreements -## Sections within Team Agreements +## Overview -* [Definition of Done](./Team-Agreements/Definition-of-Done.md) -* [Definition of Ready](./Team-Agreements/Definition-of-Ready.md) -* [Working Agreements](./Team-Agreements/Working-Agreements.md) -* [Team Manifesto](./Team-Agreements/Team-Manifesto.md) +Team agreements help clarify expectations for all team members, whether they are expectations around how the team works together (Working Agreements) or how to judge if a story is complete (Definition of Done). -## Goals +## Sections within Team Agreements -Team agreements help clarify expectations for all team members, whether they are expectations around how the team works together (Working Agreements) or how to judge if a story is complete (Definition of Done). +- [Definition of Done](team-agreements/definition-of-done.md) +- [Definition of Ready](team-agreements/definition-of-ready.md) +- [Working Agreements](team-agreements/working-agreements.md) +- [Team Manifesto](team-agreements/team-manifesto.md) diff --git a/docs/devops-practices/continuous-planning/agile-development/team-agreements/Definition-of-Done.md b/docs/devops-practices/continuous-planning/agile-development/team-agreements/Definition-of-Done.md deleted file mode 100644 index 007980d..0000000 --- a/docs/devops-practices/continuous-planning/agile-development/team-agreements/Definition-of-Done.md +++ /dev/null @@ -1,34 +0,0 @@ -# Definition of Done - -To close a user story, a sprint, or a milestone it is important to verify that the tasks are complete. - -The development team should decide together what their Definition of Done is and document this in the project. Below are some examples of checks to verify that the user story, sprint, task is completed. - -## Feature/User Story - -- [ ] Acceptance criteria are met -- [ ] Refactoring is complete -- [ ] Code builds with no error -- [ ] Unit tests are written and pass -- [ ] Existing Unit Tests pass -- [ ] Sufficient diagnostics/telemetry are logged -- [ ] Code review is complete -- [ ] UX review is complete (if applicable) -- [ ] Documentation is updated -- [ ] The feature is merged into the develop branch -- [ ] The feature is signed off by the product owner - -## Sprint Goal - -- [ ] Definition of Done for all user stories included in the sprint are met -- [ ] Product backlog is updated -- [ ] Functional and Integration tests pass -- [ ] Performance tests pass -- [ ] End 2 End tests pass -- [ ] All bugs are fixed -- [ ] The sprint is signed off from developers, software architects, project manager, product owner etc. - -## Release/Milestone - -- [ ] Code Complete (goals of sprints are met) -- [ ] Release is marked as ready for production deployment by product owner diff --git a/docs/devops-practices/continuous-planning/agile-development/team-agreements/definition-of-done.md b/docs/devops-practices/continuous-planning/agile-development/team-agreements/definition-of-done.md new file mode 100644 index 0000000..15154e1 --- /dev/null +++ b/docs/devops-practices/continuous-planning/agile-development/team-agreements/definition-of-done.md @@ -0,0 +1,34 @@ +# Definition of Done + +To close a user story, a sprint, or a milestone it is important to verify that the tasks are complete. + +The development team should decide together what their Definition of Done is and document this in the project. Below are some examples of checks to verify that the user story, sprint, task is completed. + +## Feature/User Story + +- [ ] Acceptance criteria are met +- [ ] Refactoring is complete +- [ ] Code builds with no error +- [ ] Unit tests are written and pass +- [ ] Existing Unit Tests pass +- [ ] Sufficient diagnostics/telemetry are logged +- [ ] Code review is complete +- [ ] UX review is complete (if applicable) +- [ ] Documentation is updated +- [ ] The feature is merged into the develop branch +- [ ] The feature is signed off by the product owner + +## Sprint Goal + +- [ ] Definition of Done for all user stories included in the sprint are met +- [ ] Product backlog is updated +- [ ] Functional and Integration tests pass +- [ ] Performance tests pass +- [ ] End 2 End tests pass +- [ ] All bugs are fixed +- [ ] The sprint is signed off from developers, software architects, project manager, product owner etc. + +## Release/Milestone + +- [ ] Code Complete (goals of sprints are met) +- [ ] Release is marked as ready for production deployment by product owner diff --git a/docs/devops-practices/continuous-planning/agile-development/team-agreements/Definition-of-Ready.md b/docs/devops-practices/continuous-planning/agile-development/team-agreements/definition-of-ready.md similarity index 80% rename from docs/devops-practices/continuous-planning/agile-development/team-agreements/Definition-of-Ready.md rename to docs/devops-practices/continuous-planning/agile-development/team-agreements/definition-of-ready.md index 58140a3..ee505e4 100644 --- a/docs/devops-practices/continuous-planning/agile-development/team-agreements/Definition-of-Ready.md +++ b/docs/devops-practices/continuous-planning/agile-development/team-agreements/definition-of-ready.md @@ -6,9 +6,9 @@ When the development team picks a user story from the top of the backlog, the us ## What it is -*Definition of Ready* is the agreement made by the scrum team around how complete a user story should be in order to be selected as candidate for estimation in the sprint planning. These can be codified as a checklist in user stories using [Github Issue Templates](https://help.github.com/en/github/building-a-strong-community/configuring-issue-templates-for-your-repository) or [Azure DevOps Work Item Templates](https://docs.microsoft.com/en-us/azure/devops/boards/backlogs/work-item-template?view=azure-devops&tabs=browser). +*Definition of Ready* is the agreement made by the scrum team around how complete a user story should be in order to be selected as candidate for estimation in the sprint planning. These can be codified as a checklist in user stories. -It can be understood as a checklist that helps the Product Owner to ensure that the user story they wrote contains all the necessary details for the scrum team to understand the work to be done. +It can also be understood as a checklist that helps the Product Owner to ensure that the user story they wrote contains all the necessary details for the scrum team to understand the work to be done. ### Examples of ready checklist items @@ -23,7 +23,7 @@ It can be understood as a checklist that helps the Product Owner to ensure that ## Who writes it -The ready checklist can be written by a Product Owner in agreement with the development team and the Process Lead. +The ready checklist can be written by a Product Owner in agreement with the development team and the ScrumMaster. ## When should a Definition of Ready be updated diff --git a/docs/devops-practices/continuous-planning/agile-development/team-agreements/Team-Manifesto.md b/docs/devops-practices/continuous-planning/agile-development/team-agreements/team-charter.md similarity index 63% rename from docs/devops-practices/continuous-planning/agile-development/team-agreements/Team-Manifesto.md rename to docs/devops-practices/continuous-planning/agile-development/team-agreements/team-charter.md index 2fa4a98..c1aa4c8 100644 --- a/docs/devops-practices/continuous-planning/agile-development/team-agreements/Team-Manifesto.md +++ b/docs/devops-practices/continuous-planning/agile-development/team-agreements/team-charter.md @@ -1,36 +1,32 @@ -# Team Manifesto +# Team Charter -## Introduction +## Overview -CSE teams work with a new development team in each customer engagement which requires a phase of introduction & knowledge transfer before starting an engagement. - -Completion of this phase of ice-breakers and discussions about the standards takes time, but is required to start increasing the learning curve of the new team. - -A team manifesto is a light-weight one page agile document among team members which summarizes the basic principles and values of the team and aiming to provide a consensus about technical expectations from each team member in order to deliver high quality output at the end of each engagement. +A team charter is a light-weight one page agile document among team members which summarizes the basic principles and values of the team and aiming to provide a consensus about technical expectations from each team member in order to deliver high quality output at the end of each engagement. It aims to reduce the time on setting the right expectations without arranging longer "team document reading" meetings and provide a consensus among team members to answer the question - "How does the new team develop the software?" - by covering all engineering fundamentals and excellence topics such as release process, clean coding, testing. -Another main goal of writing the manifesto is to start a conversation during the "manifesto building session" to detect any differences of opinion around how the team should work. +Another main goal of writing the charter is to start a conversation during the "charter building session" to detect any differences of opinion around how the team should work. It also serves in the same way when a new team member joins to the team. New joiners can quickly get up to speed on the agreed standards. -## How to Build a Team Manifesto +## How to Build a Team Charter It can be said that the best time to start building it is at the very early phase of the engagement when teams meet with each other for swarming or during the preparation phase. -It is recommended to keep team manifesto as simple as possible, so preferably, one-page simple document which **doesn't include any references or links** is a nice format for it. +It is recommended to keep team charter as simple as possible, so preferably, one-page simple document which **doesn't include any references or links** is a nice format for it. If there is a need for providing knowledge on certain topics, the way to do is delivering brown-bag sessions, technical katas, team practices, documentations and others later on. -A few important points about the team manifesto +A few important points about the team charter -- The team manifesto is built by the development team itself +- The team charter is built by the development team itself - It should cover all required technical engineering points for the excellence as well as behavioral agility mindset items that the team finds relevant - It aims to give a common understanding about the desired expertise, practices and/or mindset within the team - Based on the needs of the team and retrospective results, it can be modified during the engagement. -In CSE, we aim for quality over quantity, and well-crafted software as well as to a comfortable/transparent environment where each team member can reach their highest potential. +We aim for quality over quantity, and well-crafted software as well as to a comfortable/transparent environment where each team member can reach their highest potential. -The difference between the team manifesto and other team documents is that it is used to give a short summary of expectations around the technical way of working and supported mindset in the team, before code-with sprints starts. +The difference between the team charter and other team documents is that it is used to give a short summary of expectations around the technical way of working and supported mindset in the team, before code-with sprints starts. Below, you can find some including, but not limited, topics many teams touch during engagements, @@ -62,10 +58,9 @@ Below, you can find some including, but not limited, topics many teams touch dur ## Tools -Generally team sessions are enough for building a manifesto and having a consensus around it, and if there is a need for improving it in a structured way, [Building a Team Manifesto](https://www.scrum.nl/blog/building-team-manifesto/) or any retrospective tool can be used. +Generally team sessions are enough for building a charter and having a consensus around it, and if there is a need for improving it in a structured way, [Building a Team charter](https://www.scrum.nl/blog/building-team-manifesto/) or any retrospective tool can be used. ## Resources -[Building a Team Manifesto*](https://www.scrum.nl/blog/building-team-manifesto/) - -[Technical Agility*](https://v46.scaledagileframework.com/team-and-technical-agility/) +- [Building a Team Charter](https://www.mindtools.com/pages/article/newTMM_95.htm) +- [What is a Team Charter, and How Can It Keep Your Team on Track?](https://v46.scaledagileframework.com/team-and-technical-agility/) diff --git a/docs/devops-practices/continuous-planning/agile-development/team-agreements/Working-Agreements.md b/docs/devops-practices/continuous-planning/agile-development/team-agreements/working-agreements.md similarity index 78% rename from docs/devops-practices/continuous-planning/agile-development/team-agreements/Working-Agreements.md rename to docs/devops-practices/continuous-planning/agile-development/team-agreements/working-agreements.md index ebbf1ba..5952a77 100644 --- a/docs/devops-practices/continuous-planning/agile-development/team-agreements/Working-Agreements.md +++ b/docs/devops-practices/continuous-planning/agile-development/team-agreements/working-agreements.md @@ -16,18 +16,18 @@ their own, and adjust times, communication channels, branch naming policies etc. - We show all team members equal respect - We work as a team to have common expectations for technical delivery that are documented in a [Team Manifesto](team-manifesto.md). - We make sure to spread our expertise and skills in the team, so no single person is relied on for one skill -- All times below are listed in CET +- All times below are listed in BST (*British Summer Time*) ## Communication - We communicate all information relevant to the team through the Project Teams channel -- We add all [technical spikes](../../design/design-reviews/recipes/technical-spike.md), [trade studies](../../design/design-reviews/trade-studies/README.md), and other technical documentation to the project repository through [async design reviews in PRs](../../design/design-reviews/recipes/async-design-reviews.md) +- We add all [technical spikes](../../design/design-reviews/recipes/technical-spike.md), [Design Reviews](../../design/design-reviews/trade-studies/README.md), and other technical documentation to the project repository through [async design reviews in PRs](../../design/design-reviews/recipes/async-design-reviews.md) ## Work-life Balance - Our office hours, when we can expect to collaborate via Microsoft Teams, phone or face-to-face are Monday to Friday 10AM - 5PM - We are not expected to answer emails past 6PM, on weekends or when we are on holidays or vacation. -- We work in different time zones and respect this, especially when setting up recurring meetings. +- We work in different areas of the country and respect this, especially when setting up recurring meetings. - We record meetings when possible, so that team members who could not attend live can listen later. ## Quality and not Quantity @@ -39,19 +39,19 @@ their own, and adjust times, communication channels, branch naming policies etc. | Activity | When | Duration | Who | Accountable | Goal | |-|-|-|-|-|-| -| [Project Standup](../stand-ups/README.md) | Tue-Fri 9AM | 15 min | Everyone | Process Lead | What has been accomplished, next steps, blockers | +| [Project Standup](../stand-ups.md) | Tue-Fri 10AM | 15 min | Everyone | ScrumMaster | What has been accomplished, next steps, blockers | | Sprint Demo | Monday 9AM | 1 hour | Everyone | Dev Lead | Present work done and sign off on user story completion | | [Sprint Retro](../retrospectives.md) | Monday 10AM | 1 hour | Everyone | Process Lead | Dev Teams shares learnings and what can be improved | -| [Sprint Planning](../sprint-planning/README.md) | Monday 11AM | 1 hour | Everyone | PO | Size and plan user stories for the sprint | +| [Sprint Planning](../sprint-planning.md) | Monday 11AM | 1 hour | Everyone | PO | Size and plan user stories for the sprint | | Task Creation | After Sprint Planning | - | Dev Team | Dev Lead | Create tasks to clarify and determine velocity | -| [Backlog refinement](../backlog-management/backlog-refinement.md) | Wednesday 2PM | 1 hour | Dev Lead, PO | PO | Prepare for next sprint and ensure that stories are ready for next sprint. | +| [Backlog refinement](../backlog-management.md) | Wednesday 2PM | 1 hour | Dev Lead, PO | PO | Prepare for next sprint and ensure that stories are ready for next sprint. | ## Process Lead The Process Lead is responsible for leading any scrum or agile practices to enable the project to move forward. - Facilitate standup meetings and hold team accountable for attendance and participation. -- Keep the meeting moving as described in the [Project Standup](../stand-ups/README.md) page. +- Keep the meeting moving as described in the [Project Standup](../stand-ups.md) page. - Make sure all action items are documented and ensure each has an owner and a due date and tracks the open issues. - Notes as needed after planning / stand-ups. - Make sure that items are moved to the parking lot and ensure follow-up afterwards. @@ -75,9 +75,9 @@ The Process Lead is responsible for leading any scrum or agile practices to enab ## Code Management -- We follow the git flow branch naming convention for branches and identify the task number e.g. `feature/123-add-working-agreement` +- We follow the [GitOps](https://www.atlassian.com/git/tutorials/gitops) naming convention for branches and identify the task number e.g. `feature/123-add-working-agreement` - We merge all code into main branches through PRs -- All PRs are reviewed by one person from [Customer/Partner Name] and one from Microsoft (for knowledge transfer and to ensure code and security standards are met) +- All PRs are reviewed by at least two engineers - We always review existing PRs before starting work on a new task - We look through open PRs at the end of stand-up to make sure all PRs have reviewers. - We treat documentation as code and apply the same [standards to Markdown](../../code-reviews/recipes/markdown.md) as code diff --git a/mkdocs.yml b/mkdocs.yml index cdd3957..0d25d2c 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -1,17 +1,19 @@ ### --- SITE BASE CONFIG --- ### # Default values, taken from mkdocs_theme.yml -site_name: Devops Docs -site_url: https://niodus.github.io/devops-docs/ -language: en +site_name: Devops Docs +site_url: https://niodus.github.io/devops-docs/ +site_author: Scott McCarthy +repo_url: https://github.com/example/repository/ +language: en font: - text: Roboto - code: Roboto Mono - favicon: assets/favicon.png + text: Roboto + code: Roboto Mono + favicon: img/favicon.png icon: - logo: logo + logo: logo theme: - name: material + name: material # custom_dir: overrides # Not currently used features: @@ -83,7 +85,7 @@ nav: - Team Agreements: devops-practices/continuous-planning/agile-development/team-agreements.md - Tools: - - devops-tools/tools-overview.md + - Tools Overview: devops-tools/tools-overview.md - Learning: - devops-learning/learning-overview.md