From c2253f11a59ceffba9b430f5b0adddcb13bc5178 Mon Sep 17 00:00:00 2001 From: James Pace Date: Sat, 24 Feb 2024 12:07:31 +0000 Subject: [PATCH] Add scrum review article. --- posts/scaled-scrum.md | 94 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 94 insertions(+) create mode 100644 posts/scaled-scrum.md diff --git a/posts/scaled-scrum.md b/posts/scaled-scrum.md new file mode 100644 index 0000000..b13c44a --- /dev/null +++ b/posts/scaled-scrum.md @@ -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.