Start lean software development by making one source of wasted effort visible, changing the working practice and checking what happened. Start with a specific delay, repeated correction or unused deliverable. Keep the learning record tied to actual work, so a smaller backlog or a new board does not become its own success measure.
What counts as waste in this particular project?
Begin with a work item that has become difficult to finish. Ask the people involved to reconstruct its route: what was requested, when it became clear, who needed information and which work was later discarded. Separate observed events from explanations. A developer waiting for an answer is an event; the reason for the wait needs investigation.
The Scrum Guide describes lean thinking as reducing waste and focusing on essentials. That statement in the Scrum Guide is a useful starting point for the discussion. Give “essential” a task-specific meaning: a completed user outcome, a necessary control or a decision that permits the work to continue.
Avoid calling every review, document or conversation waste. Ask what decision it supports and what would happen without it. A duplicate status report may be a candidate for removal, while a record explaining an access decision may remain necessary even when it adds work to the delivery process.
Our proposed waste register uses four fields: observed repetition or delay, the work affected, the suspected cause and the evidence that would test that explanation. Put a named example in each row. “Communication is poor” is too broad to guide a useful change.
How do you connect a change to customer value?
The Agile Manifesto principles put early and continuous delivery of valuable software at the centre of customer satisfaction. Read that in the context of the Agile Manifesto principles. The useful question for a team is what the intended user can accomplish after the next piece of work, and why that outcome matters.
The principles describe working software as the main measure of progress. Define the behaviour you intend to show. A completed screen may be relevant, but a user journey might also need a clear result, appropriate access and an understandable exception route. Agree which of those concerns belongs to the current increment before deciding what “working” means in the review.
Use a hypothetical service-request application. The team is considering a decorative dashboard while staff still cannot tell who owns an unresolved request. The proposed decision is to investigate request ownership first. That is a prioritisation example, not a universal instruction to remove dashboards or an assertion about measured customer demand.
Write down the expected benefit as a question: can a staff member identify the next responsible person from the record? Then choose a bounded way to investigate it. Keep financial savings and productivity promises out of the conclusion unless the team has actually measured the relevant effects.
Which feedback should alter the work?
The principles welcome changing requirements, including late in development. Make a change understandable by recording the new evidence and which prior assumption it affects. A late request may reveal an important missing outcome, but it still needs an explicit decision about scope, priority and any existing commitments.
The Scrum Guide grounds empiricism in experience and decisions based on observations. For the hypothetical ownership problem, useful evidence might be an observed attempt to assign a synthetic request or an account from the person responsible for triage. Record who supplied the evidence and the circumstances in which it applies.
Do not merge conflicting accounts into a tidy story prematurely. If one team says the next step belongs to support and another says it belongs to operations, preserve that disagreement. The next action may be a responsibility decision rather than more software development.
The Scrum Guide links low transparency in artefacts with decisions that can reduce value and increase risk. Show the state of the work in language that helps people decide. If a feature is awaiting a business rule, say which rule and who can resolve it. A green status label that conceals the unresolved dependency works against the purpose of the review.
How can a team run a small process experiment?
Use this original experiment card for one suspected source of waste. Keep the unit of investigation small enough that colleagues can explain what changed and what else remained in play.
| Card field | Example question | Evidence to keep |
|---|---|---|
| Observed problem | Which request was returned for clarification? | Original request and the actual clarification |
| Suspected cause | Was the required owner missing from the brief? | Accounts from the affected participants |
| Proposed change | Would an explicit responsibility field help? | Revised brief and reason for trying it |
| Observation | What happened when the next relevant request used it? | Dated account of the actual handover |
| Side effect | Did the new field create another repeated task? | Specific extra work or unresolved confusion |
| Decision | Keep, modify or stop the experiment? | Owner, reasons and the next review point |
Do not invent a target reduction to make the card look rigorous. If you need a quantitative measure, define how it will be collected and what question it answers. Keep work items that are not comparable out of a claimed before-and-after result.
Ask the people doing the work to identify likely side effects before the experiment starts. A new field might become another place to copy the same information. The proposed change should explain which existing record it replaces or which decision justifies maintaining it.
Where do design quality and maintenance fit?
The principles connect agility with continuing attention to technical excellence and good design. Include maintainability in the discussion of useful work. Ask whether the proposed shortcut leaves the next developer able to understand the behaviour and change it. Treat that as a concrete review question, supported by the code and the task, rather than an automatic reason to redesign the entire system.
For the request-ownership example, a focused change might use an existing responsibility model instead of adding another parallel set of statuses. Ask the developer to explain the intended ownership boundary and identify any ambiguous transitions before implementing it. The aim is a coherent task outcome, not the largest possible refactor.
The guide says inspection without adaptation is pointless. The guide expects adjustment when a process or resulting product is unacceptable. Close the loop with a recorded decision about the experiment. If the evidence is insufficient, say what remains to be observed rather than labelling the change successful because it was deployed.
The principles call for teams to reflect regularly and adjust how they work. Make that reflection practical: which repeated task can stop, which useful check should remain and which question still needs an owner? Carry the decision into the next piece of work so that the meeting produces an observable change in practice.
For delivery roles and events, use the separate Scrum guide. For implementation scope, see web development, or discuss your requirements with Spout using a completed experiment card.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.