Add scrum review article.

_drafts/rust-ros2-quick-review.md

@@ -0,0 +1,23 @@
+---
+title: "ROS2 Rust Options"
+author: "James Pace"
+date: "2024/01/01"
+---
+
+<!--
+ros2_rust
+- Most official
+- Good non-ROS rust integration
+- no async
+r2r
+- good async
+- most rusty
+- no need to do weird things with messages
+- support for colcon is weak
+- one real maintainer.
+safe_drive
+- Good colcon support
+- Good async support
+- Good in between of ROS and Rust
+- Not heavily adopted.
+-->

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.