Ian Berry IT Blog

Notes

Six week cycles

• Strict time box, acts as a circuit breaker, by default no extension.

Shaping the work

• Senior group works in parallel to cycle team – focused on appetite (how much time do we want to spend)

Team fully responsible

• Making hard calls to finish the project (cycle) on time

Targeting risk

• The risk of not shipping on time. Solving open questions before we commit to a cycle. Build vertical deliverables, integrate early & continuously, sequence most unknown work first.

Part 1 Shaping

Wireframes are too concrete (give designers no room / creativity – design anchored)

Words are too abstract (solving a problem with no context, hard to understand scope & make tradeoffs)

Good Shaping:

• Its rough
• Its solved
• Its bounded

Shaping is kept private (closed door) until commitment to a cycle is made

Two work tracks (cycles)

• -> One for shaping
• -> One for building

6 week cycles, shaping leads into building:

Shaping 1 | Shaping 2
————-> Building 1 | Shaping 3
————————–>Building 2 | Shaping 4
—————————————> | Building 3
—————————————————->  | Building 4

Appetite

• Small batch (one designer, one or two programmers for one or two weeks)
• Big batch (same team size, 6 weeks)

Fixed time, variable scope: An appetite is completely different from an estimate. Estimates start with a design and end with a number. Appetites start with a number and end with a design

Analyse a customer problem – we asked when she wanted a calendar. What was she doing when the thought occurred to ask for it?

Breadboarding

Use words, or fat-marker visuals to achieve.

Fat marker visuals

• Avoid getting into a high level of fidelity, or into the weeds

Prefer pitches to be asynchronous communication – i.e. give people time to review offline in their own time, only escalate to real-time when necessary (i.e. meeting with key stakeholders) and give notice in advance

People review pitch and add comments (i.e to poke holes / ask questions – not to say no to the pitch, that’s for the betting table)

Part 2 Betting

Bets, not backlogs – big backlogs are a big weight we don’t need to carry. Backlogs are big time wasters – constantly reviewing, grooming and organising.Each 6 week cycle, a betting table is held where stakeholders decide what to do in the next cycle – containing a few well shaped, risk reduced options; the pitches are potential bets

• If a pitch was great, but the time wasn’t right (there is no backlog), individuals can track the pitch independently and lobby for it again six weeks later

Its easy to overvalue ideas – in truth ideas are cheap – don’t stockpile or backlog. Really important ideas will come back to you.

• Depending on whether we’re improving an existing product or building a new product, were going to set different expectations about what happens during the six week cycle.
  • Existing Products – Shape the work, bet on it, build.
  • New Products – broken into three phases:
    • 1. R&D mode: Learn what we want by building it (time boxed spikes, learn by doing), no expectation of shipping anything.
    • 2. Production mode: Shape the work, bet on it, build. Shipping is the goal (merging to main codebase), however not necessarily to end customers yet so we maintain the option to remove features from the final cut before launch
    • 3. Cleanup mode: A free for all, reserved capacity to finish things, or address things forgotten, bugs etc, no shaping, no clear team boundaries with work shipped continuously in as small bites as possible. Leadership make “final cut” decisions with cleanup not lasting longer than two cycles.

Examples

Part 3 Building

Assign projects, not tasks. Nobody plays the role of “taskmaster” or the “architect” who splits the project up into pieces for other people to execute.

Team defines their own tasks and work within the boundaries of the pitch.

Team have full autonomy and can use their judgement to execute.

Done means deployed. All QA needs to happen within the cycle.

A Basecamp project is created, chat channel and kickoff call.

First two – three days is radio silence from the team as they dive deep into the details and get aquatinted with the problem.

Team starts of with an imagined tasks, and through discovery learn about the real tasks to complete. Teams discover by doing the real work.

Integrate one slice

Pick a small slice of the project (ie design, backend & front end coding) to deliver end to end to show progress and gain feedback

Start in the middle

Start at the core of the problem (ie core screen and adding data to a database) and stub everything else out, rather than at the entry point (i.e. logging in). When choosing what to build first:

• It should be core
• It should be small
• It should be novel (things you’ve never done before, address risk / uncertainty)

Organise by structure, not by person

Allow teams to self organise around a problem, understand the scope, form a mental image, breaking down into parts that are no longer than 1-2 days effort – a series of mini scopes.

Scopes become the natural language of the project at the macro level. It will help communicate status and progress.

