Automation workshop

Recommended owner: Technical team members, led by a senior engineer, tech lead or platform/DevOps engineer with visibility into the delivery pipeline.

Goals

What the team will do during the workshop:

1. Inventory manual work done in the sprint, by domain (CI/CD, testing, configuration, reporting and release).
2. Estimate cost per item: time × frequency × people.
3. Triage candidates on a 2×2 (ROI vs. effort) matrix.
4. Scope the top three automation candidates and assign owners.

Impact

What the team will walk away with:

1. A visible catalog of what the team does by hand, with costs attached.
2. A ranked list of automation candidates with owners.
3. A first scoped automation target broken down into the smallest shippable increment.
4. A culture shift from “we don’t have time to automate” to “we don’t have time not to.”

When to run this workshop

The automation workshop earns its slot when the readout shows manual hours dominating, or when the team has had the same “we should automate that” conversation in three retros without anything moving. The workshop converts vague automation appetite into a triaged, costed and owned candidate list and a first scoped increment — which is the threshold for actually shipping automation rather than talking about it.

Reach for it when:

• The readout’s automation page shows manual work as the dominant category — every manual hour repeats every sprint, so the recovery compounds.
• The team has just absorbed a new platform, tool or domain — manual work always spikes when something new lands; a workshop within the first two or three sprints catches it before it normalizes.
• A specific bottleneck is consuming the team’s calendar — manual deploys, regression-test cycles, environment refreshes and status reporting. The Theory of Constraints lens in Exercise 4 is built for exactly this case.

Don’t reach for it when the readout’s automation hours are small (you’ll be optimizing the trivial many; rework or planning will return more), when the team is already mid-implementation on a major automation initiative (let it land before re-triaging) or when the work the team wants to automate is bespoke one-off effort that won’t repeat (automation pays back through repetition).

Audience and personas

Facilitator

Senior engineer or DevOps/platform engineer who understands the delivery pipeline and can challenge “but we always do it by hand” defaults.

Required participants

• Engineers who did manual work this sprint (CI/CD, testing, ops and deployments)
• QA or quality engineer (if on the team)
• Release manager or whoever coordinates deployments

Optional but valuable

• Platform/SRE engineer (if separate from the team)
• Product owner (for reporting/dashboard candidates — they’re the consumer)

Roles

The six automation domains

Teach these in the opening. They are the prompts for the manual-work inventory.

On Domain 4 (environment hand-holding). Each instance is small; the total is often 30–40% of a sprint. The fix is deterministic deploys, idempotent promotion scripts, fixture generation and environment parity — not heroic futzing. Automating it doesn’t replace the expert doing the futzing; it frees them to work on the novel problems that only a human can solve.

Pre-homework

Reading (for all participants)

• Everyone does TDD wrong — the “list scenarios first” mental model maps directly to listing manual steps first.
• The only way to deliver a zero-defect product — engineering owns testing, which frames why automating tests matters.
• The balanced power of TDD — “test the riskiest parts early” and “research, not construction” — pick automation candidates by risk, not by ease.
• Solve delivery with a steel thread — “automation is the only path to higher environments.”

Individual prep (~30 min)

Each participant brings:

1. A list of every manual task they did this sprint (at least the 5 most time-consuming).
2. For each: rough time spent, how often it happens (per sprint, per day, per deploy), and whether they were the only one who could do it.

Optional preparation (facilitator, 1 hour before the workshop)

The facilitator walks through the delivery pipeline end-to-end — watching a deploy, shadowing a release and observing a test run — specifically to spot manual work that engineers have normalized. What feels normal to the team often jumps out to a fresh observer. Bring the list into the workshop as seed stickies; the team will be astonished at what they’d stopped noticing. Full walkthrough → Gemba walk.

Team prep (done by facilitator, ~15 min)

• Pull automation/waiting hours from the readout.
• Draw the 2×2 matrix (x = effort to automate, y = recovery value).
• Pre-stage a long horizontal “pipeline strip” on the wall for optional value stream mapping (see Exercise 1’s Substitute).
• Prepare the automation-candidate template (see below).

Materials and setup

• Whiteboard or Miro/Mural board
• Sticky notes (one color per domain)
• Markers and dot-vote stickers
• The readout’s automation page
• Shared doc for the candidate inventory

