Wakalix/Guides/Picture it in your organisation

The migration nobody would scope.

Every organisation has one, deferred another quarter because nobody can say how big it is. This guide shows the way in, and ends with an exercise to size your own.

A six-minute readFor engineering leadersJump to the exercise ↓

The situation

Every organisation has one.

Yours might be the legacy payment path, the framework two majors behind, or the database nobody wants to touch. Everyone agrees it matters. It has been agreed for four quarters.

It doesn't get deferred because it isn't worth doing. It gets deferred because nobody can scope it, and a plan without a size doesn't win an argument against work that has one.

The unknowns are the work. Scoping it honestly would mean doing much of it first, so the ticket collects another stamp and waits.

Why it's hard

Three reasons it never gets scoped.

One

Nobody knows every caller

The call sites grew over years. A search finds most of them, never all of them.

Two

The behaviour is undocumented

Nobody can promise the same behaviour when nobody has written down today's.

Three

The authors have left

The reasons for the odd cases went with them. The code shows what, not why.

The way in

Buy knowledge first, then ship slices.

A migration stalls when the first cycle has to produce changes. Let the first cycle produce knowledge instead, and the second one has something to size.

  1. Run a survey cycleOne cycle that changes nothing: what calls it, what it does today, what could be carved off first.
  2. Write down the decisions that are yoursThe data model, the cutover, the rollback, anything a customer would notice.
  3. Pin today's behaviourTests that capture what happens now come before changes, so unchanged is something you can prove.
  4. Cut the first slice that ships aloneOne path, one caller, one table. It goes through the same review as any other change.
  5. Keep it on the roadmapOne roadmap item, one cycle at a time, while normal delivery carries on beside it.

The questions

Five questions before you start.

Put these to whoever would run it. Vague answers aren't a reason to defer again; they're the list of what cycle one is for.

  1. What would we know at the end of one survey cycle?

    Survey

    Name what it produces: a list of callers, the behaviour written down, a first slice. If that's vague, the cycle isn't scoped either.

  2. What is the smallest slice that could ship on its own?

    Slice

    If nothing can ship alone today, the first slice is the work that makes one possible.

  3. Which decisions are ours, not the agent's?

    Decisions

    The data model, the cutover and the rollback are yours. Name the person for each before any build starts.

  4. How do we prove behaviour is unchanged?

    Proof

    Without tests that pin today's behaviour, the same as before is an opinion, and the review has nothing to check.

  5. What happens to normal delivery while this runs?

    Delivery

    If the migration has no place on the roadmap, it competes with everything else in private, and loses again.

Try this on your organisation

Size your stuck migration.

Answer for the one you keep deferring. It takes two minutes, it proposes a first cycle rather than a plan, and nothing you type leaves this page.

The migration
What you don't know yet
Decisions that need a person
Can it be cut up?

These are example answers. Replace them with yours.

What you'd know at the end of it
    Book these with named people first

      No durations here, on purpose. Cycle one is what tells you what the rest is worth estimating.

      With Wakalix

      A migration is work like any other.

      Wakalix doesn't make a migration small. It makes it one roadmap item with cycles under it, each approved by a person and each leaving a record.

      1. 1
        It starts on the roadmapEvery product keeps a ranked roadmap. A cycle opens from any item, and the roadmap keeps track of every cycle it spawned and what each one produced.
      2. 2
        A plan, approved before anything runsA planning agent breaks the work into items, each with a definition of done and the right agent. Nothing runs until a person approves the plan.
      3. 3
        The agent stops when the call is yoursWhen a decision belongs to a person, the agent stops, lays out the options and waits. It doesn't guess at the cutover.
      4. 4
        Every slice comes back with evidenceWork comes back with its evidence and lands as a pull request a person merges. Every item is estimated before it starts.
      Roadmap
      The Wakalix roadmap: ranked items per product, each marked proposed or accepted.
      Product screen · the migration lives here, as one ranked item.
      Cycles
      A delivery cycle in Wakalix: its plan, phases and board, with one item blocked because an agent asked a person.
      Product screen · one cycle under it, with its approved plan and board.

      What an agent got wrong goes back into the agents at the retro, so the next slice starts from a better team than the last one did.

      Next

      Bring your migration to a conversation.

      Fill in the exercise for the one you keep deferring, and note what cycle one would have to answer. Then tell us, and we'll walk you through how it would run in Wakalix.

      Request accessHow it works