# The Sc(r)umBag Method This document is about a project-based agile framework called Sc®umBag. Its intent is to build guidelines on top of a set of real-world observations made in the context of two different organizations. # What we do now (and what's wrong about it) ## One feature one guy (one jar) A new feature has to be implemented, one guy is dedicated to design and develop it all in his subsystem. * If the feature breaks during QA: * preemptive **context switch** * If the feature breaks during deployment: * debug over IRC (w/ possibly reduced time frame), 1 dev + 1 ops * send the dev to site * the dev is in vacation, someone else applies a band-aid to the wooden leg * If the feature breaks 3 years later (maintenance/evolution): * the dev is long gone, nobody knows this piece of code anymore **Bottomline: No matter when it breaks, you just know it is going to be a pain in the ass** because our **bus factor** is critically low: * How many guys should get hit by a bus to put the project/release at risk? * How many guys know how to fix this crap? ## Code gets catapulted to the QA A dev takes an issue, writes some code, does some manual test, then simply considers it done and passes it on to the QA with little to no formal communication. * The QA engineer is assumed to own a cristal bowl (poor communication) * How does he know what to test? * Worse: how does he know what the code is supposed to do? * Issues stuck, going back and forth between dev and QA Unclear definition of **done**. When is your job done? Does everybody know (and agree) on that? Lots of **Work In Progress (WIP)**. **WIP == stock**: the amount of work that you've spent some brain juice on and still haven't been paid for. This is typically something you want to keep as low as possible. An issue that stays in progress forever is a feature that never gets delivered to the client: it is **a loss of resources and value**. We're engineers: we're naturally unhappy/demotivated when we don't deliver. # Proposed methodology ## Goals * Improve communication **quality** to cut off **quantity**. * Limit context switching to the bare minimum. * Ban micro-management. * Reduce the WIP and keep it under control. * Increase the bus factor. * Optimize the software delivery pipeline's bottlenecks. * Avoid rush periods as best as we can: achieve constant, comfortable workload. ## Base communication principles **Most** team meetings should be: * Optional (you can attend if you're interested, or not), * Open (everyone *in the company* is welcome) Except for the ceremonies. ## Ceremonies **Stand-ups** * Open, mandatory for the team, * Period: daily * Duration: 15 minutes **max**. * Update on what happened during last 24h period. * Prepare for the next period. Anticipate upcoming issues. * **Good stand-ups yield collaboration and team self-organization**. **Retrospectives** * Team-only, mandatory, * Period: 2 to 4 weeks, * Duration: 60 minutes **max**, * Review the last period and provide individual feedback on how the team performed. * **Good retrospectives yield actions to make better next time**. These ceremonies allow the team to manage itself. Any other meetings that may be described in the rest of the document are optional and open by default. ## User Stories A User Story (US) is the description of a (set of) feature(s) from a user's perspective. Good User Stories follow the INVEST characteristics: * Independent * Negociable * Valuable * Estimatable * Small * Testable It should also be written using the following formalism: As , I want so that . It must focus on the usage and the required additional **user capabilities**, **This allows to develop only valuable code**, i.e. code that brings value to the users of this piece of software. The product owner (PO) should give a **rough initial estimate** of how much workload (engineer juice) he would like to spend on the US. Once written, the US must be refined by the development team, so they can derive *what needs to be done* to complete it. The fact that the US is written describing user capabilities makes it easier to derive: * Which parts of the software should be modified and how. * What to test & how it should be tested. * **Acceptance criteria**: list of checks that prove the completion of the US. Those refined details (especially acceptance criteria) should be **written** on the ticket, as they define a contract between the developers, the product owners and the QA engineers. Acceptance criteria should be written on the Given-When-Then form: * Given , * When , * Then . Good acceptance criteria are testable, either manually or automatically whenever possible. Once refined, the US may be split in subtasks (sub-tickets), and its complexity estimated. If the estimation is too different from the PO's initial budget, the **scope** of the US may be re-negociated. Writing subtasks allows to: * Share the workload within the team, thus encouraging cooperation and increasing the bus factor. * Modularize the US (make it easier to negociate its scope with the PO). ## Definition of DONE A User Story is **done** (from the devs' point of view) when: * Its acceptance criteria are met. * The code was reviewed & merged to the shared baseline development branch. * The authors have provided either automated tests or manual test results to prove that the code works and show how. * (Optional) The US has been demo-ed in an open meeting. **Only then can it move to QA.** Developing automated tests or being commited to provide manual test results before moving on is important: * It prevents from sending obviously broken code to the QA. * Automated tests are written once, forever, and they ease regression testing. * It shows what has changed functionnally. ## Keeping the WIP and team performance under control Measure first, then optimize. "Measuring" the team's performance can be done in several ways. ### Local day-to-day control WIP can be controlled locally using a kanban board. A kanban is basically a sticky note describing a task to be completed. The kanban board consists in (at least) three columns: * To Do, * In Progress, * Done The board can be further divided using lines (or sections) to delimit user stories. Subtasks are written on sticky notes and moved from one column to another on the board. **The In Progress column must be kept as small as possible**. A good starting rule is to forbid (or at least strongly discourage) to have more kanbans in this column than there are developpers in the team. The goal here is to encourage developers to **focus** on one subtask at a time, limit context switching, and finish any started work. ### Global control The WIP control and team performance can also be globally measured and controlled by computing graphs, based on the ticket management software we use. It is a good idea to display the following graphs on a globally available dashboard: * Tickets in progress over time (WIP control) * Tickets created vs. tickets closed over time (project health) * Release burnup chart: tasks done over time vs. projection of the global release scope, (team velocity & complexity estimation accuracy) The burnup chart is about controlling the team's velocity and ability to estimate the complexity of tasks. # Why Sc(r)umBag ? SCRUM: * (artificially) time-boxed, * ceremonies (self-organization), * Primary goals: * adjust with customer requirements over time through frequent demos & feedback. * improve the team's ability to estimate complexity. * control preemption by freezing the development's scope during an iteration (sprint). Kanban: * No time box, * Use of a prioritized kanban board * Primary goals: * Control the WIP, * Allow for rapid priority shift without context-switching What about us? * We're already time-boxed based on ground truth. * Customer demos cannot be frequent: slow feedback. * We've had a fair share of priority switches in the past. But we still need some of the benefits of SCRUM! * SCRUM + Kanban -> ScrumBan (already exists, based on SCRUM's sprints & demos) * Hence, Sc(r)umBag