Ten modules, a hundred days, one page at a time. Each day gives you the
idea, a worked case file, the trap that catches people out, and the one
line to remember. Work it in order, or jump straight to what you need.
Day 01 / 100 · Agile foundations · Agile vs Agile theatre
Agile that ships. Not Agile that meets.
Plenty of teams run every ceremony and still deliver nothing new for months. Here's how to tell the real thing from the show.
Theatre
Real
The daily stand-up is a status report to the manager.
The team replans the day around the sprint goal.
Velocity goes up every sprint.
Customers get something useful every sprint.
Retro actions that nobody follows up.
One change, tried, then checked next sprint.
A board everyone updates and nobody reads.
A board the team uses to make decisions.
Measure what shipped, not what met.
Day 02 / 100 · Agile foundations · The Manifesto, read today
Four values. Still radical.
Written in 2001 by seventeen software practitioners. It takes a minute to read and is still widely misread.
Individuals and interactions
Value 01
over processes and tools
READ TODAY
A five-minute call beats a ten-comment ticket.
Working software
Value 02
over comprehensive documentation
READ TODAY
Show it running. Document what matters.
Customer collaboration
Value 03
over contract negotiation
READ TODAY
Customers in reviews, not just in contracts.
Responding to change
Value 04
over following a plan
READ TODAY
Plan, then re-plan when you learn.
Over, not instead of.
Day 03 / 100 · Agile foundations · Empiricism
Decide on what you see.
Empiricism means making decisions from what's actually happening, not what the plan said would happen. It rests on three pillars.
Transparency
Make It Visible
“Show me what's stuck, not just what's done.”
Work, problems and progress where everyone can see them.
Inspection
Look Often
Daily, at every review, at every retro.
Check progress toward the goal while there's time to react.
Adaptation
Change Course
“We're off track. What do we change now?”
Adjust the plan, the work or the way you work.
Make it visible. Look often. Change course.
Day 04 / 100 · Agile foundations · Scrum vs Kanban vs hybrid
Fit the method to the work.
No framework is best in general. Each suits a different way that work arrives. Start there, not with a favourite.
Scrum
Fixed Sprints
Best for: product work toward planned goals.
Sprints, a sprint goal, clear roles and regular events.
Kanban
Continuous Flow
Best for: support, ops and unpredictable arrivals.
Visual flow, limits on work in progress, pull when ready.
Hybrid
Both, On Purpose
Best for: teams that build and support.
Sprints for planned work, a flow lane for interrupts.
Fit the method to how work arrives.
Day 05 / 100 · Agile foundations · Iterative vs incremental
Build it in slices.
Incremental adds finished pieces. Iterative refines a rough whole. The best delivery does both, a point Jeff Patton made famous with his Mona Lisa sketches.
Incremental
Piece By Piece
Finish the login, then billing, then faults.
Risk: nothing useful end to end until the last piece lands.
Iterative
Rough, Then Better
Sketch the whole thing, then refine it.
Risk: it never quite gets finished.
Both
Thin And Whole
One useful slice, end to end, then improve.
Customers get value early, and you learn fast.
Thin, whole, useful. Then better.
Day 06 / 100 · Agile foundations · Why waterfall still exists
Waterfall isn't evil.
Sequential plans fit some work very well. Knowing when is a delivery skill, not a betrayal of Agile.
Known requirements
Fits
The work has been done many times and won't change.
EXAMPLE
Rolling out a standard phone system.
Hard sequences
Fits
Physical work, lead times and dependencies that can't be reordered.
EXAMPLE
Fibre installs, office moves.
Fixed commitments
Fits
Fixed-scope contracts and regulatory deadlines.
EXAMPLE
A compliance change due by a set date.
Novel work
Doesn'T Fit
Unclear users, new technology, lots to learn.
EXAMPLE
A brand-new customer app.
Known path: plan it. Unknown path: iterate it.
Day 07 / 100 · Agile foundations · Cynefin
What kind of problem is this?
Dave Snowden's Cynefin framework sorts problems by how cause and effect behave. Agile shines in the complex domain.
Clear
Sense, Categorise, Respond
Best practice. e.g. A standard password reset.
Complicated
Sense, Analyse, Respond
Expert analysis. e.g. Network capacity planning.
Complex
Probe, Sense, Respond
Small experiments. e.g. A new product for SMEs.
Chaotic
Act, Sense, Respond
Stabilise first. e.g. A major outage.
Match the method to the problem. Agile for complex.
Day 08 / 100 · Agile foundations · Team Topologies basics
Design teams for flow.
Team Topologies, from Matthew Skelton and Manuel Pais, describes four team types, each shaped to keep cognitive load manageable.
Stream-aligned
The Main Work
Owns a flow of change for a product or customer journey, end to end.
Platform
Self-Service
Provides internal services other teams use without waiting.
Enabling
Coaching
Helps other teams pick up new skills, then steps back.
Complicated subsystem
Deep Specialism
Owns a part that needs rare expertise, like a call-routing engine.
Limit the load. Clarify how teams work together.
Day 09 / 100 · Agile foundations · Agile in regulated environments
Compliance is a requirement.
Regulation isn't a reason to abandon Agile. It's a set of requirements, and requirements belong in the backlog.
Build it into Done
Practice 01
POPIA and security checks are part of the Definition of Done.
IN PRACTICE
No review, not done.
Traceability
Practice 02
Link stories to the requirements and approvals behind them.
IN PRACTICE
Audit trail by default.
Involve early
Practice 03
Legal and compliance join refinement, not just the final sign-off.
IN PRACTICE
Questions before code.
Automate evidence
Practice 04
Pipeline logs, test results and approvals captured automatically.
IN PRACTICE
Evidence without paperwork.
Compliance in every sprint, not at the end.
Day 10 / 100 · Agile foundations · Agile in SMEs
Small team. Light process.
Most Agile guidance is written for big companies. Small teams need the core ideas, not the full apparatus.
Keep the core
The Essentials
A goal, a visible board, a regular review with customers and a retro.
Many hats
One Person, Several Roles
The product owner is often also the PM. Fine, if you know which hat you're wearing.
Fractional help
Part-Time Expertise
A part-time Scrum Master or coach can set up habits without a full-time hire.
Keep what helps. Drop what doesn't.
Module 2Scrum done rightDays 11–20
Day 11 / 100 · Scrum done right · Scrum on one page
Scrum on one page.
The official Scrum Guide is short. Its core fits on one page. Everything else is a practice you chose to add.
Product Owner
3 Accountabilities
Maximises value. Owns the backlog order.
Scrum Master
Makes Scrum work. Coaches team and organisation.
Developers
Build a usable Increment every Sprint.
The Sprint
5 Events
One month or less. Holds all the others.
Sprint Planning
Why, what and how.
Daily Scrum
15 minutes. Toward the goal.
Sprint Review
Inspect the Increment with stakeholders.
Retrospective
Improve how the team works.
Product Backlog
3 Artifacts
Commitment: the Product Goal.
Sprint Backlog
Commitment: the Sprint Goal.
Increment
Commitment: the Definition of Done.
Three accountabilities. Five events. Three artifacts. That's it.
Day 12 / 100 · Scrum done right · Sprint planning that works
Why, what, how. In that order.
Sprint Planning answers three questions. Teams that start with “what” end up with a list. Teams that start with “why” end up with a goal.
Why
The Sprint Goal
“What's the most valuable thing we can achieve this sprint?”
The Product Owner proposes. The team shapes it.
What
The Work
“Which items get us to that goal, given our real capacity?”
Leave, public holidays and support load included.
How
The Plan
“How will we build it? Plan the first few days in detail.”
The Developers own this part.
Why, what, how. In that order.
Day 13 / 100 · Scrum done right · Sprint goals
One sentence. One outcome.
A sprint goal says why the sprint matters. It gives the team focus, and room to flex the details when reality intervenes.
Not A Goal
A Goal
“Complete tickets 412, 415, 418 and 420.”
“Customers can pay invoices by card in the portal.”
“Work on the billing epic.”
“Finance can reconcile card payments without manual exports.”
“Do as much as we can.”
“Prove the new SIP provider handles our peak call load.”
“Fix bugs.”
“Cut failed porting requests by fixing the top three causes.”
One sentence. One outcome. Room to flex.
Day 14 / 100 · Scrum done right · The daily scrum
Not a status meeting.
The Daily Scrum is fifteen minutes for the Developers to inspect progress toward the sprint goal and plan the next day.
Status Meeting
Daily Scrum
Round the room: yesterday, today, blockers.
Walk the board right to left: what's closest to done?
Everyone reports to the Scrum Master.
Developers talk to each other.
Problems get solved in the meeting.
Spot problems. Solve them straight after.
Thirty minutes, whenever.
Fifteen minutes, same time, same place.
Plan the day. Toward the goal. In fifteen.
Day 15 / 100 · Scrum done right · Sprint review
A review, not a recital.
The Sprint Review is a working session with stakeholders to inspect what was built and decide what comes next.
Invite the right people
Do
Customers, support, sales. The people who'll live with it.
INSTEAD OF
Instead of the same three managers.
Show working software
Do
The real thing, running, that people can try.
INSTEAD OF
Instead of slides about it.
Adapt the backlog
Do
Decide together what changes as a result.
INSTEAD OF
Instead of just nodding.
Talk about the context
Do
What's changed in the market, budget or timeline.
INSTEAD OF
Instead of pretending nothing moved.
Working software. Real people. Real feedback.
Day 16 / 100 · Scrum done right · Retrospectives
Retros that change something.
A retrospective is only as good as the change it produces. Keep the structure simple and the follow-through relentless.
01
Gather data
What happened this sprint? Facts before opinions.
02
Find the why
Look for patterns and causes, not culprits.
03
Pick one change
One experiment, one owner, one way to tell if it worked.
04
Check it next time
Open the next retro by reviewing the experiment.
One change. Owned. Checked next time.
Day 17 / 100 · Scrum done right · The Scrum Master role
Coach, not secretary.
The Scrum Master is accountable for the team's effectiveness. They serve three groups, and administration isn't one of them.
The team
Self-Management
Coaches the team to manage itself, remove its own blockers and focus on value.
The Product Owner
Backlog And Goals
Helps with product goals, backlog techniques and stakeholder collaboration.
The organisation
System Blockers
Leads adoption and removes blockers the team can't fix on its own.
Serve the team. Change the system.
Day 18 / 100 · Scrum done right · Product Owner accountabilities
One backlog. One voice.
The Product Owner is accountable for maximising the value of the team's work. That means real authority, not order-taking.
The Product Goal
Owns
The longer-term objective the backlog works toward.
IN PRACTICE
One clear goal, shared.
Backlog order
Owns
What comes next, and what doesn't come at all.
IN PRACTICE
Can say no, and does.
Transparency
Owns
A backlog everyone can see and understand.
IN PRACTICE
No hidden priorities.
Stakeholder input
Owns
Many voices in, one ordered backlog out.
IN PRACTICE
The team hears one voice.
One backlog. One order. One accountable person.
Day 19 / 100 · Scrum done right · Backlog refinement
Little and often.
Refinement is ongoing work, not a Scrum event. Its job is to make the next few sprints' worth of items clear enough to plan.
01
Clarify
What's the problem, who's it for, how will we know it's done?
02
Split
Break big items into slices that fit a sprint.
03
Size
A rough estimate, enough to plan with.
04
Order
The Product Owner adjusts priorities as clarity grows.
Refine the top. Two sprints ahead. Little and often.
Day 20 / 100 · Scrum done right · Common Scrum anti-patterns
Six ways Scrum goes wrong.
Most struggling Scrum teams show the same handful of patterns. Each has a clear fix.
01
Mini-waterfall sprints
Design sprint, build sprint, test sprint. Fix: finish slices end to end.
02
Constant carry-over
Half the sprint rolls over every time. Fix: plan to real capacity.
03
Scope churn
New work added daily. Fix: a goal, and changes through the PO.
04
Absent Product Owner
Nobody can answer questions. Fix: agreed PO time with the team.
05
No Definition of Done
“Done” means different things. Fix: write it down, together.
06
Retro without action
Same complaints every sprint. Fix: one change, checked next time.
Spot one pattern. Fix one pattern. Repeat.
Module 3Kanban & flowDays 21–30
Day 21 / 100 · Kanban & flow · Visualise the work
You can't fix what you can't see.
Kanban starts with a board that shows all the work, exactly as it really flows. Not the process you wish you had.
Map the real steps
Step 01
The columns work actually passes through, including waiting.
EXAMPLE
To do, build, waiting for review, test, done.
One card per item
Step 02
Every piece of work gets a card. No invisible jobs.
EXAMPLE
Including “quick favours.”
All work types
Step 03
Projects, support, maintenance and admin on one board.
EXAMPLE
Colour or lane by type.
Visible policies
Step 04
What it takes to move a card from one column to the next.
EXAMPLE
Written at the top of each column.
Map the work as it is, not as it should be.
Day 22 / 100 · Kanban & flow · WIP limits
Stop starting. Start finishing.
Limiting work in progress feels slower. It's the single most reliable way to make work flow faster.
Why it works
Less Switching
Less context switching, faster finishes, and problems that surface instead of hiding.
How to set it
Start, Then Tune
Start near the number of people in each column. Adjust after a few weeks of data.
When you hit it
Help, Don'T Start
Help finish something already in progress before pulling anything new.
Stop starting. Start finishing.
Day 23 / 100 · Kanban & flow · Flow metrics
Four numbers that matter.
The Kanban Guide names four flow metrics. Together they tell you how work actually moves, with no estimates needed.
WIP
Work In Progress
Items started but not yet finished.
Throughput
Finished Per Week
How many items finish in a period.
Cycle time
Start To Finish
How long each finished item took.
Work item age
Still Going
How long in-progress items have been going.
Four numbers tell you how work really flows.
Day 24 / 100 · Kanban & flow · Cycle time vs lead time
Fast for you. Slow for them.
Cycle time measures how fast the team works. Lead time measures how long the customer waits. They can tell very different stories.
Requested
Customer asks
Started
Work begins
Done
Meets Definition of Done
Delivered
Customer has it
Lead time: what the customer feels
Cycle time
Customers feel lead time. Teams control cycle time.
Day 25 / 100 · Kanban & flow · Little's Law
Want it faster? Start less.
One simple equation explains why limiting work in progress speeds delivery up, without anyone working harder.
Average cycle time = average WIP ÷ average throughput
Little'S Law
Holds for averages over a stable period, when work that starts eventually finishes. Proved by John Little in 1961.
Worked Example
20 items in progress, 5 finished a week. Average: 4 weeks each.
Cut WIP to 10 items, same 5 a week. Average: 2 weeks each.
Want it faster? Start less.
Day 26 / 100 · Kanban & flow · Classes of service
Not all work is equally urgent.
Classes of service set explicit policies for different kinds of urgency, so the team doesn't re-argue priority on every card.
Expedite
Drop Everything
Real emergencies, like a live outage. Limit: one at a time.
Fixed date
Hard Deadline
Costly if late: a regulatory change, a porting cut-over date.
Standard
Most Work
Taken roughly in order, within normal flow.
Intangible
Matters Later
No deadline yet, but ignore it and it bites: upgrades, tech debt.
If everything's urgent, nothing is.
Day 27 / 100 · Kanban & flow · Blockers and ageing work
Old work is a warning.
Items that sit still get more expensive every day. Make blockers and age impossible to ignore.
Mark blockers
Habit 01
A visible tag with the reason and the date it started.
LOOKS LIKE
“Blocked: vendor test env, 3 days.”
Show age
Habit 02
Days in progress on every card, updated daily.
LOOKS LIKE
Old cards stand out.
Swarm the oldest
Habit 03
Walk the board from the right. Oldest items get help first.
LOOKS LIKE
Daily Scrum, right to left.
Learn from blockers
Habit 04
Group blocker reasons monthly and fix the common causes.
Day 29 / 100 · Kanban & flow · Service level expectations
Answer “when?” before they ask.
A service level expectation (SLE) says how long a typical item should take, based on your own history, not a guess.
01
Collect
Cycle times for your last 30 to 50 finished items.
02
Pick a percentile
Most teams use the 85th percentile.
03
State it
“85% of our items finish within 8 days.”
04
Use it daily
Items nearing the SLE get attention before they breach it.
Based on data. Used every day.
Day 30 / 100 · Kanban & flow · Scrumban
Blend on purpose.
Scrumban, a term coined by Corey Ladas, combines Scrum's rhythm with Kanban's flow. It works when you choose each piece deliberately.
Keep from Scrum
Rhythm
A sprint goal, the review with stakeholders, and the retrospective.
Add from Kanban
Flow
WIP limits, flow metrics, pulling work only when there's capacity.
Drop deliberately
What Doesn'T Help
Maybe story points, or a fixed sprint commitment. Decide as a team.
Blend on purpose. Not by drift.
Module 4Backlog & requirementsDays 31–40
Day 31 / 100 · Backlog & requirements · User stories
A story is a promise to talk.
A user story isn't a mini-specification. It's a placeholder for a conversation, built on three Cs described by Ron Jeffries.
Card
The Short Version
“As a business customer, I want to download my invoice as a PDF, so I can send it to my accountant.”
Who, what and why. Short enough for a card.
Conversation
The Detail
“Which invoices? Just the latest? What must the PDF show?”
The details come from talking, not from the card.
Confirmation
How We'Ll Know
Acceptance criteria agreed before building (Day 33).
The conversation, written down as tests.
Card, conversation, confirmation.
Day 32 / 100 · Backlog & requirements · INVEST
Six checks for a good story.
Bill Wake's INVEST gives a quick quality check for any backlog item. Use it as a lens in refinement, not a gate.
I
Independent
Can be built and released without waiting on another story.
N
Negotiable
The details are open to discussion, not fixed in advance.
V
Valuable
Delivers something a user or customer actually cares about.
E
Estimable
The team understands it well enough to size it.
S
Small
Fits comfortably in a sprint, ideally in a few days.
T
Testable
Clear enough that you can tell when it's done.
Six checks for a story worth building.
Day 33 / 100 · Backlog & requirements · Acceptance criteria and BDD
Agree what done looks like.
Behaviour-driven development, introduced by Dan North, writes acceptance criteria as concrete examples in plain language.
Scenario: Customer downloads an invoice
Given I'm logged in as a business customer
And I have an invoice for August
When I choose “Download PDF”
Then the August invoice downloads as a PDF
And it shows our VAT number
Examples over rules
Concrete cases catch what abstract rules miss.
Written together
Product Owner, developer and tester: the three amigos.
Becomes the test
The same words can drive automated tests.
Examples first. Written together. Tested for real.
Day 34 / 100 · Backlog & requirements · Story splitting patterns
Slice it vertically.
Mike Cohn's SPIDR gives five ways to split a big story into smaller ones that each still deliver something usable.
S
Spike
Split off the research into a timeboxed spike (Day 38).
P
Paths
Split by path: happy path first, alternatives later.
I
Interfaces
Web first, mobile app later. One channel at a time.
D
Data
Support one data type or source first, add others later.
R
Rules
Build the core first, add business rules and limits later.
✕
Not by layer
A “UI story” and a “database story” deliver nothing alone.
Slice vertically. Every slice usable.
Day 35 / 100 · Backlog & requirements · Epics and story maps
See the whole journey.
Jeff Patton's story mapping lays the customer journey across the top and slices releases underneath. Flat backlogs hide the gaps.
BACKBONE
RELEASE 1 WALKING SKELETON
RELEASE 2
Sign up
Set up numbers
Make calls
Pay the bill
Online form
Pick one number
Calls on the app
View invoice
ID verification
Port existing numbers
Call forwarding
Pay by card
See the whole journey. Release the thinnest path.
Day 36 / 100 · Backlog & requirements · Definition of Ready (and its dangers)
Ready, or blocked?
A Definition of Ready can help teams start work with enough clarity. It can also quietly bring back waterfall. It isn't part of Scrum.
Helpful
A Light Guide
Clear value, draft acceptance criteria, small enough, dependencies known.
The danger
A Stage Gate
It grows into sign-offs and full designs. Stories bounce back. Waterfall returns.
Better
A Conversation
Use it in refinement to ask good questions, not to reject work at the door.
A guide for talking, not a gate for blocking.
Day 37 / 100 · Backlog & requirements · Definition of Done
Done means done.
The Definition of Done is the quality standard every Increment must meet. In Scrum it's a formal commitment, not a nice-to-have.
Reviewed and merged
Check
Peer reviewed, merged to main, pipeline green.
EXAMPLE
No “works on my machine.”
Tested
Check
Automated tests pass and acceptance criteria are met.
EXAMPLE
Evidence, not assurance.
Safe
Check
Security checks run. POPIA review where personal data is touched.
EXAMPLE
Compliance built in (Day 9).
Releasable
Check
Deployed to staging or production. Help docs updated.
EXAMPLE
Usable, not just finished.
Done means usable. Written down. Every time.
Day 38 / 100 · Backlog & requirements · Spikes
Buy knowledge, not code.
A spike is a short, timeboxed piece of work to answer a question, so the team can make a decision or estimate with confidence.
01
Frame the question
One specific question the spike will answer.
02
Timebox it
Usually one to three days. Stop when time's up.
03
Build to learn
A throwaway prototype, a test, a proof of concept.
04
Share the answer
A decision, and the follow-up stories it creates.
One question. A timebox. A decision.
Day 39 / 100 · Backlog & requirements · Bugs in the backlog
Triage fast. Close honestly.
A backlog full of old bugs isn't a record of quality. It's noise that hides the bugs that matter.
Fix now
Decision
Found in this sprint's own work. Not a backlog item, just finish it.
Upgrades, refactoring and infrastructure work compete with features for space. Make the case in terms the Product Owner can weigh.
Tie it to value
Say Why
“So customers get security fixes within days, not months.”
Business terms, not technical ones.
Keep it visible
Same Backlog
Technical items in the main backlog, ordered with everything else.
Hidden work never gets prioritised.
Budget for it
Every Sprint
A steady share of capacity, or built into each story.
Small and constant beats big and rare.
Explain the why. Keep it visible. Pay as you go.
Module 5Estimation & forecastingDays 41–50
Day 41 / 100 · Estimation & forecasting · Why estimates go wrong
Estimates are guesses.
Estimates miss for predictable reasons. Knowing them won't make you psychic, but it will make you less surprised.
01
Planning fallacy
We picture the best case. Kahneman and Tversky named it in 1979.
02
Unknown unknowns
The problems you can't see until you start.
03
Anchoring
The first number said out loud sticks.
04
Negotiated down
Estimates bargained to fit the date someone wants.
05
Hidden work
Reviews, testing, deploys and docs left out.
06
Interruptions
Support, meetings and leave eating capacity.
Estimates are guesses. Treat them like it.
Day 42 / 100 · Estimation & forecasting · Story points, honestly
Points aren't hours.
Story points were meant as a rough, relative sense of size. Ron Jeffries, often credited with inventing them, has since said he regrets how they're used.
What they are
Relative Size
Effort, complexity and uncertainty compared to other work. Specific to one team.
What they aren't
Not Time Or Output
Not hours. Not productivity. Not comparable between teams.
Where they help
The Conversation
A 3 against a 13 exposes a misunderstanding worth talking about.
The conversation is the value. The number isn't.
Day 43 / 100 · Estimation & forecasting · Planning poker
The gaps are the gold.
Planning poker, created by James Grenning and popularised by Mike Cohn, uses simultaneous votes to surface different understandings.
01
Read the story
The PO explains it. Quick questions only.
02
Vote privately
Everyone picks a card at the same time.
03
Talk about extremes
The highest and lowest explain their thinking.
04
Re-vote once
Then go with the result. Don't chase unanimity.
Big gaps are gold. Small gaps don't matter.
Day 44 / 100 · Estimation & forecasting · #NoEstimates
Count, don't estimate.
#NoEstimates, championed by Woody Zuill and Vasco Duarte, asks whether the effort of estimating pays off. Often, counting items works as well.
The idea
Small And Similar
Split work into small items of similar size. Count items instead of sizing them.
What you need
The Basics
Reasonably stable flow, consistently small stories, and throughput history.
What it isn't
Not “No Dates”
It's not refusing to forecast. People still need to know when.
Ward Cunningham coined “technical debt” in 1992. Martin Fowler's quadrant shows that not all debt is taken on the same way.
Deliberate and prudent
“We'll ship now and fix it properly next sprint.” A conscious trade-off.
Deliberate and reckless
“No time for design.” Shortcuts nobody plans to fix.
Inadvertent and prudent
“Now we know how we should have built it.” Learning shows the debt.
Inadvertent and reckless
The team didn't know good practice. Debt nobody noticed taking on.
Know the interest. Pay the expensive debt first.
Day 70 / 100 · Engineering practices · Documentation that stays alive
Docs that stay true.
Documentation dies when it lives far from the work. Keep it close to the code, review it like code, and use it for real.
Docs as code
In The Repo
Markdown next to the code, changed in the same pull request.
Decision records
Why, Not Just What
Short ADRs recording why a choice was made (Michael Nygard).
Runbooks
Tested In Drills
Operational steps, proven by actually following them.
README first
Run It In Ten Minutes
What it does, how to run it, who owns it, how to deploy.
Close to the code. Reviewed like code. Used for real.
Module 8ScalingDays 71–80
Day 71 / 100 · Scaling · When to scale
Scale last. Simplify first.
Scaling frameworks manage the complexity of many teams. Before adding that machinery, check whether you can remove the complexity instead.
Is one team enough?
Ask
A single team of up to about ten people ships most SME products.
BEFORE SCALING
Stay small if you can.
Can you cut dependencies?
Ask
Scaling frameworks mostly exist to manage dependencies.
BEFORE SCALING
Remove them first (Day 52).
One product or several?
Ask
Separate products can often run as separate, independent teams.
BEFORE SCALING
No framework needed.
Where's the bottleneck?
Ask
If it's decisions or approvals, more teams make it worse.
BEFORE SCALING
Fix the flow first.
Scale last. Simplify first.
Day 72 / 100 · Scaling · Scrum of Scrums
Short, focused, cross-team.
The Scrum of Scrums, first used by Jeff Sutherland and Ken Schwaber in 1996, gets representatives from each team together to clear cross-team blockers.
The Scaled Agile Framework (SAFe), created by Dean Leffingwell in 2011, is the most widely adopted scaling framework, and the most argued about.
Alignment
What It Does Well
Many teams working toward shared objectives.
Planning together
Big-room planning surfaces dependencies early.
A starting structure
Gives large organisations a map to begin with.
Heavy
Fair Criticisms
Many roles, layers and events to run.
Top-down risk
Can reinforce central control over team autonomy.
Adopted by certificate
Sometimes chosen for the badge, not the problem.
Borrow what solves your problem. Skip the rest.
Day 74 / 100 · Scaling · LeSS
More with less.
Large-Scale Scrum (LeSS), from Craig Larman and Bas Vodde, scales by keeping Scrum simple: several teams, but one of almost everything else.
One Product Owner
One Voice
One person owns priorities for the whole product.
One backlog
One Order
All teams pull from the same ordered list.
One Sprint
One Rhythm
Teams plan, review and deliver together.
One Done
One Standard
A shared Definition of Done for the whole product.
One product. One backlog. Many teams.
Day 75 / 100 · Scaling · Myths of the Spotify model
Copy principles, not org charts.
Henrik Kniberg and Anders Ivarsson's 2012 paper on how Spotify worked was never meant as a framework. Its authors have said so repeatedly.
Myth
Reality
“The Spotify model is a framework.”
A 2012 snapshot of how some teams worked.
“Rename teams to squads and tribes.”
The culture of trust mattered, not the names.
“Spotify still works exactly like this.”
Spotify kept changing, as its authors said it would.
“Autonomy means no alignment.”
The idea was aligned autonomy: both together.
Copy the principles, not the org chart.
Day 76 / 100 · Scaling · Program increments
Plan together. Adapt together.
A program or planning increment is a fixed stretch, often eight to twelve weeks, where several teams plan, deliver and review against shared objectives.
01
Set the horizon
Eight to twelve weeks, same dates for every team.
02
Shared objectives
What the teams must achieve together, not just separately.
03
Plan together
In one room or one call, so dependencies surface.
04
Review and adapt
At the end, inspect results and how you worked.
Commit to objectives, not every story.
Day 77 / 100 · Scaling · Cross-team planning
Plan in the room.
Big-room planning puts every team together, physically or online, for a day of shared context, team planning and honest confidence checks.
Context first
Part 01
Leaders share the vision, priorities and constraints.
LOOKS LIKE
Thirty minutes, not three hours.
Teams plan
Part 02
Breakouts where each team drafts its plan.
LOOKS LIKE
With the people who'll do it.
One dependency wall
Part 03
Every dependency visible, linked team to team.
LOOKS LIKE
Physical or on a whiteboard.
Confidence vote
Part 04
Every team rates its confidence in the plan, 1 to 5.
LOOKS LIKE
Low scores get discussed.
Plan in the room. Vote on confidence.
Day 78 / 100 · Scaling · Portfolio Kanban
Limit WIP at the top, too.
Portfolio Kanban puts whole initiatives on a board with work-in-progress limits, so leadership starts fewer things and finishes more.
Funnel
WIP ∞
Ideas
Reviewing
WIP 5
Card payments
Analysing
WIP 3
Number porting v2
Implementing
WIP 4
Self-service portal
SMS alerts
Done
Billing revamp
Start fewer. Finish more. At every level.
Day 79 / 100 · Scaling · OKRs across teams
Outcomes, not outputs.
Objectives and key results, developed by Andy Grove at Intel and popularised by John Doerr, align many teams on what success looks like.
Objective
Where We'Re Going
“Make switching to us painless for small businesses.”
Qualitative and motivating.
Key results
How We'Ll Know
“90% of number ports done within [X] working days.”
Three to five measurable outcomes.
Aligned
Not Cascaded
Teams propose OKRs that support the company's.
Bottom-up and top-down meet.
Outcomes, not outputs. Aligned, not cascaded.
Day 80 / 100 · Scaling · Avoiding scaling bureaucracy
Every quarter, remove something.
Scaling adds process one reasonable step at a time. Nobody decides to build a bureaucracy. It accumulates unless someone prunes it.
01
Meeting sprawl
Coordination meetings multiply. Fix: merge or cut one a quarter.
02
Role inflation
New titles for every gap. Fix: give teams the responsibility instead.
03
Approval layers
Sign-offs stacked on sign-offs. Fix: automate checks in the pipeline.
04
Reporting overhead
Reports about reports. Fix: one shared board everyone can read.
05
Tool sprawl
Five tools tracking the same work. Fix: one source of truth.
06
Framework worship
Following the book over the goal. Fix: ask “what problem does this solve?”
Add slowly. Remove regularly.
Module 9Teams & coachingDays 81–90
Day 81 / 100 · Teams & coaching · Team formation
Teams take time.
Bruce Tuckman's 1965 model describes the stages new teams go through. Every reshuffle sends a team back to the start.
01
Forming
Polite, unclear, dependent on the leader.
02
Storming
Friction about roles, approaches and priorities.
03
Norming
Agreements form. Trust starts to build.
04
Performing
Work flows. The team solves its own problems.
Stable teams. Give them time to form.
Day 82 / 100 · Teams & coaching · Psychological safety in delivery
Make bad news safe.
Amy Edmondson's research, and Google's Project Aristotle, found psychological safety was central to team performance. In delivery it shows up in how early people raise problems.
Say “I don't know”
Leaders First
“I got that forecast wrong. Here's what I missed.”
Leaders go first so others can follow.
Thank the messenger
Reward Bad News
“Thanks for flagging it now, not in release week.”
Early warnings are a gift.
Learn, don't blame
Blameless
Ask how the system allowed it (Day 68).
Mistakes become lessons, not verdicts.
Make bad news safe to say early.
Day 83 / 100 · Teams & coaching · Self-organisation
Clear boundaries. Real authority.
Self-organising teams still need clarity on who decides what. Jurgen Appelo's delegation board makes those boundaries explicit.
Tools and practices
Decision
How the team builds, tests and works together.
WHO DECIDES
Team decides.
The sprint plan
Decision
How much to take on and how to do it.
WHO DECIDES
Team decides.
Hiring a teammate
Decision
Who joins the team.
WHO DECIDES
Team and manager agree.
Product priorities
Decision
What gets built next.
WHO DECIDES
PO decides, team consulted.
Clear boundaries. Real authority inside them.
Day 84 / 100 · Teams & coaching · Facilitation skills
Every voice. Decisions out.
Good facilitation turns a room of opinions into a decision everyone understands. It's a learnable skill, not a personality trait.
Purpose
What We'Ll Leave With
Say the outcome at the start: a decision, a plan, a list.
Structure
Timeboxes And Formats
A clear agenda, timeboxes, and a format suited to the goal.
Include everyone
Quiet Voices First
Silent writing before discussion. Rounds, not free-for-alls.
Close properly
Who, What, When
End with decisions, owners and dates, written down.
Clear purpose. Every voice. Decisions out.
Day 85 / 100 · Teams & coaching · Handling conflict
Fight about ideas, early.
The Thomas-Kilmann model describes five ways people handle conflict. None is always right. The skill is choosing on purpose.
Competing
Firm on your position.
Emergencies, or clear ethical lines.
Collaborating
Find an answer that meets both needs.
Important issues, when there's time.
Compromising
Each side gives something up.
When time is short and stakes are moderate.
Avoiding
Step back for now.
Trivial issues, or when emotions need to cool.
Accommodating
Let the other side have it.
When it matters far more to them.
Choose how you handle it. Don't just react.
Day 86 / 100 · Teams & coaching · The coaching stance
Ask more than you tell.
Lyssa Adkins' work on coaching Agile teams describes several stances. Good coaches switch between them deliberately.
Teacher
Share Knowledge
Explain a practice the team hasn't met yet.
Mentor
Share Experience
“Here's what I've seen work, and what didn't.”
Facilitator
Hold The Process
Guide the conversation, not its outcome.
Coach
Ask, Don'T Tell
“What options do you see? What would you try?”
Know which hat. Ask more than you tell.
Day 87 / 100 · Teams & coaching · Remote and hybrid teams
Include by default.
Distributed teams work well when the way of working assumes nobody is in the room. They struggle when the office is the default.
Write it down
Habit 01
Decisions live in writing, where everyone can find them.
IN PRACTICE
The channel, not the corridor.
Core hours
Habit 02
A few agreed hours for live collaboration each day.
IN PRACTICE
Flexible time around them.
Remote-first meetings
Habit 03
If one person is remote, everyone joins from their own laptop.
IN PRACTICE
One room, one experience.
Deliberate connection
Habit 04
Time together that isn't about work.
IN PRACTICE
It won't happen by accident.
Write it down. Include by default.
Day 88 / 100 · Teams & coaching · Working agreements
Agree how you'll work.
Working agreements are the team's own rules for working together. They turn silent frustrations into explicit, changeable choices.
Example Working Agreements
01
Core hours are 10:00 to 15:00.
02
Pull requests reviewed within one working day.
03
Decisions go in the team channel.
04
No expectation to reply after 18:00. Urgent means call.
05
Cameras optional. Say so if you're stepping away.
Written together
By the team, not handed down.
Short
Five to ten. Enough to remember.
Revisited
Checked at retros. Changed when needed.
Written together. Short. Revisited.
Day 89 / 100 · Teams & coaching · Team health checks
Ask. Watch. Act.
A regular team health check, like the traffic-light model Spotify shared in 2014, turns “how's the team?” into a trend you can act on.
Delivering value
Example Check · This Quarter
Easy to release
Fun
Learning
Mission
Pace
Support
Teamwork
● Good
● Some problems
● Not good
Ask regularly. Watch the trends. Act on red.
Day 90 / 100 · Teams & coaching · Leading without authority
Influence is earned.
Delivery managers, Scrum Masters and product people rarely have direct authority. Their influence comes from trust, relationships and good framing.
Credibility
Do What You Say
Deliver on small promises, consistently.
Trust is built in small deposits.
Relationships
Know What They Need
Understand each stakeholder's goals and pressures.
Before you need anything from them.
Framing
Their Goals, Not Yours
Connect your ask to what they care about.
“This helps you with…”
Earn influence. Spend it carefully.
Module 10TransformationDays 91–100
Day 91 / 100 · Transformation · Why transformations fail
Change the system, not the rituals.
John Kotter's 1995 article on why transformation efforts fail still reads like a diagnosis of most Agile rollouts. The same six patterns keep appearing.
01
Big-bang rollout
Every team at once, ready or not.
02
Rituals only
New meetings, same way of working (Day 1).
03
Leaders exempt
Teams change. Leadership habits don't.
04
Old incentives
Annual budgets and individual bonuses untouched.
05
Measuring adoption
Counting trained teams, not better outcomes.
06
Coaches leave
External help ends and nothing internal remains.
Change the system, not just the ceremonies.
Day 92 / 100 · Transformation · Starting small
Small start. Real problem.
The most durable changes start with one team solving one real problem well, then spread because others want what it got.
01
One team
A team with a real, visible delivery problem.
02
One outcome
One measure to improve: lead time, quality, predictability.
03
Ninety days
Real support, a coach, and permission to experiment.
04
Let it spread
Share results openly. Let other teams ask to join.
Small start. Real problem. Let success spread.
Day 93 / 100 · Transformation · Measuring agility
Measure what people feel.
The only point of becoming more Agile is better outcomes. Measure those, not how Agile things look.
Vanity
Outcome
Number of teams “doing Agile.”
Lead time from idea to customer.
Certifications earned.
Deployment frequency and change failure rate.
Ceremonies held on time.
Customer satisfaction with what shipped.
A maturity-model score.
The team health trend (Day 89).
Measure outcomes customers and teams actually feel.
Day 94 / 100 · Transformation · Leadership's role
Leaders go first.
Teams watch what leaders do far more closely than what they say. Some changes, like funding and incentives, only leaders can make.
Model it
Do It Visibly
Use a visible board. Limit your own WIP. Admit mistakes.
Fix the system
Only You Can
Funding, approvals, incentives and structure.
Go and see
Reviews, Not Reports
Attend sprint reviews. See working software yourself.
Protect focus
No Priority Whiplash
Shield teams from constant changes of direction.
Leaders go first. Then fix what only they can.
Day 95 / 100 · Transformation · The change curve
Expect the dip.
The change curve, adapted from Elisabeth Kübler-Ross's work on grief, describes how people move through change. Performance usually drops before it improves.
Early: inform. Explain why, often.
In the dip: support. Expect it. Don't quit.
Climbing: guide. Celebrate small wins.
Expect the dip. Support people through it.
Day 96 / 100 · Transformation · Agile with HR, Legal and Finance
Invite the rest in.
Agile teams inside a traditional organisation hit walls in HR, Legal, Finance and Procurement. Those walls only move if those teams are part of the change.
HR
Partner
Individual targets and ticket counts undermine teamwork.
CHANGE TO
Team goals, peer feedback.
Legal
Partner
Late reviews force big-batch delivery.
CHANGE TO
Involved in refinement (Day 9).
Finance
Partner
Annual project budgets lock in scope.
CHANGE TO
Fund teams and stages (Day 58).
Procurement
Partner
Fixed-price contracts for uncertain work.
CHANGE TO
Contracts for collaboration (Day 59).
Agile stops at the org chart. Unless you invite them in.
Day 97 / 100 · Transformation · The fractional Scrum Master model
Expert help, part-time.
Many SMEs can't justify a full-time Scrum Master per team. A fractional model brings experienced help for a few days a week.
What it is
Shared Expertise
An experienced Scrum Master working part-time across two or three teams or companies.
When it fits
Small And Starting
Small teams, early in adoption, or where budget is tight.
What to watch
Availability
Fixed days, clear outcomes, and a plan to hand over.
Expert help, part-time, with a handover plan.
Day 98 / 100 · Transformation · AI in delivery
AI drafts. Teams decide.
AI can take a lot of drafting and summarising work off delivery teams. The Prompting Skills and AI Enablement playbooks go deeper.
Refinement
Use
Draft stories and Given/When/Then scenarios to discuss.