Software Development Strategy: The Complete Guide¶

Most software projects fail for one of two reasons: they build the wrong thing right, or they build the right thing wrong.

Building the wrong thing right means you execute perfectly — on time, on budget, with clean code — but the product solves a problem nobody actually has. Building the right thing wrong means you deeply understand the user's pain but your delivery is so slow, brittle, and expensive that the opportunity is gone before the product ships.

The framework that fixes both failure modes: Design Thinking + Lean + Agile — applied together, not picked from a menu.

Why Methodology Alone Is Never Enough¶

Before diving into the frameworks, it's worth understanding why so many teams adopt Agile, Lean, or Design Thinking — and still fail.

The problem is cargo culting: performing the rituals without understanding the purpose.

  CARGO CULT AGILE:
  ✓ We do two-week sprints
  ✓ We have daily standups
  ✓ We write user stories
  ✓ We have a Scrum Master
  ✗ We never talk to users
  ✗ We never validate assumptions
  ✗ We never say "we built the wrong thing"

  Result: fast delivery of things nobody asked for

Methodology is not a substitute for thinking. The frameworks in this guide are tools that help you think better — about what problem to solve, what solution to build, and how to build it sustainably.

The sequence matters:

   WHY                  WHAT                  HOW
┌────────────┐      ┌───────────────┐     ┌───────────────┐
│   DESIGN   │  →   │     LEAN      │  →  │     AGILE     │
│  THINKING  │      │               │     │               │
│            │      │               │     │               │
│ Discover   │      │  Validate &   │     │ Deliver &     │
│ the real   │      │  build the    │     │ improve       │
│ problem    │      │  right thing  │     │ continuously  │
└────────────┘      └───────────────┘     └───────────────┘

Skip the first stage and you risk building the wrong thing. Skip the second and you risk committing too early to an unvalidated solution. The third stage without the first two is precisely how you end up with the cargo cult.

Part 1: Design Thinking — Discovering the Real Problem¶

Design Thinking is a human-centred approach to problem-solving. It was popularised by IDEO and Stanford's d.school and is built on one core belief: the best solutions come from deeply understanding the people who experience the problem.

It is not a creative exercise. It is a structured approach to reducing the risk of solving the wrong problem.

The Five Stages¶

  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐
  │EMPATHISE │→ │ DEFINE   │→ │ IDEATE   │→ │PROTOTYPE │→ │   TEST   │
  │          │  │          │  │          │  │          │  │          │
  │Understand│  │Frame the │  │Generate  │  │Build to  │  │Learn from│
  │the human │  │right     │  │many      │  │think,    │  │real      │
  │experience│  │problem   │  │solutions │  │not to    │  │users     │
  │          │  │          │  │          │  │ship      │  │          │
  └──────────┘  └──────────┘  └──────────┘  └──────────┘  └──────────┘

Design Thinking is not linear — you will loop back. Testing reveals new insights that reframe the problem. That's by design.

Stage 1: Empathise — Get Out of the Building¶

Empathy in Design Thinking is not sympathy. It's the rigorous practice of understanding what users actually do, feel, think, and say — not what they tell you they want.

Why this matters: People are famously bad at knowing what they want. Henry Ford allegedly said if he had asked customers what they wanted, they would have said "faster horses." The real insight — a car — required watching how people lived, not taking feature requests.

User Interviews — The Core Empathy Tool¶

A user interview is not a survey. It's a conversation designed to surface behaviour, motivations, and mental models.

The golden rules:

Rule	Why
Ask about the past, not the future	"What did you do last week?" is reliable. "What would you do?" is not.
Ask "why" at least three times	Surface root causes, not surface symptoms
Never ask leading questions	"How frustrating is the checkout process?" assumes frustration
Observe, don't just listen	Watch them do the task — their behaviour contradicts their words
Recruit from the edges	Extreme users (power users, non-users) reveal more than average users

Interview structure (60 minutes):

  0-5 min:   Warm up — who are they, context of their work/life
  5-20 min:  Current workflow — walk me through what you did last time
  20-40 min: Deep dive — why did you do X? What happened when Y?
  40-55 min: Pain points — what's the hardest part? What breaks down?
  55-60 min: Wrap up — what did we miss? Who else should I talk to?

Questions to ask:

  ✅  "Walk me through the last time you had to [do X]."
  ✅  "What did you do when that happened?"
  ✅  "Why was that important to you?"
  ✅  "What was the hardest part of that process?"
  ✅  "What workarounds do you use?"

  ❌  "Would you use a feature that did X?"
  ❌  "How often do you need Y?"
  ❌  "Do you like our current approach to Z?"

Empathy Mapping¶

After interviews, organise observations into an empathy map for each user segment:

  ┌─────────────────────────────────────────────────────────┐
  │                    EMPATHY MAP                           │
  │                   User: [Name/Role]                      │
  ├──────────────────────┬──────────────────────────────────┤
  │       SAYS           │             THINKS               │
  │                      │                                  │
  │ Quotes from the      │ What's on their mind that        │
  │ interview (verbatim) │ they won't say out loud          │
  ├──────────────────────┼──────────────────────────────────┤
  │       DOES           │             FEELS                │
  │                      │                                  │
  │ Observable actions   │ Emotional state — frustrations,  │
  │ and behaviours       │ fears, aspirations               │
  └──────────────────────┴──────────────────────────────────┘

  PAINS: What obstacles, frustrations, and risks do they face?
  GAINS: What outcomes do they want? What would delight them?

