public
/
til.jpace121
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Add scrum review article.

This commit is contained in:
James Pace 2024-02-24 12:07:31 +00:00
parent dd50547005
commit c2253f11a5
1 changed files with 94 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

94
posts/scaled-scrum.md Normal file
View File

@ -0,0 +1,94 @@
---
title: "Scalable Scrum Frameworks"
author: "James Pace"
date: "2024/02/24"
---
Scrum is a popular lightweight framework that defines how a single team can
work towards a goal and is very popular in software engineering circles.
Scrum is the most prescriptive of the frameworks that claim to be
"Agile", and is probably the initial approach most teams reach to
when they are trying to be more "Agile".
If you've worked on a "Sprint" to work down tasks in a "Backlog", you've
probably been doing Scrum.
The official definition of Scrum is found in the
[Scrum Guide](https://scrumguides.org/index.html).
The big idea in Scrum is there is a single "Product Owner" who is accountable
for managing a "Product Backlog", which is a list of tasks that need to be
done for a project.
Teams work to complete those tasks by completing a "Sprint" over a fixed time
interval.
A "Sprint" involves:
1. Defining a goal for the end of the sprint.
2. Picking which tasks from the "Product Backlog" will be worked on
for the sprint.
3. Working on those tasks, and communicating daily to make sure there are
no blockers.
4. At the end of each sprint, delivering some sort of deliverable working
towards the final deliverable (called an "increment"[^increment]).
5. Doing a retrospective and adjusting the process and backlog given
any information learned since the last sprint.
The Scrum Guide largely defines how a **single** Scrum team is built and works.
There are three popular approaches to extend Scrum to work for **multiple** teams:
1. Nexus
2. LeSS
3. SaFE
## Nexus
[Nexus](https://www.scrum.org/resources/online-nexus-guide) is the most light weight
and least prescriptive of the three aforementioned options.
Nexus starts with multiple scrum teams, all working on one product, who practice Scrum as normal
working from a single backlog of tasks.
To keep the individual Scrum teams from stepping all over each other, Nexus adds a "meta" Scrum team
called the "Nexus Integration Team" that is responsible for the coordination between teams, and
for combining the output of the inner Scrum teams into a single combined output.
The integration team is made up of selected members of the inner Scrum teams.
Of the three options in this article, I would lean towards Nexus if I was running a small start up
that had just outgrown every one being in one Scrum team.
Nexus would be easiest to apply, with the least amount of extra work and management layers.
## LeSS
[LeSS](https://less.works/) (for LargE Scale Scrum) is similar to Nexus, in that if you squint, it is
basically inner Scrums wrapped by a bigger Scrum, but the bigger Scrum doesn't have its own team.
Compared to Nexus, LeSS is also a lot more prescriptive.
Where Nexus leaves a lot up to the reader to figure out, LeSS provides a lot of guidance, answering
a lot questions in their guide that Nexus leaves up to the reader.
LeSS suggests roughly the following process for a sprint:
1. Sprint Planning 1, where the product owner communicates the things that need to be done
to all of the teams, who proportion the work out amongst themselves.
2. Sprint Planning 2, where the teams work to convert what needs to be done into individual
tasks that can be worked on.
3. Teams then go off and do Scrum to work on those tasks, refining the backlog and communicating
with eachother as they go.
4. At the end of the Sprint one Sprint Review is completed with all teams, and then two Retrospectives
are completed, one for each team and one for the Scrum as a whole.
Of the three options in this article, I would lean towards LeSS if I was in a small but already established
company.
I think the extra prescriptiveness of LeSS can help pre-answer questions people will have in a company that
is big enough that the person making the decision to switch can't individually talk to everyone, but also
small enough to not have decades of internal politics to wade through.
## SAFe
[SAFe](https://scaledagile.com/) is the most prescriptive of the methods in this article,
and arguably the least agile.
SAFe has multiple complicated layers of management, but all the complicated levels
are clearly documented with their explicit roles spelled out clearly.
My impression is SAFe only really makes sense in a large organization where there already
is a multilayered management system, and that system is seen as good.
[^increment]: Think "incremental deliverable" but with less letters.