Agile & Lean

A visual workflow management method that uses a board with columns (To Do, In Progress, Done) to track work and limit work-in-progress. Originated at Toyota. Unlike Scrum, Kanban has no fixed iterations — work flows continuously.

"We switched to Kanban for the ops team — they handle unpredictable incoming requests, so the fixed Scrum sprint cadence didn't fit. The Kanban board makes bottlenecks visible instantly."

A constraint on how many work items can be in a given stage simultaneously. WIP limits force teams to finish work before starting new work, exposing bottlenecks and improving flow. A WIP limit of 3 means no more than 3 items can be in that column.

"Our In Progress column has a WIP limit of 4 — when it's full, team members must help others finish before picking up new work. This revealed that code review was the bottleneck: 3 items were waiting for review while new work kept starting."

A philosophy of eliminating waste and maximising value. Applied to software: eliminate unnecessary features (waste), reduce handoff delays, stop over-engineering, and deliver value early and often. Originating from the Toyota Production System.

"Lean thinking made us question the admin dashboard we were building — nobody had asked for it, and when we surveyed users, only 2% would use it. We eliminated that work and focused on the feature 80% of users requested."

The version of a product with just enough features to be usable and testable by real users. An MVP is not a half-built product — it is a complete, valuable experience that validates the core hypothesis with minimum investment. Often misused to mean "quick and low quality."

"Our MVP was a basic booking form with email confirmation — no payment integration, no calendar sync, no reminders. It validated that users would commit to a time slot before we built any of those features."

A practice where code is always in a releasable state — every change passes automated tests and can be deployed to production at any time by a business decision. Differs from Continuous Deployment (changes are deployed automatically without a manual release decision).

"Continuous delivery means we can release at 2pm on a Tuesday if the business asks — the code is always ready. The release decision is a business decision, not a technical one. Continuous deployment would skip that decision and deploy automatically."

The total time from when work is requested (ticket created) to when it is delivered to users. A key flow metric that includes waiting time, not just active development time. Reducing lead time requires reducing both development time and queue/waiting time.

"Our average lead time is 18 days — but the actual development takes only 3 days. The other 15 days are the ticket waiting in the backlog, waiting for code review, and waiting for the release window. Reducing lead time means reducing the waiting, not working faster."

The time from when development actively starts on a work item to when it is done. A subset of lead time — it excludes backlog waiting time. Used to measure team throughput and predictability.

"Our cycle time is 2.4 days on average — but the standard deviation is 4 days, which means delivery is unpredictable. We're investigating what causes some items to take 2 weeks and others 1 day."

A framework for implementing agile practices across large enterprises with multiple teams. Introduces additional structures: Program Increments (PI), Agile Release Trains (ARTs), and portfolio-level planning. Widely used but also widely debated in the agile community.

"The company adopted SAFe because 12 teams were working on the same product with no coordination — dependencies were blocking deliveries constantly. SAFe's PI planning introduced a quarterly alignment ceremony where all teams synchronise goals and identify dependencies upfront."

A goal-setting framework: an Objective is a qualitative ambition; Key Results are measurable outcomes that define success. Used at company, team, and individual levels. Originally developed at Intel, popularised by Google. Different from KPIs (ongoing metrics vs. time-bound goals).

"Our team's Q2 OKR — Objective: Make the onboarding experience best-in-class. Key Result 1: Reduce time-to-first-value from 14 days to 3. Key Result 2: Increase day-7 retention from 62% to 75%. These force us to define what 'best-in-class' actually means numerically."

The implied cost of future rework caused by taking shortcuts now instead of using the best approach. Like financial debt: it accrues interest (makes future changes slower) and must eventually be paid down. "Deliberate tech debt" is an intentional trade-off; "accidental tech debt" is the result of ignorance or poor practice.

"We took on deliberate tech debt by hardcoding the currency to USD to ship on time. We documented it as a known issue — now, three months later, the interest is high: adding multi-currency is affecting 40 files instead of the 5 it would have been."

The ongoing process of reviewing, clarifying, estimating, and prioritising backlog items. Refinement ensures the top of the backlog is always "sprint-ready" — well-understood stories with clear acceptance criteria. Typically a regular ceremony mid-sprint, not just before sprint planning.

"In refinement, the team challenged the acceptance criteria of the export feature — "export to CSV" was in scope but nobody had specified the column order, date format, or encoding. We clarified all three, which prevented a scope argument mid-sprint."

A checklist of criteria that a user story must meet before the team agrees to take it into a sprint. Complements the Definition of Done. Typical criteria: clear acceptance criteria, estimated, dependencies identified, design available. Prevents teams from starting work on under-defined stories.

"Our Definition of Ready requires acceptance criteria, a design mockup for UI changes, and an estimate. Two items in the sprint planning were rejected as not-ready — they were scheduled for refinement first."

The ratio of active work time to total lead time. Flow efficiency of 15% means a work item is actively being worked on for 15% of its total journey and waiting 85% of the time. Most teams have 10–20% flow efficiency — improving it requires reducing queues and handoffs.

"Our flow efficiency analysis was eye-opening: user stories spend 3 days in active development but 14 days waiting — for requirements, for the environment, for review, for the release window. The bottleneck is not coding speed."

One cycle of the development loop — plan, build, test, review, learn. In Scrum, a sprint is an iteration. In general agile usage, an iteration is any repeating development cycle. Iterative development means building the product in small, tested increments rather than all at once.

"We released iteration 1 with only the core booking flow — no payments, no admin panel. After one week of real user feedback we had insights that changed the direction of iteration 2. If we'd built everything upfront, we would have built the wrong thing."

The amount of work a team completes in a fixed time period, measured in story points or work items. Used to forecast capacity and set expectations. Average velocity over 3–5 sprints gives a reliable planning baseline. Velocity is a planning tool, not a performance metric.

"Don't compare team velocities — story points have no meaning across teams. Our team's velocity of 42 and another team's 38 says nothing about relative productivity. We use velocity only to forecast our own future capacity."

An agile development practice where two developers work together at one keyboard — a driver (writes code) and a navigator (reviews in real time). Pairs switch roles frequently. Benefits: fewer bugs, knowledge sharing, better design decisions. Common in XP (Extreme Programming).

"We use pair programming for the most complex refactoring work — two people reviewing the same code in real time catches design issues that code review misses. The initial slowdown is offset by dramatically fewer bugs in production."