Customer Journey Mapping¶

Map the end-to-end experience of your user doing a task — including the parts you don't control:

  JOURNEY: Customer ordering a replacement part online

  Stage:    DISCOVER    →   EVALUATE   →   ORDER    →   WAIT     →   RECEIVE

  Actions:  Googles     →   Checks 3   →   Fills    →   Emails   →   Inspects
            "part #"        websites       long form     support      package

  Thoughts: "Is this    →   "These     →   "Why do  →   "Is it   →   "Finally,
             the right       prices        I need       coming?       but is it
             part?"          vary so       all this     I can't       the right
                             much"         info?"       wait more"    one?"

  Feelings: Uncertain   →   Confused   →   Annoyed  →   Anxious  →   Relieved /
                                                                       Frustrated

  Pain      ← Can't verify compatibility │ Form abandonment │ No proactive updates →
  Points:

This reveals pain points that nobody reports in surveys because they seem "normal" — but they're the exact places where a better solution wins.

Stage 2: Define — Frame the Right Problem¶

After empathising, you have raw observations. The Define stage synthesises them into a clear, actionable problem statement. This is harder than it sounds — most teams jump to solutions before they've properly defined the problem.

Affinity Mapping¶

Group your observations into themes:

  Raw observations on sticky notes:

  "I always have to log in again"     "The report takes 10 minutes to run"
  "I email the file to myself"        "I can't find old orders"
  "The mobile version is broken"      "I have to re-enter the same data"
  "I screenshot the screen to share"  "The export breaks in Excel"

  After grouping:

  ┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐
  │   AUTH / ACCESS │  │   PERFORMANCE   │  │  DATA SHARING   │
  │                 │  │                 │  │                 │
  │ Log in again    │  │ 10 min reports  │  │ Email to self   │
  │ Mobile broken   │  │ Can't find old  │  │ Screenshot      │
  │                 │  │ orders          │  │ Export breaks   │
  │                 │  │                 │  │ Re-enter data   │
  └─────────────────┘  └─────────────────┘  └─────────────────┘

The Point of View Statement¶

A Point of View (POV) statement is a reframeable problem definition:

  FORMAT:
  [User] needs [need] because [insight].

  EXAMPLE:
  "A warehouse manager who approves 50 orders per day needs a way to
  quickly verify order accuracy without switching between 4 systems
  because errors caught late cost 3x more to fix than errors caught
  at the approval stage."

  NOT:
  "We need to build a dashboard." (This is a solution, not a problem)
  "Users want a better UI." (Too vague to act on)

How Might We (HMW) Questions¶

Translate POV statements into opportunity questions that invite ideation:

  POV: Warehouse managers waste 20 minutes per order switching between systems

  HMW questions:
  ✦ HMW reduce the number of systems a manager must check?
  ✦ HMW bring relevant data to the manager instead of them seeking it?
  ✦ HMW make errors obvious before the approval step?
  ✦ HMW give managers confidence to approve faster?
  ✦ HMW eliminate the approval step altogether for low-risk orders?

HMW questions open up the solution space without locking you into one approach. Each question is a different strategic bet.

Stage 3: Ideate — Generate Many Solutions Before Committing¶

Most teams stop at their first good idea. Ideation is about quantity before quality — generating enough options that you can make an informed choice.

Brainstorming Rules¶

  ✅  Defer judgement — no idea is wrong in ideation
  ✅  Go for quantity — 50 ideas in 30 minutes
  ✅  Build on each other — "Yes, and..." not "No, but..."
  ✅  Encourage wild ideas — constraints come later
  ✅  Stay visual — sketch, don't just write

Crazy 8s¶

Each person takes one sheet of paper, folds it into 8 panels, and sketches 8 different ideas in 8 minutes. Quantity and speed kill over-attachment to the first idea.

Dot Voting and Prioritisation¶

After generating ideas, use dot voting to identify what the team finds most promising. Then evaluate against your constraints:

  IDEA EVALUATION MATRIX

                    User Value
                    High │ Low
                  ───────┼───────
  Implementation  High   │  Stars │  Bets  │
  Feasibility     Low    │───────┼────────│
                         │ Quick  │  Skip  │
                         │  Wins  │        │

Stars (High Value, High Feasibility): Do these first
Quick Wins (Low Value, High Feasibility): Do if bandwidth allows
Bets (High Value, Low Feasibility): Worth exploring — prototype first
Skip (Low Value, Low Feasibility): Don't do

Stage 4: Prototype — Build to Learn, Not to Ship¶

A prototype is the cheapest possible way to test an idea with real users. The goal is learning, not production code.

  PROTOTYPE FIDELITY SPECTRUM

  Paper sketch    →    Clickable mockup    →    Coded prototype
  (15 minutes)         (2-3 hours)               (2-3 days)

  Use when:            Use when:                 Use when:
  Testing concept      Testing flow and          Testing technical
  and layout           interaction               feasibility

  Before committing 1 day, test with paper.
  Before committing 1 week, test with a mockup.
  Before committing 1 month, test with a coded prototype.