Agenda (2.5 hours)

Workshop exercises

Exercise 1 — Manual-work inventory (25 min)

Silent brainstorm (7 min): each person writes manual tasks on stickies, one per sticky. This follows the Liberating Structures “1” step of 1-2-4-All — the silent start prevents early voices from anchoring the group.

Then each person shares (pair, then share to group if time allows). Scribe captures:

• What the task is
• How long it takes
• How often it happens
• Who can do it

Prompt the team: “What did we not notice because we always do it that way?”

Substitute: value stream mapping (45 min)

Use this instead of the manual-work inventory when the team needs a bigger-picture view of the pipeline, or add it afterward (adding ~20 min to the total) when the pipeline has many stages.

VSM is the single highest-leverage discovery tool when the team feels like “we’re busy but nothing ships” — it visualizes the delivery pipeline end-to-end, annotates each step with process time, wait time and first-pass yield, and exposes exactly where hours are going. The manual-effort and waiting-waste stickies become the automation-candidate list that feeds Exercise 2.

Full walkthrough, including process-time/wait-time/first-pass-yield mechanics, worked example and future-state mapping → Value stream mapping.

Exercise 2 — Cluster into domains (10 min)

Move stickies (from the inventory or VSM) into the six domain regions. A single task may touch two domains — put it at the intersection.

Exercise 3 — Cost calculation (15 min)

For each sticky, calculate:

Cost = time per occurrence × occurrences per sprint × people involved

Write the number on the sticky. This converts “it’s just a 10-minute thing” into “it’s 2 hours per sprint across the team.”

Add them up by domain. The scribe captures. Now the team sees the shape of the waste.

Exercise 4 — 2×2 matrix with Theory of Constraints lens (30 min)

Draw the matrix:

Place each high-cost sticky on the matrix. Disagreements are signal — capture the reasoning. The full mechanics of the matrix (silent placement, axis definition, quadrant-assignment discipline) → 2×2 prioritization matrix.

Before finalizing, apply the Theory of Constraints lens: mark any sticky that sits on the team’s current delivery bottleneck with a star. Goldratt’s insight is that automating anything other than the bottleneck doesn’t speed up delivery — it just moves the pile. Stars go to the front of the queue regardless of which quadrant they’re in.

Skip anything in Skip. Focus on starred items first, then the rest of Automate now. Schedule gets a backlog entry.

Exercise 5 — Scenario lists for top three (30 min)

From Everyone does TDD wrong: “write a list of the test scenarios you want to cover.” We adapt this: write a list of the manual steps you want to automate, then pick the first one.

Break into small groups (one per top candidate). Each group:

1. Writes a complete list of manual steps the automation would replace.
2. Picks the smallest one — the steel thread of the automation.
3. Drafts a one-sentence description of a scripted/tested replacement.

Each group shares back. This is the first-increment scope.

Automation-candidate template

Example candidate

Capturing results

Within 24 hours, the scribe produces:

1. Manual-work inventory with costs per item and per domain.
2. The ranked candidate list with owners and first-increment scope.
3. Anything in Schedule added to the team’s backlog with a note about when it will surface.

Follow-up

• Facilitator checks in at mid-sprint: is the first-increment script/test/dashboard in progress?
• Next waste walk: automation hours in the readout should be measurably lower. If not, the first-increment wasn’t real — revisit scope.
• Publish a wins log. Automation wins are contagious — share them.

Anti-patterns to watch for

• Automating the easy instead of the risky. If the top candidate is “trivial” in effort, ask what you’d learn from attempting the hard one first. (See The balanced power of TDD on prioritizing risk.)

• Automating off the bottleneck. Automating something that isn’t the delivery bottleneck doesn’t speed anything up. Star the bottleneck in Exercise 4 and prioritize accordingly.

• Big-bang automation plans. If the first increment takes more than a sprint, it’s not an increment — break it down.

• Tools over ownership. Don’t buy a new tool before proving the approach with an existing one.

• “QA will do it.” Engineering owns quality. Automation that replaces manual testing belongs in the codebase, written by the team that writes the code (see The only way to deliver a zero-defect product).

