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 <who?>, I want <what?> so that <why?>.

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 <some input, conf, user...>,
• When <something happens>,
• Then <the system responds that way>.

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