The prototype mistake

The most common prototype mistake is building too much — polishing the UI, writing clean code, adding real data. This wastes time and creates emotional attachment to a solution before you know if it works. The rule: prototype should take 10x less time than building the real thing.

Paper Prototyping in Practice¶

  Test: a new order approval workflow

  Materials: Paper, scissors, sticky notes, marker
  Time to build: 20 minutes

  Process:
  1. Draw each screen on separate paper
  2. Draw dropdowns on separate slips of paper
  3. Give the stack to a user
  4. Ask them to complete a task: "Please approve this order"
  5. Manually swap paper "screens" as they tap/click
  6. Observe and note where they hesitate, tap wrong, or get confused

  Outcome: You learn more in 30 minutes than from 2 weeks of UX meetings

Stage 5: Test — Learn from Real Users¶

Testing is not QA. It's the process of putting your prototype in front of real users and observing what happens.

The five-user rule: Nielsen Norman Group research shows that testing with 5 users reveals ~85% of usability problems. You don't need 100 users — you need 5, with time to learn between sessions.

  USABILITY TEST STRUCTURE

  Facilitator: Gives tasks, stays silent, takes notes
  Observer:    Watches, records, does not intervene
  User:        Thinks aloud while completing real tasks

  Key tasks to test (for the order approval workflow):
  Task 1: "You've received an order. Please approve it."
  Task 2: "Something looks wrong with this order. What do you do?"
  Task 3: "Find all orders you approved last week."

  What to observe:
  ✦ Where they hesitate (point of confusion)
  ✦ Where they click wrong (mislabelled or misplaced element)
  ✦ What they say while thinking aloud
  ✦ Where they succeed without help (keep this — it works)
  ✦ Where they fail or give up (fix this)

Part 2: Lean — Building the Right Thing¶

Lean methodology originated in the Toyota Production System and was adapted for software by Eric Ries in The Lean Startup (2011). Its core premise: waste is the enemy, and the biggest waste in software is building something nobody uses.

The Seven Wastes of Software Development¶

Toyota identified seven wastes in manufacturing. In software they look like this:

Waste	Manufacturing	Software
Overproduction	Making more parts than needed	Building features no one asked for
Waiting	Parts sitting idle	Code waiting for review, approval, or deployment
Defects	Faulty products	Bugs, rework, missed requirements
Over-processing	More steps than necessary	Unnecessary process, meetings, sign-offs
Inventory	Unfinished parts on the floor	Undeployed code, unstarted stories in backlog
Motion	Unnecessary physical movement	Context switching, tool fragmentation
Transport	Moving parts between stations	Handoffs between teams, departments

The biggest waste you're probably ignoring

The invisible waste in most teams is partially completed work — features that are coded but not tested, tested but not reviewed, reviewed but not deployed. This is work that has cost money but is delivering zero value. Lean calls this WIP (Work In Progress) and says: stop starting, start finishing.

The Build-Measure-Learn Loop¶

The Build-Measure-Learn loop is the engine of Lean product development:

  ┌─────────────────────────────────────────────────────────┐
  │                BUILD-MEASURE-LEARN LOOP                  │
  │                                                          │
  │   ┌──────────┐         ┌──────────┐        ┌──────────┐ │
  │   │          │         │          │        │          │ │
  │   │  BUILD   │────────▶│ MEASURE  │───────▶│  LEARN   │ │
  │   │          │         │          │        │          │ │
  │   │ Minimum  │         │ Real user │        │ Validate │ │
  │   │ testable │         │ behaviour│        │ or pivot │ │
  │   │ thing    │         │ (metrics)│        │          │ │
  │   └──────────┘         └──────────┘        └────┬─────┘ │
  │        ▲                                        │       │
  │        └────────────────────────────────────────┘       │
  │                  Iterate or pivot                        │
  └─────────────────────────────────────────────────────────┘

The loop starts with an idea, not code. The fastest way to complete a loop is to build the minimum thing that can test the idea — not the minimum shippable product, but the minimum testable thing.

What Is an MVP — Really?¶

The Minimum Viable Product is the most misunderstood concept in product development. It is not:

The first version of your product
A poorly built version of the full product
The smallest thing your team can ship in one sprint

An MVP is the minimum experiment that tests your most critical assumption.

  ASSUMPTION:  Users will pay for automated invoice reconciliation

  MVP options (in order of cost):

  1. Concierge MVP (0 code):
     Offer the service manually. Do it by hand. 
     If people pay, the demand is real. Cost: 1 week.

  2. Wizard of Oz MVP (minimal code):
     Build a UI that looks automated but is manually operated behind the scenes.
     Customers think it's a product. It's actually a person.
     Cost: 1-2 weeks.

  3. Landing Page MVP (no product):
     Build a marketing page describing the product.
     Add a "Get Early Access" button.
     Count sign-ups. Cost: 2-3 days.

  4. Feature-limited product:
     Build only the core reconciliation feature, nothing else.
     Cost: 4-8 weeks.

  Start with option 1 or 2. Build option 4 only after proving demand.

