Basic refactor of agile section (#1057)

* refactor agile

* refactor and clean up of the agile section

* refactor and clean up of the agile section

* fix agile links

* remove core expectations as all the content is moved to other places

* fix agile links

* fix agile links

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
 
@@ -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
 

docs/SPRINT-STRUCTURE.md

@@ -10,22 +10,22 @@ 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)
-  - [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
-- [ ] [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)
 
 ### 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)
@@ -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)

docs/agile-development/README.md

@@ -1,5 +1,29 @@
-# 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.
+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
+- 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 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)

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 ?
 

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.

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)

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

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.