You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* 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
Copy file name to clipboardExpand all lines: docs/SPRINT-STRUCTURE.md
+9-9
Original file line number
Diff line number
Diff line change
@@ -10,22 +10,22 @@ The purpose of this document is to:
10
10
11
11
### Before starting the project
12
12
13
-
-[ ][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
13
+
-[ ] Discuss and start writing the Team Agreements. Update these documents with any process decisions made throughout the project
-[Agile Basics](./basics/README.md): Learn or refresh your basic agile knowledge.
4
-
-[Agile Core Expectations](./core-expectations/README.md): What are our core expectations from an Agile team.
5
-
-[Agile Advanced Topics](./advanced-topics/README.md): Go beyond the basics.
3
+
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.
4
+
5
+
## Why agile
6
+
7
+
- We want to be quick to respond to change
8
+
- We want to get to a state of working software fast, and iterate on it to improve it
9
+
- We want to keep the customer/end users involved all the way through
10
+
- We care about individuals and interactions over documents and processes
11
+
12
+
## The fundamentals
13
+
14
+
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.
15
+
16
+
- We keep a shared backlog of work, that everyone in the team can always access (ex. Azure DevOps or GitHub)
17
+
- We plan our work in iterations with clear goals (ex. sprints)
18
+
- We have a clear idea of when work items are ready to implement (ex. definition of ready)
19
+
- We have a clear idea of when work items are completed (ex. definition of done)
20
+
- We communicate the progress in one place that everyone can access, and keep the progress up to date (ex. sprint board and daily standups)
21
+
- We reflect on our work regularly to make improvements (ex. retrospectives)
22
+
- The team has a clear idea of the roles and responsibilities in the project (ex. Dev lead, TPM, Process Lead etc.)
23
+
- The team has a joint idea of how we work together (ex. team agreement)
24
+
- We value and respect the opinions and work of all team members.
25
+
26
+
## Links
27
+
28
+
-[What Is Scrum?](https://www.scrum.org/resources/what-is-scrum)
29
+
-[Essential Scrum: A Practical Guide to The Most Popular Agile Process](https://www.goodreads.com/book/show/13663747-essential-scrum)
Copy file name to clipboardExpand all lines: docs/agile-development/advanced-topics/collaboration/virtual-collaboration.md
+20-29
Original file line number
Diff line number
Diff line change
@@ -7,8 +7,8 @@ Pair programming works well under the correct circumstances, but it loses some o
7
7
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:
8
8
9
9
1. Generating clarity through communication
10
-
2. Producing higher quality through collaboration
11
-
3. Creating ownership through equal contribution
10
+
1. Producing higher quality through collaboration
11
+
1. Creating ownership through equal contribution
12
12
13
13
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.
14
14
@@ -23,19 +23,16 @@ Red Team Testing has the same philosophy as any other Test-Driven Development li
23
23
## Steps
24
24
25
25
1. Design Phase: Both developers design the interface together. This includes:
26
-
* Method signatures and names
27
-
* Writing documentation or docstrings for what the methods are intended to do.
28
-
* Architecture decisions that would influence testing (Factory patterns, etc.)
29
-
30
-
2. Implementation Phase: The developers separate and parallelize work, while continuing to communicate.
31
-
* Developer A will design the implementation of the methods, adhering to the previously decided design.
32
-
* Developer B will concurrently write tests for the same method signatures, without knowing details of the implementation.
33
-
34
-
3. Integration & Testing Phase: Both developers commit their code and run the tests.
35
-
* Utopian Scenario: All tests run and pass correctly.
36
-
* 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.
37
-
38
-
4. The developers will repeat the three phases until the code is functional and tested.
26
+
- Method signatures and names
27
+
- Writing documentation or docstrings for what the methods are intended to do.
28
+
- Architecture decisions that would influence testing (Factory patterns, etc.)
29
+
1. Implementation Phase: The developers separate and parallelize work, while continuing to communicate.
30
+
- Developer A will design the implementation of the methods, adhering to the previously decided design.
31
+
- Developer B will concurrently write tests for the same method signatures, without knowing details of the implementation.
32
+
1. Integration & Testing Phase: Both developers commit their code and run the tests.
33
+
- Utopian Scenario: All tests run and pass correctly.
34
+
- 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.
35
+
1. The developers will repeat the three phases until the code is functional and tested.
39
36
40
37
## When to follow the RTT strategy
41
38
@@ -47,20 +44,14 @@ RTT also works well when there is complete consensus, or no consensus at all, on
47
44
48
45
RTT has many of the same benefits as Pair Programming and Test-Driven development but tries to update them for a virtual setting.
49
46
50
-
* 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.
51
-
52
-
* RTT maintains the pair programming paradigm, while reducing the need for video communication or constant communication between developers.
53
-
54
-
* RTT allows detailed focus on design and engineering alignment before implementing any code, leading to cleaner and simpler interfaces.
55
-
56
-
* RTT encourages testing to be prioritized alongside implementation, instead of having testing follow or be influenced by the implementation of the code.
57
-
58
-
* Documentation is inherently a part of RTT, since both the implementer and the tester need correct, up to date documentation, in the implementation phase.
47
+
- 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.
48
+
- RTT maintains the pair programming paradigm, while reducing the need for video communication or constant communication between developers.
49
+
- RTT allows detailed focus on design and engineering alignment before implementing any code, leading to cleaner and simpler interfaces.
50
+
- RTT encourages testing to be prioritized alongside implementation, instead of having testing follow or be influenced by the implementation of the code.
51
+
- Documentation is inherently a part of RTT, since both the implementer and the tester need correct, up to date documentation, in the implementation phase.
59
52
60
53
## What you need for RTT to work well
61
54
62
-
* 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.
63
-
64
-
* 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.
65
-
66
-
* 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.
55
+
- 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.
56
+
- 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.
57
+
- 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.
Copy file name to clipboardExpand all lines: docs/agile-development/advanced-topics/collaboration/why-collaboration.md
-3
Original file line number
Diff line number
Diff line change
@@ -74,9 +74,6 @@ Knowledge sharing and bringing ISE and customer engineers together in a ‘code-
74
74
## Resources
75
75
76
76
-[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
77
-
78
77
-[On Pair Programming - Martin Fowler](https://martinfowler.com/articles/on-pair-programming.html)
79
-
80
78
-[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)
81
-
82
79
-[Effortless Pair Programming with GitHub Codespaces and VSCode](./pair-programming-tools.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](../../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).
3
+
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.
4
4
5
5
## Goals
6
6
7
7
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.
8
8
9
-
The scrum of scrums ceremony happens every day and can be seen as a regular [stand-up](../../core-expectations/README.md):
9
+
The scrum of scrums ceremony happens every day and can be seen as a regular stand-up:
10
10
11
11
- What was done the day before by the sub-team.
12
12
- 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
15
15
16
16
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.
17
17
18
-
This list of impediments is usually managed in a separate [backlog](../backlog-management/README.md) but does not have to.
18
+
This list of impediments is usually managed in a separate [backlog](../../basics/backlog-management.md) but does not have to.
19
19
20
20
## Participation
21
21
22
-
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.
22
+
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.
23
23
24
24
## Impact
25
25
@@ -29,8 +29,8 @@ When choosing to implement Scrum of Scrums, you need to keep in mind that some t
29
29
30
30
## Measures
31
31
32
-
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?).
32
+
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?).
33
33
34
34
## Facilitation Guidance
35
35
36
-
This should be facilitated like a regular [stand-up](../../core-expectations/README.md).
36
+
This should be facilitated like a regular stand-up.
0 commit comments