Lean Metrics — Validated Learning¶

Lean replaces vanity metrics with actionable ones:

  VANITY METRICS (feel good, don't inform decisions):
  ✗ Total registered users
  ✗ Page views
  ✗ App downloads
  ✗ Features shipped

  ACTIONABLE METRICS (directly linked to decisions):
  ✓ Activation rate: % of users who complete onboarding
  ✓ Retention rate: % of users who return after 7/30 days
  ✓ Conversion rate: % of free users who upgrade to paid
  ✓ NPS: would you recommend this to a colleague?
  ✓ Time-to-value: how long until a user gets their first value?

The Pivot Decision¶

A pivot is not a failure — it's a strategic course correction based on evidence. The question is when to pivot vs when to persevere:

  PIVOT vs PERSEVERE DECISION

  Questions to answer:
  1. Have we run enough experiments?  (at least 5 learning cycles)
  2. Have we tested with real users?  (not just internal stakeholders)
  3. Are the metrics moving?          (even slowly?)
  4. Are users doing the workaround?  (workarounds signal real need)
  5. Are we chasing the wrong user?   (maybe different segment would work)

  Pivot types:
  ✦ Zoom-in pivot: one feature becomes the product
  ✦ Zoom-out pivot: the product becomes one feature of something bigger
  ✦ Customer segment pivot: same product, different customer
  ✦ Problem pivot: same customer, different problem worth solving
  ✦ Business model pivot: same product, different monetisation

Part 3: Agile — Building It Right¶

Agile is not a methodology — it's a mindset, codified in the Agile Manifesto (2001). The Manifesto was a reaction to heavyweight, document-driven processes (Waterfall) that produced wrong software slowly.

The Agile Manifesto¶

  We are uncovering better ways of developing software
  by doing it and helping others do it.
  Through this work we have come to value:

  Individuals and interactions    OVER  processes and tools
  Working software                OVER  comprehensive documentation
  Customer collaboration          OVER  contract negotiation
  Responding to change            OVER  following a plan

  That is, while there is value in the items on the right,
  we value the items on the left more.

The 12 Agile Principles distil this into practice. The most important:

Principle	What it means in practice
Deliver working software frequently	Ship something every 1-4 weeks, not every 6 months
Welcome changing requirements	Change is information, not a problem
Business and developers must work daily	Not just at kickoff and demo
Working software is the primary measure	Not story points, not velocity
Simplicity — maximise work not done	YAGNI applied to process
Self-organising teams	The team decides how, management decides what
Regular reflection and adjustment	The retrospective is non-negotiable

Scrum — The Most Widely Used Agile Framework¶

Scrum structures work into Sprints — fixed-length iterations (1-4 weeks, typically 2). Each sprint produces a working, potentially shippable increment.

The Scrum Roles¶

  ┌─────────────────────────────────────────────────────────┐
  │                   SCRUM TEAM                            │
  │                                                         │
  │  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐  │
  │  │   PRODUCT    │  │    SCRUM     │  │ DEVELOPMENT  │  │
  │  │   OWNER      │  │    MASTER    │  │    TEAM      │  │
  │  │              │  │              │  │              │  │
  │  │ Owns the     │  │ Serves the   │  │ Self-organise│  │
  │  │ product      │  │ team and     │  │ to deliver   │  │
  │  │ backlog and  │  │ removes      │  │ the sprint   │  │
  │  │ prioritises  │  │ impediments  │  │ goal         │  │
  │  │ value        │  │              │  │              │  │
  │  └──────────────┘  └──────────────┘  └──────────────┘  │
  └─────────────────────────────────────────────────────────┘

Common misunderstandings: - The Product Owner is not the boss of the development team — the team self-organises on how to deliver - The Scrum Master is not a project manager — they don't track tasks and report status - "Development Team" means everyone who delivers: engineers, designers, QA — not just developers

The Sprint Cycle¶

  SPRINT CYCLE (2 weeks)

  Day 1 ──────────────────────────────── Day 14
    │                                       │
  Sprint          Daily                  Sprint    Sprint
  Planning        Scrum                  Review    Retro
    │              │  │  │  │  │           │         │
    │         (15 min each day)            │         │
    ▼                                      ▼         ▼
  Sprint Goal                          Working    What to
  selected,                            software   improve
  backlog items                        demo'd to  next sprint
  committed                            stakeholders

Sprint Planning (2-4 hours for a 2-week sprint)¶

  SPRINT PLANNING AGENDA

  Part 1 — WHAT (1-2 hours):
  ✦ Product Owner presents highest-priority backlog items
  ✦ Team asks clarifying questions
  ✦ Team commits to a Sprint Goal (one sentence: why this sprint matters)
  ✦ Team selects stories they can complete in the sprint

  Part 2 — HOW (1-2 hours):
  ✦ Team breaks each story into tasks (hours, not days)
  ✦ Team identifies risks and dependencies
  ✦ Team agrees on Definition of Done for the sprint

  Output: Sprint Backlog — the team's commitment for the next 2 weeks

The Daily Scrum (15 minutes, not a status meeting)¶

  WRONG: "Yesterday I worked on the payment module. Today I'll continue."
         (Status report — wastes 15 minutes)

  RIGHT: "I finished the payment validation. I'm now blocked because
          the Stripe sandbox credentials haven't been shared yet.
          Can someone from ops help after standup?"
         (Surfaces an impediment that the Scrum Master can remove)

  The three questions:
  1. What did I complete toward the Sprint Goal?
  2. What will I complete today toward the Sprint Goal?
  3. Are there any blockers?

Sprint Review (Demo) — 1-2 hours¶

  Sprint Review is NOT a presentation — it's a conversation.

  ✦ Team demonstrates working software (live, not screenshots)
  ✦ Stakeholders give feedback on what they see
  ✦ Product Owner updates the backlog based on feedback
  ✦ The team shows what they actually built, not what they planned

  The measure: "Is this working software?" not "Did we finish all the stories?"

Sprint Retrospective — The Most Skipped, Most Important Ceremony¶

  Retrospective format (1.5 hours):

  ┌─────────────────────────────────────────────────────────┐
  │              WHAT WENT WELL   │   WHAT TO IMPROVE       │
  │                               │                         │
  │ ✓ Daily standups felt short   │ ✗ Stories not refined   │
  │   and focused                 │   before planning       │
  │ ✓ We hit the sprint goal      │ ✗ Too many PR review    │
  │   for the first time          │   bottlenecks           │
  │ ✓ New deployment pipeline     │ ✗ Test coverage dropped  │
  │   saved 2 hours               │                         │
  └─────────────────────────────────────────────────────────┘

  Output: 1-3 specific actions, owned by named people, done by next retro
  (Not a list of complaints — a list of experiments)

The retrospective anti-pattern

Retrospectives that produce the same complaints every sprint are retrospectives where nothing changes. Every retro must produce a specific, owned action — not "we should communicate better" but "Ahmed will create a shared doc for design decisions by Friday."

Writing Good User Stories¶

A user story is not a feature description — it's a placeholder for a conversation.

  FORMAT:
  As a [type of user]
  I want [to do something]
  So that [I get some benefit]

  EXAMPLE:
  As a warehouse manager
  I want to see flagged discrepancies highlighted in red on the order approval screen
  So that I can identify issues without reading every field manually

  ACCEPTANCE CRITERIA (the conversation about Done):
  ✦ Discrepancies in quantity > 5% are highlighted in red
  ✦ Discrepancies in price > 2% are highlighted in amber
  ✦ Hovering shows the expected vs actual value
  ✦ The approval button is disabled until all red flags are resolved
  ✦ Works on desktop and tablet (minimum 768px)

INVEST — The Quality Test for User Stories¶

Letter	Stands for	Means
I	Independent	Can be built without another story being done first
N	Negotiable	The how is open; the what is agreed
V	Valuable	Delivers value on its own, not just as part of something bigger
E	Estimable	Small enough that the team can estimate it
S	Small	Completable in one sprint
T	Testable	Has clear acceptance criteria

A story that fails INVEST needs to be split, refined, or discarded.

Story Splitting Patterns¶

  A story too big for one sprint can be split by:

  BY WORKFLOW STEP:
  "User can manage their account"  →  "View account details"
                                   →  "Edit profile information"
                                   →  "Change password"

  BY DATA TYPE:
  "Import product data"  →  "Import products from CSV"
                         →  "Import products from Excel"
                         →  "Import products from API"

  BY HAPPY PATH / EDGE CASES:
  "Process payment"  →  "Process successful card payment"
                     →  "Handle declined card"
                     →  "Handle network timeout during payment"

  BY USER TYPE:
  "User can view reports"  →  "Admin can view all reports"
                           →  "Manager can view team reports"

Kanban — Flow Over Sprints¶

Kanban is an alternative to Scrum's sprint model. Where Scrum works in timeboxed iterations, Kanban focuses on continuous flow — optimising the speed at which work moves from start to done.

  KANBAN BOARD

  │ BACKLOG  │  READY   │  IN PROGRESS │  REVIEW  │    DONE   │
  │──────────│──────────│──────────────│──────────│───────────│
  │  Story A │  Story D │  Story F     │  Story H │  Story J  │
  │  Story B │  Story E │  Story G     │          │  Story K  │
  │  Story C │          │              │          │           │
  │          │  WIP: 2  │    WIP: 2    │  WIP: 1  │           │
  │          │  LIMIT:2 │    LIMIT: 3  │  LIMIT: 2│           │

  WIP Limits: force the team to finish before starting new work.
  If "In Progress" is full, you help someone else finish instead of
  starting something new.

Kanban metrics:

Lead Time: Time from "request made" to "delivered" — what the customer experiences
Cycle Time: Time from "work started" to "delivered" — what the team controls
Throughput: Items completed per week — team capacity

When to choose Kanban over Scrum:

Use Scrum when	Use Kanban when
Building a new product with evolving requirements	Supporting a live product (bug fixes, small features)
Team needs structure and rhythm	Work arrives unpredictably
Stakeholders need regular, predictable demos	Continuous deployment is the norm
Team is new and needs process	Team is mature and self-manages

Part 4: Dual-Track Agile — Discovery and Delivery Together¶

The three-phase model (Design Thinking → Lean → Agile) implies sequential phases. But in practice, the best product teams run discovery and delivery in parallel — continuously learning while continuously shipping.

This is called Dual-Track Agile:

  DUAL-TRACK AGILE

  ┌──────────────────────────────────────────────────────┐
  │                DISCOVERY TRACK                        │
  │  Research → Define → Prototype → Test → Validated    │
  │                                          stories  ──┐ │
  └──────────────────────────────────────────────────┘  │ │
                                                         ▼ │
  ┌──────────────────────────────────────────────────────┐ │
  │                DELIVERY TRACK                         │ │
  │  Sprint 1 │ Sprint 2 │ Sprint 3 │ Sprint 4 │ ...     │◄┘│
  │           │          │          │          │          │  │
  │  Build → Measure ─────────────────────────────────── ┤  │
  │                                              Feedback─┘  │
  └──────────────────────────────────────────────────────────┘

How it works:

The Discovery Track runs 1-2 sprints ahead of delivery — validating what the delivery team will build next
The Delivery Track builds what discovery has already validated — no wasted development on unvalidated ideas
User research findings flow from discovery into the backlog as validated, refined stories

The split of roles:

Discovery Track	Delivery Track
Product Manager + Designer (lead)	Engineering team (lead)
User research, prototyping, testing	Development, testing, deployment
Validates: is this worth building?	Validates: did we build it correctly?
Output: validated stories	Output: working software

Part 5: The Build vs Buy vs Partner Decision¶

Agile and Lean tell you how to work. But before you start, you face a strategic question: should you build this at all?

Every feature, module, and capability in your system is a choice between:

  ┌───────────────────────────────────────────────────────────────┐
  │              THE BUILD / BUY / PARTNER SPECTRUM               │
  │                                                               │
  │   BUILD        CUSTOMISE       BUY / SaaS      PARTNER        │
  │   (100%        (platform +     (COTS /         (outsource     │
  │   custom)      config)          off-shelf)       entirely)    │
  │                                                               │
  │   Max           High            Low              None         │
  │   control       control         control          control      │
  │                                                               │
  │   Max           Medium          Low              None         │
  │   cost          cost            upfront          upfront      │
  │                                                               │
  │   Slowest       Medium          Fastest          Fast         │
  │   to market     to market       to market        to market    │
  └───────────────────────────────────────────────────────────────┘

The Decision Framework¶

Ask three questions in sequence:

Question 1: Is this your Core Domain?

From Domain-Driven Design: your core domain is the thing that gives you competitive advantage. You must own and build what makes you unique.

  Core Domain → Always BUILD (this is your secret sauce)
  Supporting Domain → Consider BUY or CUSTOMISE
  Generic Domain → Always BUY or use open source

  Examples:
  ✦ Amazon's recommendation engine → CORE → Build
  ✦ Amazon's payroll system → GENERIC → Buy (Workday)
  ✦ Amazon's warehouse management → SUPPORTING → Build (complex enough to be worth it)

Question 2: Is a good-enough solution available?

  Decision criteria for BUY:
  ✓ A market-standard solution exists with 80%+ of required functionality
  ✓ The gap (20%) can be addressed through configuration, not code
  ✓ Integration cost is lower than build cost
  ✓ The vendor is stable and the product is actively maintained
  ✓ Total cost of ownership (TCO) over 3 years is lower than building

  Decision criteria for BUILD:
  ✗ No solution handles your specific workflow or data model
  ✗ Compliance or security requirements can't be met by a vendor
  ✗ The capability is a competitive differentiator
  ✗ Customisation required would equal a rebuild anyway
  ✗ Vendor lock-in risk is unacceptable

Question 3: What is the total cost?

Most teams compare build cost vs licence cost. The real comparison is Total Cost of Ownership:

  BUILD TCO:
  ✦ Development cost (initial build)
  ✦ Maintenance cost (ongoing: ~20-30% of build cost per year)
  ✦ Operational cost (infrastructure, monitoring)
  ✦ Opportunity cost (what else could these engineers build?)

  BUY TCO:
  ✦ Licence cost (per user, per seat, per API call)
  ✦ Implementation cost (initial setup, data migration)
  ✦ Integration cost (connecting to existing systems)
  ✦ Customisation cost (config, workflow mapping)
  ✦ Training cost
  ✦ Vendor lock-in risk (what's the exit cost in 3 years?)

Open Source — A Third Path¶

Open source is often the best of both: a proven, maintained solution you can customise and own.

  OPEN SOURCE DECISION CHECKLIST

  Before adopting open source, verify:
  ✓ Active community (commits in last 30 days, issues being closed)
  ✓ Commercial support available if needed (Red Hat, Elastic, Confluent model)
  ✓ Licence is compatible with your use case (MIT/Apache 2 vs AGPL)
  ✓ Security posture (CVE history, security policy exists)
  ✓ You have capacity to contribute back (or pay for the gap)
  ✓ You can operate it — some open source is operationally complex

  Open source ≠ free. Cost is operational and maintenance labour.

Part 6: Technical Strategy — Decisions That Outlive Sprint 1¶

Beyond the methodology, a software development strategy requires technical decisions that will shape your system for years.

Platform vs Product Thinking¶

A product solves a specific user problem. A platform enables others to build products.

Most teams build products. But at scale, the highest-leverage investment is often building internal platforms — foundations that make every product team faster.

  PRODUCT THINKING:                  PLATFORM THINKING:
  "We need to add observability       "We need an observability platform
   to the order service."              that every service uses."

  Time to value: 1 sprint             Time to value: 1 quarter
  Value scope: 1 team                 Value scope: all teams

  When to choose product:             When to choose platform:
  ✦ You have 1-3 services            ✦ You have 5+ teams with the same need
  ✦ Speed to market is critical      ✦ Teams are duplicating infrastructure
  ✦ Requirements are unclear         ✦ Platform enables 10x team velocity

Managing Technical Debt Intentionally¶

Technical debt is not bad code — it's a decision to trade future flexibility for current speed. Like financial debt, it's only a problem if it's untracked and unmanaged.

  TYPES OF TECHNICAL DEBT

  PRUDENT + DELIBERATE (acceptable):
  "We know we're cutting this corner. We'll fix it in Q3."
  → Document it. Plan the payoff.

  PRUDENT + INADVERTENT (learning):
  "Now that we delivered it, we can see the better design."
  → Normal discovery. Refactor in the next iteration.

  RECKLESS + DELIBERATE (dangerous):
  "We don't have time to do this right."
  → Must be tracked and paid down urgently.

  RECKLESS + INADVERTENT (crisis):
  "We didn't know it was bad code."
  → Skills gap. Requires team investment in quality practices.

The Debt Register:

# Keep a living document of known debt:

technical_debt:
  - id: TD-001
    description: "Order service uses synchronous calls to Inventory — should be async events"
    impact: "Inventory downtime causes order failures"
    effort: "3 sprints"
    priority: HIGH
    target_sprint: "Q3 Sprint 4"
    owner: "Backend team"

  - id: TD-002
    description: "Authentication module has no unit tests"
    impact: "Changes are risky, slow"
    effort: "1 sprint"
    priority: MEDIUM
    target_sprint: "Q3 Sprint 6"
    owner: "Platform team"

Team Topologies — Structuring Teams for Flow¶

How you organise your teams directly affects what you can build. The Team Topologies framework (Skelton & Pais, 2019) defines four team types:

  ┌─────────────────────────────────────────────────────────────────┐
  │                     TEAM TOPOLOGIES                              │
  │                                                                  │
  │  ┌───────────────┐    The core team. Owns a bounded context,    │
  │  │  STREAM-      │    delivers a value stream end-to-end.       │
  │  │  ALIGNED      │    Example: "Order Management Team"          │
  │  └───────────────┘                                              │
  │                                                                  │
  │  ┌───────────────┐    Reduces cognitive load for stream-aligned  │
  │  │  PLATFORM     │    teams. Provides self-service infrastructure.│
  │  │               │    Example: "Developer Platform Team"        │
  │  └───────────────┘                                              │
  │                                                                  │
  │  ┌───────────────┐    Temporary team for hard problems.         │
  │  │  ENABLING     │    Upskills stream-aligned teams then        │
  │  │               │    disbands. Example: "Security Enablement"  │
  │  └───────────────┘                                              │
  │                                                                  │
  │  ┌───────────────┐    Narrow expertise used by multiple teams.  │
  │  │  COMPLICATED  │    Example: "Data Science Team",             │
  │  │  SUBSYSTEM    │    "Cryptography Team"                       │
  │  └───────────────┘                                              │
  └─────────────────────────────────────────────────────────────────┘

The key insight: Conway's Law means your software architecture will mirror your team structure. Design teams around how you want software to be structured, not around existing org charts.

Part 7: Measuring What Matters¶

A strategy without metrics is a wish. Here are three measurement frameworks that matter.

OKRs — Objectives and Key Results¶

OKRs align teams around outcomes (not outputs):

  OKR FORMAT:
  OBJECTIVE: Qualitative, inspirational, time-bound
  KEY RESULT: Quantitative, measurable, 0-100% trackable

  EXAMPLE — Product Team OKRs (Q3):

  Objective: Make it effortless for warehouse managers to approve orders

  Key Result 1: Reduce average order approval time from 4 minutes to 90 seconds
  Key Result 2: Reduce order approval errors from 8% to 2%
  Key Result 3: Achieve NPS of 7+ from warehouse manager users (currently 3)

  The OKR forces a conversation:
  "If we ship feature X, will it move these numbers?"
  Not: "Did we ship feature X?"

OKR anti-patterns:

Writing OKRs for tasks ("Ship the approval redesign") — that's a delivery plan, not an OKR
Too many OKRs (max 3 objectives, 3-5 KRs each)
Key Results that are binary (done/not done) — they should be a scale
Not reviewing OKRs mid-quarter — they should be a live conversation

DORA Metrics — Engineering Performance¶

The DORA (DevOps Research and Assessment) metrics are the four most predictive indicators of software delivery performance:

  FOUR DORA METRICS

  ┌───────────────────────────────────────────────────────────────┐
  │  METRIC              │ ELITE    │ HIGH     │ MEDIUM   │ LOW   │
  ├───────────────────────┼──────────┼──────────┼──────────┼───────│
  │  Deployment          │ Multiple │ Daily-   │ Weekly-  │ < 1x  │
  │  Frequency           │ per day  │ weekly   │ monthly  │ month │
  ├───────────────────────┼──────────┼──────────┼──────────┼───────│
  │  Lead Time for       │ < 1 hour │ 1 day -  │ 1 week - │ > 6   │
  │  Changes             │          │ 1 week   │ 1 month  │ months│
  ├───────────────────────┼──────────┼──────────┼──────────┼───────│
  │  Change Failure      │ 0-15%    │ 0-15%    │ 16-30%   │ 16-   │
  │  Rate                │          │          │          │ 30%   │
  ├───────────────────────┼──────────┼──────────┼──────────┼───────│
  │  Mean Time to        │ < 1 hour │ < 1 day  │ 1 day -  │ > 6   │
  │  Restore (MTTR)      │          │          │ 1 week   │ months│
  └───────────────────────┴──────────┴──────────┴──────────┴───────┘

DORA research shows: elite performers deploy 208x more frequently, have 2,604x faster recovery, and 7x lower change failure rates than low performers — while burning out less. Speed and stability are not trade-offs; they're correlated.

North Star Metric¶

Every product team should have one metric that best captures the value they deliver to users:

  NORTH STAR FRAMEWORK

  Product          │ North Star Metric
  ─────────────────┼──────────────────────────────────
  Spotify          │ Time spent listening per user per day
  Airbnb           │ Nights booked
  Slack            │ Messages sent per active team per day
  GitHub           │ Repositories with ≥1 commit per week
  WhatsApp         │ Messages sent per day

  YOUR NORTH STAR should:
  ✦ Reflect value delivered to users (not to the business)
  ✦ Be a leading indicator (predicts revenue, not just reports it)
  ✦ Be singular — one number the whole team rallies around
  ✦ Be understandable by everyone on the team

The Complete Playbook — From Strategy to Delivery¶

Putting it all together into a repeatable cycle:

  PHASE 1: DISCOVER (2-4 weeks)
  ─────────────────────────────
  ✦ Conduct 5-8 user interviews
  ✦ Build empathy maps and journey maps
  ✦ Run affinity mapping to find themes
  ✦ Write POV statements and HMW questions
  ✦ Align stakeholders on the real problem
  Output: A validated problem statement

  PHASE 2: DEFINE & VALIDATE (2-4 weeks)
  ───────────────────────────────────────
  ✦ Ideate solutions (Crazy 8s, HMW)
  ✦ Build paper/clickable prototypes
  ✦ Test with 5 users — what works, what doesn't
  ✦ Decide Build / Buy / Partner
  ✦ Define your North Star metric
  ✦ Write the first sprint's user stories
  Output: Validated concept + refined backlog

  PHASE 3: BUILD & MEASURE (ongoing sprints)
  ──────────────────────────────────────────
  ✦ Sprint 1-3: Build the core MVP
  ✦ Release to real users (even if limited)
  ✦ Measure: are users getting value? (activation, retention)
  ✦ Sprint 4-6: Iterate based on data
  ✦ Retro every sprint — improve the process
  ✦ Run discovery in parallel (Dual-Track)
  Output: Working software + learning

  PHASE 4: SCALE (when product-market fit is proven)
  ──────────────────────────────────────────────────
  ✦ Invest in platform (reduce duplication across teams)
  ✦ Track DORA metrics — optimise delivery performance
  ✦ Manage technical debt intentionally
  ✦ Adopt Team Topologies structure
  ✦ Set quarterly OKRs aligned to North Star
  Output: Sustainable, scalable delivery

Summary¶

Methodology	Answers	Core Tool	Output
Design Thinking	WHY — what problem is worth solving?	User interviews, empathy maps, prototypes	Validated problem statement
Lean	WHAT — what is the minimum to test the solution?	Build-Measure-Learn, MVP	Validated solution concept
Scrum	HOW — how do we deliver reliably?	Sprints, backlog, ceremonies	Working software every 2 weeks
Kanban	HOW — how do we optimise flow?	WIP limits, cycle time	Continuous delivery
Dual-Track	WHAT & HOW simultaneously	Discovery + Delivery tracks	Validated backlog + shipped software
Build/Buy/Partner	SHOULD WE build this?	Core domain analysis, TCO	Strategic sourcing decision
OKRs	Are we moving the right needle?	Objective + Key Results	Outcome alignment
DORA	How is our engineering performing?	4 metrics dashboard	Delivery performance benchmark

The essential reading for going deeper: The Lean Startup by Eric Ries, Inspired by Marty Cagan, The Phoenix Project by Gene Kim, Accelerate by Nicole Forsgren et al., and Team Topologies by Matthew Skelton & Manuel Pais. Together they form the complete modern software delivery canon.

Questions or discussion? Connect on LinkedIn, X or reach out via email.

Discussion

Have thoughts on this post? Share them below — questions, corrections, or your own experience are all welcome.