_drafts/rust-ros2-quick-review.md

@@ -1,23 +0,0 @@
----
-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

@@ -1,94 +0,0 @@
----
-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.