Scoping happens over time as the team learns (not necessarily all up front); You need to walk the territory before you can draw the map. Scopes need to be discovered by doing the real work; identifying imagined vs discovered tasks and seeing how things connect (and don’t connect).

How do you know if you have scoped right?

Usually takes a few weeks to get a clear understanding of scope

A typical software project is split into cake layers (front end & backend work, thin slices). Watch out for icebergs, which can see a lot more back end or a lot more front-end work; look to simplify, reduce the problem and/or split these into seperate projects.

There will always be things that don’t fit into specific scope buckets, we refer to these tasks a chowder.

Mark tasks which are nice to have with a leading ~ to identify nice-to-haves (to sort out from must-haves).

The problem with estimates is they don’t show uncertainty (or confidence level).

• If you have two tasks, both estimated to take four hours:
  • the team has done task 1 many times and you can be confident in the estimate
  • The team has never done task 2 or it has unclear interdependencies (lots of unknowns) is uncertain and a low confidence estimate

We came up with a way to see the status of a project without counting tasks and without numerical estimates – by shifting the focus from what’s done or not done to what’s unknown and what’s solved. We use the metaphor of the hill.

The uphill phase is full of uncertainty, unknowns and problem solving (ie discovery). The downhill phase is marked by certainty, confidence, seeing everything and knowing what to do.

A dot that doesn’t move over time is a red-flag, someone might be stuck and need help (the Hill Chart identifies this without someone needing to say “I dont know / I need help”). Changes languages and enables managers to help by asking “what can we solve to get that over the hill?”. A non-moving dot can also indicate work is progressing well, but scope is significantly increasing with discovery, the team can break scope apart into smaller scope or redefine / reshape the problem.

Sometimes tasks backslide, which often happens when someone did the uphill work (i.e. discovery) with their head (i.e. imagined) instead of their hands (practice). Uphill can be broken into three tasks:

1. “I’ve thought about this”
2. “Ive validated my approach”
3. “I’m far enough with what I’ve build that I don’t believe there are other unknowns”

Teams should attack the scariest / riskiest scope first within the cycle (given more time to unknown tasks and less time to known tasks).

Journalists have a concept called the inverted pyramid, their articles start with the most essential information at the top and add details and background information in decreasing order of importance. Teams should plan their work this way too.

There’s always more work than time. Shipping on time means shipping something that’s imperfect.

Pride in work is important for quality and morale, but we need to direct it at the right target. If we aim for perfect design we’l never get there, at the same time we dont want to lower our standard.

Instead of comparing up to an ideal, compare down to a baseline – seeing work as being better than what customers have today – “its not perfect, but it works and is an improvement”.

Limits motivate trade-offs, with a hard six week circuit breaker forces teams to make trade-offs.

Cutting scope isn’t lowering quality. Makes choices makes the product better, it differentiates the product (better at some things).

Base camp (for millions of customers), have one QA person. The designers and programmers take responsibility for the basic quality of their work and the QA person comes in towards the end of the cycle and hunts for edge cases outside the core functionality. Programmers write their own tests and team works together to ensure the project does what it should according to what was shaped.

We think of QA as a level up, not as a gate or check point.

The team can ship without waiting for a code-review, there’s no formal checkpoint. But code review makes things better, so if there’s time, it make sense.

When to extend a project

In rare cases we’ll allow a project to run past its deadline / cycle and use the following criteria:

• The outstanding tasks must be “must haves”
• The outstanding tasks must be all “down hill” – no unsolved problems, no open questions.

The cool down period can be used to finish a project, however team needs to be disciplined and this shouldn’t become a habit (points to a problem with shaping or team performance).

Shipping and going live can generate new work – through customer feedback, defects and new feature requests.

With customer feedback, treat as new raw ideas which need to go through the shaping process.

• Use a gentle no (push back) with customers until ideas are shaped and problem verified. If you say yes to customer requests, it can take away your freedom in the future (like taking on debt).

Feedback needs to be shaped.

As base camp has scaled to 50 people, we’ve been able to specialise roles:

• Product team (12)
• Specialised roles of designers and programmers
• Dedicated Security, Infrastructure & Performance (SIP) handles technical work, lower in stack and more structural
• Ops team (keep the lights on)
• Support team

With this structure, we don’t need to interrupt the designers and programmers on our core product team working on shaped projects within cycles.