• “Automation will replace me.” It won’t. Automation replaces the repeatable part of the work — the clicks, the tweaks, the regression runs — so the expert is free to tackle the novel part. A QA engineer who spends 15 hours a sprint on regression clicks and 5 hours on weird edge cases is a QA engineer who should have 0 hours clicking and 20 hours on edge cases. The automation doesn’t shrink the role; it upgrades it.

  Name the fear explicitly when you hear it — unaddressed, it’s the largest single blocker to environment-hand-holding and manual-testing candidates actually getting automated.

Alternative and complementary exercises

Swap these in for specific situations or as warm-up / cool-down activities.

TRIZ — “How could we guarantee we never automate anything?” (15 min, warm-up)

Invert the question: rather than “what should we automate?” ask “what could we do to guarantee we stay stuck with all this manual work?” Expect answers like: “keep everything tribal knowledge,” “schedule automation after the ‘real’ work,” “require 5 approvals for any new CI job,” “tell engineers that automation is QA’s job.” Then ask: “which of these are we actually doing?” Teams admit to sacred-cow behaviors safely because they start as hypotheticals.

Use it as: A 15-minute opener on a team that’s been resistant to automation or has a history of false starts. Full walkthrough → TRIZ.

Reverse brainstorm (“How could we make this process worse?”)

Closely related to TRIZ but narrower — applied to a single manual process rather than the whole team. Good for unpacking why a specific manual step is sticky.

1-2-4-All (facilitation pattern)

The 1-2-4-All structure is already baked into Exercise 1. The pattern — silent individual, paired, small group, full group — is applicable anywhere brainstorming risks being dominated by loud voices. Use it anywhere the silent-brainstorm step could benefit from a pair/small-group refinement before the full share-out. Full walkthrough → 1-2-4-All.

Pareto on manual-work costs

After Exercise 3 (cost calculation), sort tasks by team-hour cost from largest to smallest. Typically 20% of tasks carry 80% of the cost. Explicitly name the top three as the Pareto candidates — they’re automation priorities regardless of what comes out of the 2×2. See Pareto analysis for the method.

Theory of Constraints — “Five focusing steps”

Eliyahu Goldratt’s full framework, used as a framing overlay:

1. Identify the constraint (the bottleneck)
2. Exploit it (get the most out of it without investment)
3. Subordinate everything else to the constraint (don’t optimize non-bottlenecks)
4. Elevate the constraint (invest to increase its capacity, often through automation)
5. Repeat when the constraint moves

Useful for framing the whole discussion. Automation is typically step 4. Steps 1–3 often reveal that the team can get immediate wins without investment, which reduces “automate everything” pressure.

References

Related guides

• Rework workshop — for tracing rework hours back to their origin in the delivery pipeline.
• Planning workshop — for finding meeting overhead, late planning and external dependency friction.

Process guide

• Process guide — reference library for every facilitation technique called out in this workshop (including 1-2-4-All, TRIZ, value stream mapping, Theory of Constraints and more).

Delivery Playbook articles

• My formula for running a successful workshop — the meta-framework this guide follows.
• Everyone does TDD wrong — scenario-list approach.
• The only way to deliver a zero-defect product — engineering owns quality.
• The balanced power of TDD — test the riskiest parts early.
• Solve delivery with a steel thread — automation as prerequisite for production.
• Observability as architecture — why instrumented automation beats tribal knowledge.

External references

• Kent Beck, Canon TDD — the scenario-list mental model.
• Mike Rother and John Shook, Learning to See (Lean Enterprise Institute, 2003) — the canonical value stream mapping text; see the Lean Enterprise Institute VSM workshop kit.
• Miro — How to run a VSM workshop — practical remote-friendly walkthrough.
• Eliyahu Goldratt, The Goal (1984) — Theory of Constraints; five focusing steps.
• Henri Lipmanowicz and Keith McCandless, Liberating Structures — including 1-2-4-All and TRIZ.
• “Gemba walk” — Taiichi Ohno’s shop-floor practice, codified for Western audiences in Masaaki Imai’s Gemba Kaizen (McGraw-Hill, 1997).
• OpenTelemetry — instrumented automation standard.
• DORA metrics — deployment frequency and lead time as automation payoff signals.
• Thoughtworks Technology Radar on Infrastructure as Code.