From 2bc7fe7af1204b77dc223552033e5d1cb767e615 Mon Sep 17 00:00:00 2001 From: Tess Ferrandez Date: Wed, 14 Aug 2024 14:34:17 +0200 Subject: [PATCH 1/7] refactor agile --- docs/agile-development/README.md | 25 ++++++++++++++++--- docs/agile-development/basics/README.md | 10 -------- .../README.md => backlog-management.md} | 0 .../{Ceremonies/README.md => ceremonies.md} | 0 .../basics/{Roles/README.md => roles.md} | 0 .../basics/{Sprints/README.md => sprints.md} | 0 .../README.md => core-expectations.md} | 9 ------- .../accessibility.md} | 0 .../reliability.md} | 0 9 files changed, 21 insertions(+), 23 deletions(-) delete mode 100644 docs/agile-development/basics/README.md rename docs/agile-development/basics/{Backlog Management/README.md => backlog-management.md} (100%) rename docs/agile-development/basics/{Ceremonies/README.md => ceremonies.md} (100%) rename docs/agile-development/basics/{Roles/README.md => roles.md} (100%) rename docs/agile-development/basics/{Sprints/README.md => sprints.md} (100%) rename docs/agile-development/{core-expectations/README.md => core-expectations.md} (96%) rename docs/{accessibility/README.md => non-functional-requirements/accessibility.md} (100%) rename docs/{reliability/README.md => non-functional-requirements/reliability.md} (100%) diff --git a/docs/agile-development/README.md b/docs/agile-development/README.md index 5241df7b13..9d671f5587 100644 --- a/docs/agile-development/README.md +++ b/docs/agile-development/README.md @@ -1,5 +1,22 @@ -# Agile documentation +# Agile development -- [Agile Basics](./basics/README.md): Learn or refresh your basic agile knowledge. -- [Agile Core Expectations](./core-expectations/README.md): What are our core expectations from an Agile team. -- [Agile Advanced Topics](./advanced-topics/README.md): Go beyond the basics. +## Why + +- We want to be quick to respond to change +- We want to get to a state of working software fast, and iterate on it to improve it +- We want to keep the customer/end users involved all the way through +- We care about individuals and interactions over documents and processes + +## The fundamentals + +We care about the goal for each activity, but not necessarily about how they are accomplished. The suggestions in parenthesis are common ways to accomplish the goals. + +- We keep a shared backlog of work, that everyone in the team can always access (ex. Azure DevOps or GitHub) +- We plan our work in iterations with clear goals (ex. sprints) +- We have a clear idea of when work items are ready to implement (ex. definition of ready) +- We have a clear idea of when work items are completed (ex. definition of done) +- We communicate the progress in one place that everyone can access, and keep the progress up to date (ex. sprint board and daily standups) +- We reflect on our work regularly to make improvements (ex. retrospectives) +- The team has a clear idea of the roles in the project (ex. Dev lead, TPM, Process Lead etc.) +- The team has a joint idea of how we work together (ex. team agreement) +- We value and respect the opinions and work of all team members. diff --git a/docs/agile-development/basics/README.md b/docs/agile-development/basics/README.md deleted file mode 100644 index 44180ddc3a..0000000000 --- a/docs/agile-development/basics/README.md +++ /dev/null @@ -1,10 +0,0 @@ -# Agile Development Basics - -If you are new to Agile development or if you are looking for a refresher, this section will provides links to information that provide best pracices for Backlog Management, Agile Ceremonies, Roles within Agile and Agile Sprints. - -- [What is Agile](https://learn.microsoft.com/en-us/devops/plan/what-is-agile 'What is Agile') -- [What is Agile Development](https://learn.microsoft.com/en-us/devops/plan/what-is-agile-development 'What is Agile Development') -- [Backlog Management](./Backlog%20Management/README.md) -- [Ceremonies](./Ceremonies/README.md) -- [Roles](./Roles/README.md) -- [Sprints](./Sprints/README.md) diff --git a/docs/agile-development/basics/Backlog Management/README.md b/docs/agile-development/basics/backlog-management.md similarity index 100% rename from docs/agile-development/basics/Backlog Management/README.md rename to docs/agile-development/basics/backlog-management.md diff --git a/docs/agile-development/basics/Ceremonies/README.md b/docs/agile-development/basics/ceremonies.md similarity index 100% rename from docs/agile-development/basics/Ceremonies/README.md rename to docs/agile-development/basics/ceremonies.md diff --git a/docs/agile-development/basics/Roles/README.md b/docs/agile-development/basics/roles.md similarity index 100% rename from docs/agile-development/basics/Roles/README.md rename to docs/agile-development/basics/roles.md diff --git a/docs/agile-development/basics/Sprints/README.md b/docs/agile-development/basics/sprints.md similarity index 100% rename from docs/agile-development/basics/Sprints/README.md rename to docs/agile-development/basics/sprints.md diff --git a/docs/agile-development/core-expectations/README.md b/docs/agile-development/core-expectations.md similarity index 96% rename from docs/agile-development/core-expectations/README.md rename to docs/agile-development/core-expectations.md index c118f217eb..36bbf0d330 100644 --- a/docs/agile-development/core-expectations/README.md +++ b/docs/agile-development/core-expectations.md @@ -1,14 +1,5 @@ # Agile core expectations -This section contains core expectations for agile practices in ISE: - -- It should stay concise and link to external documentation for details. -- Each section contains a list of core expectations and suggestions: - - **Core expectations** are what each dev team is expected to aim for. - - **Suggestions** *are not* expectations. They are our learned experience for meeting those expectations, and can be adopted and modified to suit the project. - -**Notes:** - - We prefer the usage of "process lead" over "scrum master". It describes the same role. - **"Crew"**, in this document, refers to the entire team working on an project (dev team, dev lead, PM, etc.). - We follow Agile principles and usually [Scrum](https://www.scrum.org/resources/what-is-scrum) diff --git a/docs/accessibility/README.md b/docs/non-functional-requirements/accessibility.md similarity index 100% rename from docs/accessibility/README.md rename to docs/non-functional-requirements/accessibility.md diff --git a/docs/reliability/README.md b/docs/non-functional-requirements/reliability.md similarity index 100% rename from docs/reliability/README.md rename to docs/non-functional-requirements/reliability.md From 0af0ceb34d60bff1468a89ff9be61f8eb1ab29d0 Mon Sep 17 00:00:00 2001 From: Tess Ferrandez Date: Wed, 14 Aug 2024 15:24:27 +0200 Subject: [PATCH 2/7] refactor and clean up of the agile section --- docs/agile-development/README.md | 11 +- .../advanced-topics/README.md | 8 - .../backlog-management/README.md | 5 - .../advanced-topics/collaboration/README.md | 11 - .../collaboration/teaming-up.md | 4 +- .../collaboration/virtual-collaboration.md | 49 ++--- .../collaboration/why-collaboration.md | 3 - .../effective-organization/README.md | 4 - .../effective-organization/delivery-plan.md | 2 +- .../effective-organization/scrum-of-scrums.md | 12 +- .../advanced-topics/team-agreements/README.md | 10 - .../team-agreements/working-agreements.md | 16 +- .../basics/backlog-management.md | 12 + docs/agile-development/basics/ceremonies.md | 152 ++++++++++++- docs/agile-development/basics/roles.md | 2 + docs/agile-development/basics/sprints.md | 8 - docs/agile-development/core-expectations.md | 207 ------------------ 17 files changed, 210 insertions(+), 306 deletions(-) delete mode 100644 docs/agile-development/advanced-topics/README.md delete mode 100644 docs/agile-development/advanced-topics/backlog-management/README.md delete mode 100644 docs/agile-development/advanced-topics/collaboration/README.md delete mode 100644 docs/agile-development/advanced-topics/effective-organization/README.md delete mode 100644 docs/agile-development/advanced-topics/team-agreements/README.md delete mode 100644 docs/agile-development/basics/sprints.md diff --git a/docs/agile-development/README.md b/docs/agile-development/README.md index 9d671f5587..14d83a8139 100644 --- a/docs/agile-development/README.md +++ b/docs/agile-development/README.md @@ -1,6 +1,8 @@ # Agile development -## Why +In this documentation we refer to the team working on an engagement a **"Crew"**. This includes the dev team, dev lead, PM, data scientists, etc. + +## Why agile - We want to be quick to respond to change - We want to get to a state of working software fast, and iterate on it to improve it @@ -17,6 +19,11 @@ We care about the goal for each activity, but not necessarily about how they are - We have a clear idea of when work items are completed (ex. definition of done) - We communicate the progress in one place that everyone can access, and keep the progress up to date (ex. sprint board and daily standups) - We reflect on our work regularly to make improvements (ex. retrospectives) -- The team has a clear idea of the roles in the project (ex. Dev lead, TPM, Process Lead etc.) +- The team has a clear idea of the roles and responsibilities in the project (ex. Dev lead, TPM, Process Lead etc.) - The team has a joint idea of how we work together (ex. team agreement) - We value and respect the opinions and work of all team members. + +## Links + +- [What Is Scrum?](https://www.scrum.org/resources/what-is-scrum) +- [Essential Scrum: A Practical Guide to The Most Popular Agile Process](https://www.goodreads.com/book/show/13663747-essential-scrum) diff --git a/docs/agile-development/advanced-topics/README.md b/docs/agile-development/advanced-topics/README.md deleted file mode 100644 index 5dd3b42e4b..0000000000 --- a/docs/agile-development/advanced-topics/README.md +++ /dev/null @@ -1,8 +0,0 @@ -# Agile Development advanced topics - -Documentation that help you going beyond the basics and core expectations. - -- [Backlog Management](./backlog-management/README.md) -- [Collaboration](./collaboration/README.md) -- [Effective Organization](./effective-organization/README.md) -- [Team Agreements](./team-agreements/README.md) diff --git a/docs/agile-development/advanced-topics/backlog-management/README.md b/docs/agile-development/advanced-topics/backlog-management/README.md deleted file mode 100644 index f70f7ce95b..0000000000 --- a/docs/agile-development/advanced-topics/backlog-management/README.md +++ /dev/null @@ -1,5 +0,0 @@ -# Advanced recommendations for Backlog Management - -- [External Feedback](./external-feedback.md) -- [Minimal slices](./minimal-slices.md) -- [Risk Management](./risk-management.md) diff --git a/docs/agile-development/advanced-topics/collaboration/README.md b/docs/agile-development/advanced-topics/collaboration/README.md deleted file mode 100644 index 3bd18f8e1c..0000000000 --- a/docs/agile-development/advanced-topics/collaboration/README.md +++ /dev/null @@ -1,11 +0,0 @@ -# Advanced recommendations for collaboration - -- [Why Collaboration](./why-collaboration.md) -- [How to use the "Social Question of the Day"](./social-question.md) -- [Engagement Team Development](./teaming-up.md) - -## Pair and Swarm programming - -- [Virtual Collaboration and Pair Programming](./virtual-collaboration.md) -- [How to add a Pairing Custom Field in Azure DevOps User Stories](./add-pairing-field-azure-devops-cards.md) -- [Effortless Pair Programming with GitHub Codespaces and VSCode](./pair-programming-tools.md) diff --git a/docs/agile-development/advanced-topics/collaboration/teaming-up.md b/docs/agile-development/advanced-topics/collaboration/teaming-up.md index 0c07de1042..a08a0b6bee 100644 --- a/docs/agile-development/advanced-topics/collaboration/teaming-up.md +++ b/docs/agile-development/advanced-topics/collaboration/teaming-up.md @@ -15,7 +15,7 @@ Some potential steps in this phase may be as following (not limited): - [Working agreement](../team-agreements/working-agreements.md) - Identification of styles/preferences in communication, sharing, learning, decision making of each team member - + - Talking about necessity of pair programming - Decisions on backlog management & refinement meetings, weekly design sessions, social time sessions...etc. - Sync/Async communication methods, work hours/flexible times @@ -50,7 +50,7 @@ Just as an example, agility debugging activities may include: - Are Acceptance Criteria enough and right? - Is everyone ready-to-go after taking the User Story/Task? -- Running [Efficient Retrospectives](../../core-expectations/README.md) +- Running [Efficient Retrospectives](../../basics/ceremonies.md#retrospectives) - Is the Sprint Goal clear in every iteration ? diff --git a/docs/agile-development/advanced-topics/collaboration/virtual-collaboration.md b/docs/agile-development/advanced-topics/collaboration/virtual-collaboration.md index e08b276532..f6b199548e 100644 --- a/docs/agile-development/advanced-topics/collaboration/virtual-collaboration.md +++ b/docs/agile-development/advanced-topics/collaboration/virtual-collaboration.md @@ -7,8 +7,8 @@ Pair programming works well under the correct circumstances, but it loses some o Virtual work patterns are different from the in-person patterns we are accustomed to. Pair programming at its core is based on the following principles: 1. Generating clarity through communication -2. Producing higher quality through collaboration -3. Creating ownership through equal contribution +1. Producing higher quality through collaboration +1. Creating ownership through equal contribution Pair programming is one way to achieve these results. Red Team Testing (RTT) is an alternate programming method that uses the same principles but with some of the advantages that virtual work methods provide. @@ -23,19 +23,16 @@ Red Team Testing has the same philosophy as any other Test-Driven Development li ## Steps 1. Design Phase: Both developers design the interface together. This includes: - * Method signatures and names - * Writing documentation or docstrings for what the methods are intended to do. - * Architecture decisions that would influence testing (Factory patterns, etc.) - -2. Implementation Phase: The developers separate and parallelize work, while continuing to communicate. - * Developer A will design the implementation of the methods, adhering to the previously decided design. - * Developer B will concurrently write tests for the same method signatures, without knowing details of the implementation. - -3. Integration & Testing Phase: Both developers commit their code and run the tests. - * Utopian Scenario: All tests run and pass correctly. - * Realistic Scenario: The tests have either broken or failed due to flaws in testing. This leads to further clarification of the design and a discussion of why the tests failed. - -4. The developers will repeat the three phases until the code is functional and tested. + - Method signatures and names + - Writing documentation or docstrings for what the methods are intended to do. + - Architecture decisions that would influence testing (Factory patterns, etc.) +1. Implementation Phase: The developers separate and parallelize work, while continuing to communicate. + - Developer A will design the implementation of the methods, adhering to the previously decided design. + - Developer B will concurrently write tests for the same method signatures, without knowing details of the implementation. +1. Integration & Testing Phase: Both developers commit their code and run the tests. + - Utopian Scenario: All tests run and pass correctly. + - Realistic Scenario: The tests have either broken or failed due to flaws in testing. This leads to further clarification of the design and a discussion of why the tests failed. +1. The developers will repeat the three phases until the code is functional and tested. ## When to follow the RTT strategy @@ -47,20 +44,14 @@ RTT also works well when there is complete consensus, or no consensus at all, on RTT has many of the same benefits as Pair Programming and Test-Driven development but tries to update them for a virtual setting. -* Code implementation and testing can be done in parallel, over long distances or across time zones, which reduces the overall time taken to finish writing the code. - -* RTT maintains the pair programming paradigm, while reducing the need for video communication or constant communication between developers. - -* RTT allows detailed focus on design and engineering alignment before implementing any code, leading to cleaner and simpler interfaces. - -* RTT encourages testing to be prioritized alongside implementation, instead of having testing follow or be influenced by the implementation of the code. - -* Documentation is inherently a part of RTT, since both the implementer and the tester need correct, up to date documentation, in the implementation phase. +- Code implementation and testing can be done in parallel, over long distances or across time zones, which reduces the overall time taken to finish writing the code. +- RTT maintains the pair programming paradigm, while reducing the need for video communication or constant communication between developers. +- RTT allows detailed focus on design and engineering alignment before implementing any code, leading to cleaner and simpler interfaces. +- RTT encourages testing to be prioritized alongside implementation, instead of having testing follow or be influenced by the implementation of the code. +- Documentation is inherently a part of RTT, since both the implementer and the tester need correct, up to date documentation, in the implementation phase. ## What you need for RTT to work well -* Demand for constant communication and good teamwork may pose a challenge; daily updates amongst team members are essential to maintain alignment on varying code requirements. - -* Clarity of the code design and testing strategy must be established beforehand and documented as reference. Lack of an established design will cause misalignment between the two major pieces of work and a need for time-consuming refactoring. - -* RTT does not work well if only one developer has knowledge of the overall design. Team communication is critical to ensuring that every developer involved in RTT is on the same page. +- Demand for constant communication and good teamwork may pose a challenge; daily updates amongst team members are essential to maintain alignment on varying code requirements. +- Clarity of the code design and testing strategy must be established beforehand and documented as reference. Lack of an established design will cause misalignment between the two major pieces of work and a need for time-consuming refactoring. +- RTT does not work well if only one developer has knowledge of the overall design. Team communication is critical to ensuring that every developer involved in RTT is on the same page. diff --git a/docs/agile-development/advanced-topics/collaboration/why-collaboration.md b/docs/agile-development/advanced-topics/collaboration/why-collaboration.md index 33ae8f360d..b5905742ad 100644 --- a/docs/agile-development/advanced-topics/collaboration/why-collaboration.md +++ b/docs/agile-development/advanced-topics/collaboration/why-collaboration.md @@ -74,9 +74,6 @@ Knowledge sharing and bringing ISE and customer engineers together in a ‘code- ## Resources - [How to add a pairing custom field in Azure DevOps User Stories](./add-pairing-field-azure-devops-cards.md) - adding a custom field of type _Identity_ in Azure DevOps for pairing - - [On Pair Programming - Martin Fowler](https://martinfowler.com/articles/on-pair-programming.html) - - [Pair Programming hands-on lessons](https://github.com/The-V8/pair-programming-sessions) - these can be used (and adapted) to support bringing pair programming into your team (MS internal or including customers) - - [Effortless Pair Programming with GitHub Codespaces and VSCode](./pair-programming-tools.md) diff --git a/docs/agile-development/advanced-topics/effective-organization/README.md b/docs/agile-development/advanced-topics/effective-organization/README.md deleted file mode 100644 index 52b2144718..0000000000 --- a/docs/agile-development/advanced-topics/effective-organization/README.md +++ /dev/null @@ -1,4 +0,0 @@ -# Advanced recommendations for a more effective organization - -- [Delivery/Release plan](./delivery-plan.md) -- [Scrum of Scrum](./scrum-of-scrums.md) diff --git a/docs/agile-development/advanced-topics/effective-organization/delivery-plan.md b/docs/agile-development/advanced-topics/effective-organization/delivery-plan.md index 929f516d95..1d515e0341 100644 --- a/docs/agile-development/advanced-topics/effective-organization/delivery-plan.md +++ b/docs/agile-development/advanced-topics/effective-organization/delivery-plan.md @@ -22,7 +22,7 @@ One approach you can take to accomplish is with stickies and a spreadsheet. Step 1: Stack rank the features for everything in your backlog - Functional Features -- [Non-functional Features] (docs/TECH-LEADS-CHECKLIST.md) +- [Non-functional Features] (docs/non-functional-requirements) - User Research and Design - Testing - Documentation diff --git a/docs/agile-development/advanced-topics/effective-organization/scrum-of-scrums.md b/docs/agile-development/advanced-topics/effective-organization/scrum-of-scrums.md index 3bf17afa68..fb0b3c9155 100644 --- a/docs/agile-development/advanced-topics/effective-organization/scrum-of-scrums.md +++ b/docs/agile-development/advanced-topics/effective-organization/scrum-of-scrums.md @@ -1,12 +1,12 @@ # Scrum of Scrums -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](../../core-expectations/README.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](../../core-expectations/README.md). +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](../../basics/ceremonies.md#stand-up) 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. ## 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](../../core-expectations/README.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. @@ -15,11 +15,11 @@ The scrum of scrums ceremony happens every day and can be seen as a regular [sta The outcome of the meeting will result in a list of impediments related to coordination of the whole project. Solutions could be: agreeing on interfaces between teams, discussing architecture changes, evolving responsibility boundaries, etc. -This list of impediments is usually managed in a separate [backlog](../backlog-management/README.md) but does not have to. +This list of impediments is usually managed in a separate [backlog](../../basics/backlog-management.md) but does not have to. ## 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](../../core-expectations/README.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 @@ -29,8 +29,8 @@ When choosing to implement Scrum of Scrums, you need to keep in mind that some t ## Measures -The easiest way to measure the impact is by tracking the time to resolve issues in the scrum of scrums backlog. You can also track issues reported during the [retrospective](../../core-expectations/README.md) related to global coordination (is it well done? can it be improved?). +The easiest way to measure the impact is by tracking the time to resolve issues in the scrum of scrums backlog. You can also track issues reported during the [retrospective](../../basics/ceremonies.md#retrospectives) related to global coordination (is it well done? can it be improved?). ## Facilitation Guidance -This should be facilitated like a regular [stand-up](../../core-expectations/README.md). +This should be facilitated like a regular stand-up. diff --git a/docs/agile-development/advanced-topics/team-agreements/README.md b/docs/agile-development/advanced-topics/team-agreements/README.md deleted file mode 100644 index 723595772b..0000000000 --- a/docs/agile-development/advanced-topics/team-agreements/README.md +++ /dev/null @@ -1,10 +0,0 @@ -# Team Agreements - -* [Definition of Done](./definition-of-done.md) -* [Definition of Ready](./definition-of-ready.md) -* [Working Agreements](./working-agreements.md) -* [Team Manifesto](./team-manifesto.md) - -## Goals - -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). diff --git a/docs/agile-development/advanced-topics/team-agreements/working-agreements.md b/docs/agile-development/advanced-topics/team-agreements/working-agreements.md index 20e0e27745..9102bea4fa 100644 --- a/docs/agile-development/advanced-topics/team-agreements/working-agreements.md +++ b/docs/agile-development/advanced-topics/team-agreements/working-agreements.md @@ -37,21 +37,21 @@ their own, and adjust times, communication channels, branch naming policies etc. ## Scrum Rhythm -| Activity | When | Duration | Who | Accountable | Goal | -|-------------------------------------------------------|-----------------------|----------|--------------|--------------|----------------------------------------------------------------------------| -| [Project Standup](../../core-expectations/README.md) | Tue-Fri 9AM | 15 min | Everyone | Process Lead | What has been accomplished, next steps, blockers | +| Activity | When | Duration | Who | Accountable | Goal | +| -- | -- | -- | -- | -- | -- | +| Project Standup | Tue-Fri 9AM | 15 min | Everyone | Process Lead | 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](../../core-expectations/README.md) | Monday 10AM | 1 hour | Everyone | Process Lead | Dev Teams shares learnings and what can be improved | -| [Sprint Planning](../../core-expectations/README.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/README.md) | Wednesday 2PM | 1 hour | Dev Lead, PO | PO | Prepare for next sprint and ensure that stories are ready for next sprint. | +| Sprint Retro | Monday 10AM | 1 hour | Everyone | Process Lead | Dev Teams shares learnings and what can be improved | +| Sprint Planning | 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 | 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](../../core-expectations/README.md) page. +- Keep the meeting moving as described in the [Project Standup](../../basics/ceremonies.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. diff --git a/docs/agile-development/basics/backlog-management.md b/docs/agile-development/basics/backlog-management.md index f06a5c18e1..7dd6d50488 100644 --- a/docs/agile-development/basics/backlog-management.md +++ b/docs/agile-development/basics/backlog-management.md @@ -1,5 +1,17 @@ # Backlog Management basics for the Product and Sprint backlog +## Backlog + +- User stories have a clear acceptance criteria and definition of done. +- Design activities are planned as part of the backlog (a design for a story that needs it should be done before it is added in a Sprint). + +**Suggestions** + +- Consider the backlog refinement as an ongoing activity, that expands outside of the typical "Refinement meeting". +- Technical debt is mostly due to shortcuts made in the implementation as well as the future maintenance cost as the natural result of continuous improvement. Shortcuts should generally be avoided. In some rare instances where they happen, prioritizing and planning improvement activities to reduce this debt at a later time is the recommended approach. + +## Other + This section has links directing you to best practices for managing Product and Sprint backlogs. After reading through the best practices you should have a basic understanding for managing both product and sprint backlogs, how to create acceptance criteria for user stories, creating a definition of done and definition of ready for user stories and the basics around estimating user stories. - [Product Backlog](https://scrumguides.org/scrum-guide.html#product-backlog) diff --git a/docs/agile-development/basics/ceremonies.md b/docs/agile-development/basics/ceremonies.md index 0b44209f52..2a3a8d71ae 100644 --- a/docs/agile-development/basics/ceremonies.md +++ b/docs/agile-development/basics/ceremonies.md @@ -1,9 +1,157 @@ -# Agile Ceremonies basics +# Agile Ceremonies -This section has links directing you to best practices for conducting the Agile ceremonies. After reading through the best practices you should have a basic understanding of the key Agile ceremonies in terms of purpose, value and best practices around conducting and facilitating these ceremonies. +## Sprint planning +- The planning supports Diversity and Inclusion principles and provides equal opportunities. +- The Planning defines how the work is going to be completed in the sprint. +- Stories fit in a sprint and are [designed](https://github.com/microsoft/code-with-engineering-playbook/tree/main/docs/design/design-reviews) and [ready](../advanced-topics/team-agreements/definition-of-ready.md) before the planning. + +### Sprint goal + +Consider defining a sprint goal, or list of goals for each sprint. Effective sprint goals are a concise bullet point list of items. A Sprint goal can be created first and used as an input to choose the Stories for the sprint. A sprint goal could also be created from the list of stories that were picked for the Sprint. + +The sprint goal can be used: + +- At the end of each stand up meeting, to remember the north star for the Sprint and help everyone taking a step back +- *During the sprint review ("was the goal achieved?", "If not, why?") + +> Note: A simple way to define a sprint goal, is to create a User Story in each sprint backlog and name it "Sprint XX goal". You can add the bullet points in the description.* + +### Stories + +- Example 1 - Preparing in advance: + - The dev lead and product owner plan time to prepare the sprint backlog ahead of sprint planning. + - The dev lead uses their experience (past and on the current project) and the estimation made for these stories to gauge how many should be in the sprint. + - The dev lead asks the entire team to look at the tentative sprint backlog in advance of the sprint planning. + - The dev lead assigns stories to specific developers after confirming with them that it makes sense + - During the sprint planning meeting, the team reviews the sprint goal and the stories. Everyone confirm they understand the plan and feel it's reasonable. +- Example 2 - Building during the planning meeting: + - The product owner ensures that the highest priority items of the product backlog is refined and estimated following the team estimation process. + - During the Sprint planning meeting, the product owner describe each stories, one by one, starting by highest priority. + - For each story, the dev lead and the team confirm they understand what needs to be done and add the story to the sprint backlog. + - The team keeps considering more stories up to a point where they agree the sprint backlog is full. This should be informed by the estimation, past developer experience and past experience in this specific project. + - Stories are assigned during the planning meeting: + - Option 1: The dev lead makes suggestion on who could work on each stories. Each engineer agrees or discuss if required. + - Option 2: The team review each story and engineer volunteer select the one they want to be assigned to. (*Note*: this option might cause issues with the first core expectations. Who gets to work on what? Ultimately, it is the dev lead responsibility to ensure each engineer gets the opportunity to work on what makes sense for their growth.) + +### Tasks + +- Examples of approaches for task creation and assignment: + - Stories are split into tasks ahead of time by dev lead and assigned before/during sprint planning to engineers. + - Stories are assigned to more senior engineers who are responsible for splitting into tasks. + - Stories are split into tasks during the Sprint planning meeting by the entire team. + - *Note*: Depending on the seniority of the team, consider splitting into tasks before sprint planning. This can help getting out of sprint planning with all work assigned. It also increase clarity for junior engineers. + +### Sprint planning links + +- [Definition of Ready](../advanced-topics/team-agreements/definition-of-ready.md) +- [Sprint Goal Template](https://www.scrum.org/resources/blog/five-questions-sprint-goal) - [Planning](https://scrumguides.org/scrum-guide.html#sprint-planning 'Sprint Planning') - [Refinement](https://learn.microsoft.com/devops/plan/what-is-agile-development#diligent-backlog-refinement 'Refinement') +- [User Stories Applied: For Software Development](https://www.goodreads.com/book/show/3856.User_Stories_Applied) + +> Note: Self assignment by team members can give a feeling of fairness in how work is split in the team. Sometime, this ends up not being the case as it can give an advantage to the loudest or more experienced voices in the team. Individuals also tend to stay in their comfort zone, which might not be the right approach for their own growth.* + +## Estimation + +- Estimation supports the predictability of the team work and delivery. +- Estimation re-enforces the value of accountability to the team. +- The estimation process is improved over time and discussed on a regular basis. +- Estimation is inclusive of the different individuals in the team. + +**Suggestions** + +Rough estimation is usually done for a generic SE 2 dev. + +- Example 1 + - The team use t-shirt sizes (S, M, L, XL) and agrees in advance which size fits a sprint. + - In this example: S, M fits a sprint, L, XL too big for a sprint and need to be split / refined + - The dev lead with support of the team roughly estimates how much S and M stories can be done in the first sprints + - This rough estimation is refined over time and used to as an input for future sprint planning and to adjust project end date forecasting +- Example 2 + - The team uses a single indicator: "does this story fits in one sprint?", if not, the story needs to be split + - The dev lead with support of the team roughly estimates how many stories can be done in the first sprints + - How many stories are done in each sprint on average is used as an input for future sprint planning and as an indicator to adjust project end date forecasting +- Example 3 + - The team does planning poker and estimates in story points + - Story points are roughly used to estimate how much can be done in next sprint + - The dev lead and the TPM uses the past sprints and observed velocity to adjust project end date forecasting + +- Other considerations + - Estimating stories using story points in smaller project does not always provide the value it would in bigger ones. + - Avoid converting story points or t-shirt sizes to days. + - Measure estimation accuracy: + - Collect data to monitor estimation accuracy and sprint completion over time to drive improvements. + - Use the sprint goal to understand if the estimation was correct. If the sprint goal is met: does anything else matter? + - Scrum Practices: While Scrum does not prescribe how to size work, Professional Scrum is biased away from absolute estimation (hours, function points, ideal-days, etc.) and towards relative sizing. + - Planning Poker: is a collaborative technique to assign relative size. Developers may choose whatever units they want - story points and t-shirt sizes are examples of units. + - 'Same-Size' PBIs is a relative estimation approach that involves breaking items down small enough that they are roughly the same size. Velocity can be understood as a count of PBIs; this is sometimes used by teams doing continuously delivery. + - 'Right-Size' PBIs is a relative estimation approach that involves breaking things down small enough to deliver value in a certain time period (i.e. get to Done by the end of a Sprint). This is sometimes associated with teams utilizing flow for forecasting. Teams use historical data to determine if they think they can get the PBI done within the confidence level that their historical data says they typically get a PBI done. + +### Estimation links + +- [The Most Important Thing You Are Missing about Estimation](https://www.scrum.org/resources/blog/most-important-thing-you-are-missing-about-estimation) + +## Retrospectives + +- Retrospectives lead to actionable items that help grow the team's engineering practices. These items are in the backlog, assigned, and prioritized to be fixed by a date agreed upon (default being next retrospective). +- Is used to ask the hard questions ("we usually don't finish what we plan, let's talk about this") when necessary. + +**Suggestions** + +- Consider [other retro formats](https://www.goodreads.com/book/show/721338.Agile_Retrospectives) available outside of Mad Sad Glad. + - Gather Data: Triple Nickels, Timeline, Mad Sad Glad, Team Radar + - Generate Insights: 5 Whys, Fishbone, Patterns and Shifts +- Consider setting a retro focus area. +- Schedule enough time to ensure that you can have the conversation you need to get the correct plan an action and improve how you work. +- Bring in a neutral facilitator for project retros or retros that introspect after a difficult period. + +### Retrospective links + +- [Agile Retrospective: Making Good Teams Great](https://www.goodreads.com/book/show/721338.Agile_Retrospectives) - [Retrospective](https://scrumguides.org/scrum-guide.html#sprint-retrospective 'Retrospective') + +### Use the following retrospectives techniques to address specific trends that might be emerging on an engagement + +#### 5 whys + +If a team is confronting a problem and is unsure of the exact root cause, the 5 whys exercise taken from the business analysis sector can help get to the bottom of it. For example, if a team cannot get to *Done* each Sprint, that would go at the top of the whiteboard. The team then asks why that problem exists, writing that answer in the box below.  Next, the team asks why again, but this time in response to the *why* they just identified. Continue this process until the team identifies an actual root cause, which usually becomes apparent within five steps. + +#### Processes, tools, individuals, interactions and the Definition of Done + +This approach encourages team members to think more broadly.  Ask team members to identify what is going well and ideas for improvement within the categories of processes, tools, individuals/interactions, and the Definition of Done.  Then, ask team members to vote on which improvement ideas to focus on during the upcoming Sprint. + +#### Focus + +This retrospective technique incorporates the concept of visioning. Using this technique, you ask team members where they would like to go?  Decide what the team should look like in 4 weeks, and then ask what is holding them back from that and how they can resolve the impediment.  If you are focusing on specific improvements, you can use this technique for one or two Retrospectives in a row so that the team can see progress over time. + +## Sprint Demo + +- Each sprint has demos that illustrate the sprint goal and how it fits in the engagement goal. + +**Suggestions** + +- Consider not pre-recording sprint demos in advance. You can record the demo meeting and archive them. +- A demo does not have to be about running code. It can be showing documentation that was written. + +## Stand-up + +- The stand-up is run efficiently. +- The stand-up helps the team understand what was done, what will be done and what are the blockers. +- The stand-up helps the team understand if they will meet the sprint goal or not. + +**Suggestions** + +- Keep stand up short and efficient. Table the longer conversations for a parking lot section, or for a conversation that will be planned later. +- Run daily stand ups: 15 minutes of stand up and 15 minutes of parking lot. +- If someone cannot make the stand-up exceptionally: Ask them to do a written stand up in advance. +- Stand ups should include everyone involved in the project, including the customer. +- Projects with widely divergent time zones should be avoided if possible, but if you are on one, you should adapt the standups to meet the needs and time constraints of all team members. + +### Sprint demo links + - [Sprint Review/Demo](https://scrumguides.org/scrum-guide.html#sprint-review 'Sprint Review') + +### Stand-up links + - [Stand-Up/Daily Scrum](https://scrumguides.org/scrum-guide.html#daily-scrum 'Stand-up/Daily Scrum') diff --git a/docs/agile-development/basics/roles.md b/docs/agile-development/basics/roles.md index ecd0b1690b..477f66a125 100644 --- a/docs/agile-development/basics/roles.md +++ b/docs/agile-development/basics/roles.md @@ -1,5 +1,7 @@ # Agile/Scrum Roles +- We prefer the usage of "process lead" over "scrum master". It describes the same role. + This section has links directing you to definitions for the traditional roles within Agile/Scrum. After reading through the best practices you should have a basic understanding of the key Agile roles in terms of what they are and the expectations for the role. - [Product Owner](https://scrumguides.org/scrum-guide.html#product-owner 'Product Owner') diff --git a/docs/agile-development/basics/sprints.md b/docs/agile-development/basics/sprints.md deleted file mode 100644 index 0cae7dea95..0000000000 --- a/docs/agile-development/basics/sprints.md +++ /dev/null @@ -1,8 +0,0 @@ -# The Sprint - -This section has links directing you to best practices in regards to what a sprint is within agile and the practices around the sprint. After reading through the best practices you should have a basic understanding of Sprint Planning and the Sprint Backlog, Sprint Execution and the Daily Standup, Sprint Review and Sprint Retrospective and the key output of the sprint which is called the Increment. - -- [Sprint Planning and the Sprint Backlog](https://learn.microsoft.com/en-us/devops/plan/what-is-scrum#sprint-planning-and-the-sprint-backlog 'Sprint Planning and Sprint Backlog') -- [Sprint Execution and the Daily Standup](https://learn.microsoft.com/en-us/devops/plan/what-is-scrum#sprint-execution-and-daily-scrum 'Sprint Execution and the Daily Standup') -- [Sprint Review and Sprint Retrospective](https://learn.microsoft.com/en-us/devops/plan/what-is-scrum#sprint-review-and-sprint-retrospective 'Sprint Review and Sprint Retrospective') -- [Increment](https://learn.microsoft.com/en-us/devops/plan/what-is-scrum#increment 'Increment') diff --git a/docs/agile-development/core-expectations.md b/docs/agile-development/core-expectations.md index 36bbf0d330..4bd52fb758 100644 --- a/docs/agile-development/core-expectations.md +++ b/docs/agile-development/core-expectations.md @@ -1,211 +1,4 @@ # Agile core expectations -- We prefer the usage of "process lead" over "scrum master". It describes the same role. -- **"Crew"**, in this document, refers to the entire team working on an project (dev team, dev lead, PM, etc.). -- We follow Agile principles and usually [Scrum](https://www.scrum.org/resources/what-is-scrum) - -## Overall expectations for a project - -- The crew is predictable in their delivery. -- The crew makes relevant adjustments and shares these transparently. -- Roles and Responsibilities are clarified and agreed before the project starts. -- The crew is driving continuous improvement of their own process to meet the core expectations and increase project success. - -## Core expectations and suggestions - -### Sprints - -___ - -**Expectations:** - -- Sprint structure gives frequent opportunities for feedback and adjustment in the context of relatively small projects. -- Sprint ceremonies should be planned to accommodate working schedules of the team and take into consideration hard and soft time constraints. - -**Suggestions:** - -- Sprinting starts day 1: Game plan creation, game plan review and sharing are included in sprints and should be reflected in the backlog. -- Define a sprint goal that will be used to determine the success of the sprint. -- Note: Sprints are usually 1 week long to increase the number of opportunities for adjustments. And minimize the risk of missing the sprint goal. - -### Estimation - -___ - -**Expectations:** - -- Estimation supports the predictability of the team work and delivery. -- Estimation re-enforces the value of accountability to the team. -- The estimation process is improved over time and discussed on a regular basis. -- Estimation is inclusive of the different individuals in the team. - -**Suggestions:** -Rough estimation is usually done for a generic SE 2 dev. - -- Example 1 - - The team use t-shirt sizes (S, M, L, XL) and agrees in advance which size fits a sprint. - - In this example: S, M fits a sprint, L, XL too big for a sprint and need to be split / refined - - The dev lead with support of the team roughly estimates how much S and M stories can be done in the first sprints - - This rough estimation is refined over time and used to as an input for future sprint planning and to adjust project end date forecasting -- Example 2 - - The team uses a single indicator: "does this story fits in one sprint?", if not, the story needs to be split - - The dev lead with support of the team roughly estimates how many stories can be done in the first sprints - - How many stories are done in each sprint on average is used as an input for future sprint planning and as an indicator to adjust project end date forecasting -- Example 3 - - The team does planning poker and estimates in story points - - Story points are roughly used to estimate how much can be done in next sprint - - The dev lead and the TPM uses the past sprints and observed velocity to adjust project end date forecasting - -- Other considerations - - Estimating stories using story points in smaller project does not always provide the value it would in bigger ones. - - Avoid converting story points or t-shirt sizes to days. - - Measure estimation accuracy: - - Collect data to monitor estimation accuracy and sprint completion over time to drive improvements. - - Use the sprint goal to understand if the estimation was correct. If the sprint goal is met: does anything else matter? - - Scrum Practices: While Scrum does not prescribe how to size work, Professional Scrum is biased away from absolute estimation (hours, function points, ideal-days, etc.) and towards relative sizing. - - Planning Poker: is a collaborative technique to assign relative size. Developers may choose whatever units they want - story points and t-shirt sizes are examples of units. - - 'Same-Size' PBIs is a relative estimation approach that involves breaking items down small enough that they are roughly the same size. Velocity can be understood as a count of PBIs; this is sometimes used by teams doing continuously delivery. - - 'Right-Size' PBIs is a relative estimation approach that involves breaking things down small enough to deliver value in a certain time period (i.e. get to Done by the end of a Sprint). This is sometimes associated with teams utilizing flow for forecasting. Teams use historical data to determine if they think they can get the PBI done within the confidence level that their historical data says they typically get a PBI done. - -**Links:** - -- [The Most Important Thing You Are Missing about Estimation](https://www.scrum.org/resources/blog/most-important-thing-you-are-missing-about-estimation) - -### Sprint planning - -___ - -**Expectations:** - -- The planning supports Diversity and Inclusion principles and provides equal opportunities. -- The Planning defines how the work is going to be completed in the sprint. -- Stories fit in a sprint and are [designed](https://github.com/microsoft/code-with-engineering-playbook/tree/main/docs/design/design-reviews) and [ready](../advanced-topics/team-agreements/definition-of-ready.md) before the planning. - -**Suggestions:** - -**Sprint goal:** - -Consider defining a sprint goal, or list of goals for each sprint. Effective sprint goals are a concise bullet point list of items. A Sprint goal can be created first and used as an input to choose the Stories for the sprint. A sprint goal could also be created from the list of stories that were picked for the Sprint. - -The sprint goal can be used : - -- At the end of each stand up meeting, to remember the north star for the Sprint and help everyone taking a step back -- *During the sprint review ("was the goal achieved?", "If not, why?") - -*Note: A simple way to define a sprint goal, is to create a User Story in each sprint backlog and name it "Sprint XX goal". You can add the bullet points in the description.* - -**Stories:** - -- Example 1 - Preparing in advance: - - The dev lead and product owner plan time to prepare the sprint backlog ahead of sprint planning. - - The dev lead uses their experience (past and on the current project) and the estimation made for these stories to gauge how many should be in the sprint. - - The dev lead asks the entire team to look at the tentative sprint backlog in advance of the sprint planning. - - The dev lead assigns stories to specific developers after confirming with them that it makes sense - - During the sprint planning meeting, the team reviews the sprint goal and the stories. Everyone confirm they understand the plan and feel it's reasonable. -- Example 2 - Building during the planning meeting: - - The product owner ensures that the highest priority items of the product backlog is refined and estimated following the team estimation process. - - During the Sprint planning meeting, the product owner describe each stories, one by one, starting by highest priority. - - For each story, the dev lead and the team confirm they understand what needs to be done and add the story to the sprint backlog. - - The team keeps considering more stories up to a point where they agree the sprint backlog is full. This should be informed by the estimation, past developer experience and past experience in this specific project. - - Stories are assigned during the planning meeting: - - Option 1: The dev lead makes suggestion on who could work on each stories. Each engineer agrees or discuss if required. - - Option 2: The team review each story and engineer volunteer select the one they want to be assigned to. (*Note*: this option might cause issues with the first core expectations. Who gets to work on what? Ultimately, it is the dev lead responsibility to ensure each engineer gets the opportunity to work on what makes sense for their growth.) - -**Tasks:** - -- Examples of approaches for task creation and assignment: - - Stories are split into tasks ahead of time by dev lead and assigned before/during sprint planning to engineers. - - Stories are assigned to more senior engineers who are responsible for splitting into tasks. - - Stories are split into tasks during the Sprint planning meeting by the entire team. - - *Note*: Depending on the seniority of the team, consider splitting into tasks before sprint planning. This can help getting out of sprint planning with all work assigned. It also increase clarity for junior engineers. - -**Links:** - -- [Definition of Ready](../advanced-topics/team-agreements/definition-of-ready.md) -- [Sprint Goal Template](https://www.scrum.org/resources/blog/five-questions-sprint-goal) - -*Notes: Self assignment by team members can give a feeling of fairness in how work is split in the team. Sometime, this ends up not being the case as it can give an advantage to the loudest or more experienced voices in the team. Individuals also tend to stay in their comfort zone, which might not be the right approach for their own growth.* - -### Backlog - -___ - -**Expectations:** - -- User stories have a clear acceptance criteria and definition of done. -- Design activities are planned as part of the backlog (a design for a story that needs it should be done before it is added in a Sprint). - -**Suggestions:** - -- Consider the backlog refinement as an ongoing activity, that expands outside of the typical "Refinement meeting". -- Technical debt is mostly due to shortcuts made in the implementation as well as the future maintenance cost as the natural result of continuous improvement. Shortcuts should generally be avoided. In some rare instances where they happen, prioritizing and planning improvement activities to reduce this debt at a later time is the recommended approach. - -### Retrospectives - -___ - -**Expectations:** - -- Retrospectives lead to actionable items that help grow the team's engineering practices. These items are in the backlog, assigned, and prioritized to be fixed by a date agreed upon (default being next retrospective). -- Is used to ask the hard questions ("we usually don't finish what we plan, let's talk about this") when necessary. - -**Suggestions:** - -- Consider [other retro formats](https://www.goodreads.com/book/show/721338.Agile_Retrospectives) available outside of Mad Sad Glad. - - Gather Data: Triple Nickels, Timeline, Mad Sad Glad, Team Radar - - Generate Insights: 5 Whys, Fishbone, Patterns and Shifts -- Consider setting a retro focus area. -- Schedule enough time to ensure that you can have the conversation you need to get the correct plan an action and improve how you work. -- Bring in a neutral facilitator for project retros or retros that introspect after a difficult period. - -**Use the following retrospectives techniques to address specific trends that might be emerging on an engagement:** - -**5 whys:** - -If a team is confronting a problem and is unsure of the exact root cause, the 5 whys exercise taken from the business analysis sector can help get to the bottom of it. For example, if a team cannot get to *Done* each Sprint, that would go at the top of the whiteboard. The team then asks why that problem exists, writing that answer in the box below.  Next, the team asks why again, but this time in response to the *why* they just identified. Continue this process until the team identifies an actual root cause, which usually becomes apparent within five steps. - -**Processes, tools, individuals, interactions and the Definition of Done:** - -This approach encourages team members to think more broadly.  Ask team members to identify what is going well and ideas for improvement within the categories of processes, tools, individuals/interactions, and the Definition of Done.  Then, ask team members to vote on which improvement ideas to focus on during the upcoming Sprint. - -**Focus:** - -This retrospective technique incorporates the concept of visioning. Using this technique, you ask team members where they would like to go?  Decide what the team should look like in 4 weeks, and then ask what is holding them back from that and how they can resolve the impediment.  If you are focusing on specific improvements, you can use this technique for one or two Retrospectives in a row so that the team can see progress over time. - -### Sprint Demo - -___ - -**Expectations:** - -- Each sprint has demos that illustrate the sprint goal and how it fits in the engagement goal. - -**Suggestions:** - -- Consider not pre-recording sprint demos in advance. You can record the demo meeting and archive them. -- A demo does not have to be about running code. It can be showing documentation that was written. - -## Stand-up - -___ - -**Expectations:** - -- The stand-up is run efficiently. -- The stand-up helps the team understand what was done, what will be done and what are the blockers. -- The stand-up helps the team understand if they will meet the sprint goal or not. - -**Suggestions:** - -- Keep stand up short and efficient. Table the longer conversations for a parking lot section, or for a conversation that will be planned later. -- Run daily stand ups: 15 minutes of stand up and 15 minutes of parking lot. -- If someone cannot make the stand-up exceptionally: Ask them to do a written stand up in advance. -- Stand ups should include everyone involved in the project, including the customer. -- Projects with widely divergent time zones should be avoided if possible, but if you are on one, you should adapt the standups to meet the needs and time constraints of all team members. - ### Documentation -- [What Is Scrum?](https://www.scrum.org/resources/what-is-scrum) -- [Agile Retrospective: Making Good Teams Great](https://www.goodreads.com/book/show/721338.Agile_Retrospectives) -- [User Stories Applied: For Software Development](https://www.goodreads.com/book/show/3856.User_Stories_Applied) -- [Essential Scrum: A Practical Guide to The Most Popular Agile Process](https://www.goodreads.com/book/show/13663747-essential-scrum) From 59eaf6c3b6a0bc608820a942ee1eb544be78774d Mon Sep 17 00:00:00 2001 From: Tess Ferrandez Date: Thu, 15 Aug 2024 10:16:26 +0200 Subject: [PATCH 3/7] refactor and clean up of the agile section --- docs/non-functional-requirements/reliability.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/non-functional-requirements/reliability.md b/docs/non-functional-requirements/reliability.md index 13f8101c80..7f727e1251 100644 --- a/docs/non-functional-requirements/reliability.md +++ b/docs/non-functional-requirements/reliability.md @@ -64,7 +64,7 @@ We can build graceful failure (or graceful degradation) into our software stack * [Leader Election](https://en.wikipedia.org/wiki/Leader_election) can be used to keep healthy services on standby in case the leader experiences issues. * Entire cluster failover can redirect traffic to another region or availability zone. * Propagate downstream failures of **dependent services** up the stack via health checks, so that your ingress points can re-route to healthy services. -* [Circuit breakers](https://techblog.constantcontact.com/software-development/circuit-breakers-and-microservices/#:~:text=The%20Circuit%20breaker%20pattern%20helps,unavailable%20or%20have%20high%20latency.) can bail early on requests vs. propagating errors throughout the system. +* **Circuit breakers** can bail early on requests vs. propagating errors throughout the system. Consider using a well-known, tested library such as [Polly](https://github.com/App-vNext/Polly) (.NET) that enables configurable implementations of this and other common resilience and transient fault-handling patterns. ## Practice @@ -96,4 +96,4 @@ Leverage automated chaos testing to see how things break. You can read this play Writing up a [post-mortem](https://en.wikipedia.org/wiki/Postmortem_documentation) is a great way to document the root causes, and action items for your failures. They're also a great way to track recurring issues, and create a strong case for prioritizing fixes. -This can even be tied into your regular Agile [restrospectives](../agile-development/core-expectations/README.md). +This can even be tied into your regular Agile [restrospectives](../agile-development/basics/ceremonies.md#retrospectives). From 216a8d9aa6c599f54fe1be02d4f19dd323920279 Mon Sep 17 00:00:00 2001 From: Tess Ferrandez Date: Thu, 15 Aug 2024 10:23:50 +0200 Subject: [PATCH 4/7] fix agile links --- docs/SPRINT-STRUCTURE.md | 6 +++--- docs/design/design-reviews/recipes/engagement-process.md | 4 ++-- .../recipes/engineering-feasibility-spikes.md | 2 +- docs/machine-learning/ml-project-management.md | 8 ++++---- 4 files changed, 10 insertions(+), 10 deletions(-) diff --git a/docs/SPRINT-STRUCTURE.md b/docs/SPRINT-STRUCTURE.md index 76ac6cbd5e..0e5171acfc 100644 --- a/docs/SPRINT-STRUCTURE.md +++ b/docs/SPRINT-STRUCTURE.md @@ -14,7 +14,7 @@ The purpose of this document is to: - [Working Agreement](agile-development/advanced-topics/team-agreements/working-agreements.md) - [Definition of Ready](agile-development/advanced-topics/team-agreements/definition-of-ready.md) - [Definition of Done](agile-development/advanced-topics/team-agreements/definition-of-done.md) - - [Estimation](agile-development/core-expectations/README.md) + - [Estimation](agile-development/basics/ceremonies.md#estimation) - [ ] [Set up the repository/repositories](source-control/README.md#creating-a-new-repository) - Decide on repository structure/s - Add [README.md](resources/templates/README.md), [LICENSE](resources/templates/LICENSE), [CONTRIBUTING.md](resources/templates/CONTRIBUTING.md), .gitignore, etc @@ -25,7 +25,7 @@ The purpose of this document is to: ### Day 1 -- [ ] [Plan the first sprint](agile-development/core-expectations/README.md) +- [ ] [Plan the first sprint](agile-development/basics/ceremonies.md#sprint-planning) - Agree on a sprint goal, and how to measure the sprint progress - Determine team capacity - Assign user stories to the sprint and split user stories into tasks @@ -42,7 +42,7 @@ The purpose of this document is to: - [ ] [Set up Source Control](source-control/README.md) - Agree on [best practices for commits](source-control/git-guidance/README.md#commit-best-practices) - [ ] [Set up basic Continuous Integration with linters and automated tests](continuous-integration/README.md) -- [ ] [Set up meetings for Daily Stand-ups and decide on a Process Lead](agile-development/core-expectations/README.md) +- [ ] [Set up meetings for Daily Stand-ups and decide on a Process Lead](agile-development/basics/ceremonies.md#stand-up) - Discuss purpose, goals, participants and facilitation guidance - Discuss timing, and how to run an efficient stand-up - [ ] [If the project has sub-teams, set up a Scrum of Scrums](agile-development/advanced-topics/effective-organization/scrum-of-scrums.md) diff --git a/docs/design/design-reviews/recipes/engagement-process.md b/docs/design/design-reviews/recipes/engagement-process.md index e4f6a84484..4b4717b24d 100644 --- a/docs/design/design-reviews/recipes/engagement-process.md +++ b/docs/design/design-reviews/recipes/engagement-process.md @@ -21,7 +21,7 @@ During this time the team uncovers many unknowns, leveraging all new-found infor ## Sprint Planning -In many engagements Microsoft works with customers using a SCRUM agile development process which begins with sprint planning. [Sprint planning](../../../agile-development/core-expectations/README.md) is a great opportunity to dive deep into the next set of high priority work. Some key points to address are the following: +In many engagements Microsoft works with customers using a SCRUM agile development process which begins with sprint planning. [Sprint planning](../../../agile-development/basics/ceremonies.md#sprint-planning) is a great opportunity to dive deep into the next set of high priority work. Some key points to address are the following: 1. Identify stories that require design reviews 1. Separate design from implementation for complex stories @@ -48,7 +48,7 @@ The team can follow the same steps from [sprint planning](#sprint-planning) to h ## Sprint Retrospectives -[Sprint retrospectives](../../../agile-development/core-expectations/README.md) are a great time to check in with the dev team, identify what is working or not working, and propose changes to keep improving. +[Sprint retrospectives](../../../agile-development/basics/ceremonies.md#retrospectives) are a great time to check in with the dev team, identify what is working or not working, and propose changes to keep improving. It is also a great time to check in on design reviews diff --git a/docs/design/design-reviews/recipes/engineering-feasibility-spikes.md b/docs/design/design-reviews/recipes/engineering-feasibility-spikes.md index 84451cade4..cd7f226569 100644 --- a/docs/design/design-reviews/recipes/engineering-feasibility-spikes.md +++ b/docs/design/design-reviews/recipes/engineering-feasibility-spikes.md @@ -89,4 +89,4 @@ Conducting engineering feasibility spikes sets the team and the customer up for - The key purpose of the engineering feasibility spike is learning. - Learning comes from both conducting and sharing insights from spikes. - Use new spike infused learnings to revise, refine, re-prioritize, or create the next set of spikes. -- When spikes are completed, look for new weekly rhythms like adding a ‘risk’ column to the retro board or raising topics at [daily standup](../../../agile-development/core-expectations/README.md) to identify emerging risks. +- When spikes are completed, look for new weekly rhythms like adding a ‘risk’ column to the retro board or raising topics at [daily standup](../../../agile-development/basics/ceremonies.md#stand-up) to identify emerging risks. diff --git a/docs/machine-learning/ml-project-management.md b/docs/machine-learning/ml-project-management.md index 18ac570981..7087ea6683 100644 --- a/docs/machine-learning/ml-project-management.md +++ b/docs/machine-learning/ml-project-management.md @@ -14,17 +14,17 @@ To learn more about how ISE runs the Agile process for software development team Within this framework, the team follows these Agile ceremonies: - [Backlog management](../agile-development/advanced-topics/backlog-management/README.md) -- [Retrospectives](../agile-development/core-expectations/README.md) +- [Retrospectives](../agile-development/basics/ceremonies.md#retrospectives) - [Scrum of Scrums](../agile-development/advanced-topics/effective-organization/scrum-of-scrums.md) (where applicable) -- [Sprint planning](../agile-development/core-expectations/README.md) -- [Stand-ups](../agile-development/core-expectations/README.md) +- [Sprint planning](../agile-development/basics/ceremonies.md#sprint-planning) +- [Stand-ups](../agile-development/basics/ceremonies.md#stand-up) - [Working agreement](../agile-development/advanced-topics/team-agreements/working-agreements.md) ### Notes on Agile process during exploration and experimentation 1. While acknowledging the fact that ML user stories and research spikes are less predictable than software development ones, we strive to have a deliverable for every user story in every sprint. -2. User stories and spikes are usually estimated using [T-shirt sizes](../agile-development/core-expectations/README.md) or similar, and not in actual days/hours. See more [here](../agile-development/core-expectations/README.md) on story estimation. +2. User stories and spikes are usually estimated using [T-shirt sizes](../agile-development/basics/ceremonies.md#estimation) or similar, and not in actual days/hours. 3. ML design sessions should be included in each sprint. From afb025fd128216d7df1d19fc7e936f3591890c3f Mon Sep 17 00:00:00 2001 From: Tess Ferrandez Date: Thu, 15 Aug 2024 10:27:27 +0200 Subject: [PATCH 5/7] remove core expectations as all the content is moved to other places --- docs/agile-development/core-expectations.md | 4 ---- 1 file changed, 4 deletions(-) delete mode 100644 docs/agile-development/core-expectations.md diff --git a/docs/agile-development/core-expectations.md b/docs/agile-development/core-expectations.md deleted file mode 100644 index 4bd52fb758..0000000000 --- a/docs/agile-development/core-expectations.md +++ /dev/null @@ -1,4 +0,0 @@ -# Agile core expectations - -### Documentation - From e203e288faa05de8c77de91bb467b120fb858dc2 Mon Sep 17 00:00:00 2001 From: Tess Ferrandez Date: Thu, 15 Aug 2024 10:48:22 +0200 Subject: [PATCH 6/7] fix agile links --- docs/ENG-FUNDAMENTALS-CHECKLIST.md | 2 +- docs/SPRINT-STRUCTURE.md | 12 ++++++------ .../design-reviews/recipes/engagement-process.md | 2 +- .../recipes/engineering-feasibility-spikes.md | 2 +- docs/machine-learning/ml-project-management.md | 2 +- 5 files changed, 10 insertions(+), 10 deletions(-) diff --git a/docs/ENG-FUNDAMENTALS-CHECKLIST.md b/docs/ENG-FUNDAMENTALS-CHECKLIST.md index 76eca615cb..9a1ea69a73 100644 --- a/docs/ENG-FUNDAMENTALS-CHECKLIST.md +++ b/docs/ENG-FUNDAMENTALS-CHECKLIST.md @@ -97,7 +97,7 @@ More details on [code reviews](code-reviews/README.md) - [ ] Experiments have owners and are added to project backlog. - [ ] The team conducts longer retrospective for Milestones and project completion. -More details on [retrospectives](agile-development/core-expectations/README.md) +More details on [retrospectives](agile-development/basics/ceremonies.md#retrospectives) ## Engineering Feedback diff --git a/docs/SPRINT-STRUCTURE.md b/docs/SPRINT-STRUCTURE.md index 0e5171acfc..4433a1dd42 100644 --- a/docs/SPRINT-STRUCTURE.md +++ b/docs/SPRINT-STRUCTURE.md @@ -10,7 +10,7 @@ The purpose of this document is to: ### Before starting the project -- [ ] [Discuss and start writing the Team Agreements](agile-development/advanced-topics/team-agreements/README.md). Update these documents with any process decisions made throughout the project +- [ ] Discuss and start writing the Team Agreements. Update these documents with any process decisions made throughout the project - [Working Agreement](agile-development/advanced-topics/team-agreements/working-agreements.md) - [Definition of Ready](agile-development/advanced-topics/team-agreements/definition-of-ready.md) - [Definition of Done](agile-development/advanced-topics/team-agreements/definition-of-done.md) @@ -18,7 +18,7 @@ The purpose of this document is to: - [ ] [Set up the repository/repositories](source-control/README.md#creating-a-new-repository) - Decide on repository structure/s - Add [README.md](resources/templates/README.md), [LICENSE](resources/templates/LICENSE), [CONTRIBUTING.md](resources/templates/CONTRIBUTING.md), .gitignore, etc -- [ ] [Build a Product Backlog](agile-development/advanced-topics/backlog-management/README.md) +- [ ] [Build a Product Backlog](agile-development/advanced-topics/backlog-management) - Set up a project in your chosen project management tool (ex. Azure DevOps) - [INVEST](https://en.wikipedia.org/wiki/INVEST_(mnemonic)) in good User Stories and Acceptance Criteria - [Non-Functional Requirements Guidance](design/design-patterns/non-functional-requirements-capture-guide.md) @@ -64,12 +64,12 @@ The purpose of this document is to: ### Day 5 -- [ ] Conduct a Sprint Demo -- [ ] [Conduct a Retrospective](agile-development/core-expectations/README.md) +- [ ] Conduct a [Sprint Demo](agile-development/basics/ceremonies.md#sprint-demo) +- [ ] Conduct a [Retrospective](agile-development/basics/ceremonies.md#retrospectives) - Determine required participants, how to capture input (tools) and outcome - Set a timeline, and discuss facilitation, meeting structure etc. -- [ ] [Refine the Backlog](agile-development/advanced-topics/backlog-management/README.md) +- [ ] [Refine the Backlog](agile-development/advanced-topics/backlog-management) - Determine required participants - Update the [Definition of Ready](agile-development/advanced-topics/team-agreements/definition-of-ready.md) - - Update estimates, and the [Estimation](agile-development/core-expectations/README.md) document + - Update estimates, and the [Estimation](agile-development/basics/ceremonies.md#estimation) document - [ ] [Submit Engineering Feedback for issues encountered](engineering-feedback/README.md) diff --git a/docs/design/design-reviews/recipes/engagement-process.md b/docs/design/design-reviews/recipes/engagement-process.md index 4b4717b24d..68999861e7 100644 --- a/docs/design/design-reviews/recipes/engagement-process.md +++ b/docs/design/design-reviews/recipes/engagement-process.md @@ -37,7 +37,7 @@ Stories that will benefit from design reviews have one or more of the following ## Sprint Backlog Refinement -If your team is not already hosting a [Sprint Backlog Refinement](../../../agile-development/advanced-topics/backlog-management/README.md) session at least once per week you should consider it. It is a great opportunity to: +If your team is not already hosting a [Sprint Backlog Refinement](../../../agile-development/advanced-topics/backlog-management) session at least once per week you should consider it. It is a great opportunity to: 1. Keep the backlog clean 1. Re-prioritize work based on shifting business priorities diff --git a/docs/design/design-reviews/recipes/engineering-feasibility-spikes.md b/docs/design/design-reviews/recipes/engineering-feasibility-spikes.md index cd7f226569..26e7f2fb87 100644 --- a/docs/design/design-reviews/recipes/engineering-feasibility-spikes.md +++ b/docs/design/design-reviews/recipes/engineering-feasibility-spikes.md @@ -13,7 +13,7 @@ The following guidelines outline how Microsoft and the customer can incorporate ## Pre-Mortem -A good way to gauge what engineering spikes to conduct is to do a [pre-mortem](https://www.facebook.com/business/m/thinkkit/exercises/strong-starts/pre-mortem). +A good way to gauge what engineering spikes to conduct is to do a pre-mortem. ### What is a pre-mortem? diff --git a/docs/machine-learning/ml-project-management.md b/docs/machine-learning/ml-project-management.md index 7087ea6683..002ee1c1cb 100644 --- a/docs/machine-learning/ml-project-management.md +++ b/docs/machine-learning/ml-project-management.md @@ -13,7 +13,7 @@ To learn more about how ISE runs the Agile process for software development team Within this framework, the team follows these Agile ceremonies: -- [Backlog management](../agile-development/advanced-topics/backlog-management/README.md) +- [Backlog management](../agile-development/advanced-topics/backlog-management) - [Retrospectives](../agile-development/basics/ceremonies.md#retrospectives) - [Scrum of Scrums](../agile-development/advanced-topics/effective-organization/scrum-of-scrums.md) (where applicable) - [Sprint planning](../agile-development/basics/ceremonies.md#sprint-planning) From af5ecda95a0a9d5c45844d80c2987930604df261 Mon Sep 17 00:00:00 2001 From: Tess Ferrandez Date: Thu, 15 Aug 2024 10:56:02 +0200 Subject: [PATCH 7/7] fix agile links --- docs/ENG-FUNDAMENTALS-CHECKLIST.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/ENG-FUNDAMENTALS-CHECKLIST.md b/docs/ENG-FUNDAMENTALS-CHECKLIST.md index 9a1ea69a73..6a7764a7cd 100644 --- a/docs/ENG-FUNDAMENTALS-CHECKLIST.md +++ b/docs/ENG-FUNDAMENTALS-CHECKLIST.md @@ -20,7 +20,7 @@ More details on [source control](source-control/README.md) - [ ] All items are tracked in AzDevOps (or similar). - [ ] The board is organized (swim lanes, feature tags, technology tags). -More details on [backlog management](agile-development/advanced-topics/backlog-management/README.md) +More details on [backlog management](agile-development/advanced-topics/backlog-management) ## Testing