What does Kanban's 'start with what you do now' principle mean in practice?
answer
- It changes a process, not replaces one
- Model today before altering anything
- Roles, titles and hand-offs stay put
- Small steps, each cheap to reverse
basics
~20 sKanban is applied on top of the process a team already runs rather than replacing it. You model the current workflow, make it visible on a flow board, and only then change it in small reversible steps.
solid answer
~50 sKanban is a **change method**, not a delivery process, so it asks for no structural change as a precondition. Current roles, titles, hand-offs and approval steps all stay; what happens on day one is that the workflow is drawn as it actually runs and made visible on a shared flow board, including the unflattering stages where work waits on someone outside the team. Improvement then proceeds **evolutionarily**: one small change to one explicit policy, agreed by the people doing that work, with its effect observed before the next one. The reason is adoption risk rather than workflow design - a change that takes nobody's title away leaves almost nobody with a motive to resist it. The honest cost is patience: this route reaches structural problems slowly, and a team that never actually changes a policy just ends up with a prettier status wall.
go deeper
Be ready to say in one sentence that Kanban is applied to the process a team already has, and to name what appears on day one: the real workflow drawn on a visible flow board, with roles and hand-offs untouched.
Explain the mechanics of a small change - one explicit policy, agreed by the people at that stage, cheap to revert - and give two concrete examples, such as writing a column's exit criteria or capping work in progress at one stage.
Show you have run it. Describe a policy you changed on a real team, what you expected to move, and whether it did. Naming a change you reverted is stronger evidence than a list of successes.
Own the limitation: evolutionary change optimises within the current structure, so be able to say what it will not reach and how you would tell the difference between a team that needs another experiment and one whose constraint is structural.
## A change method, not a delivery process Most process frameworks arrive with a shape of their own: roles to appoint, events to schedule, a timebox to fit the work into. Kanban arrives with almost none of that. It is a **method for changing whatever process a team already runs**, and its first instruction is to leave that process alone long enough to see it clearly. Job titles stay. Hand-offs stay. The approval step everyone complains about stays. What changes on day one is only that all of it becomes visible on a shared flow board, with columns drawn to match the stages work really passes through - including the unflattering ones, like 'waiting for someone outside the team to look at it'. The claim behind that modesty is about **adoption risk**, not about workflow design. A change that asks nobody to give up a title, a budget line or a reporting line leaves almost nobody with a reason to fight it. A change that reassigns fourteen people into new teams creates fourteen reasons on the morning it is announced, and the usual outcome is quiet non-compliance: the new structure on the chart, the old process running underneath it. ## The principles that travel together The Kanban Method states its change stance as a small set of principles that only work as a set: - **Start with what you do now** - model the current workflow, respect current roles and responsibilities, and require no structural change as a precondition. - **Agree to pursue improvement through evolutionary change** - alter the system in increments small enough that reverting one costs almost nothing. - **Encourage acts of leadership at every level** - improvement proposals are expected from anyone doing the work, not only from whoever owns the process. The first makes adoption cheap, the second makes each step safe, and the third makes the supply of proposals larger than one person's attention span. Drop the second and you get an unmeasured drift of habits; drop the third and improvement waits on a single overloaded individual. ## Evolutionary and imposed change, side by side | | Imposed redesign | Evolutionary change | |---|---|---| | Decided up front | the whole target structure | one policy | | Who must agree | everyone affected, at once | the people working at one stage | | Cost of being wrong | months, plus the credibility to try again | a week and a reverted rule | | Typical failure | quiet non-compliance; the old process survives underneath | drift - many small changes, none measured | | Reach into structure | direct | slow, sometimes never | The last row is the honest weakness, and a candidate who names it reads better than one who sells the method. Evolutionary change optimises inside the structure it starts from. If the real constraint is that four teams share one queue with nobody owning it, no sequence of column policies will reach that. ## What 'small' actually looks like A first round of changes on a real team is unglamorous. Every item below is one sentence of policy that can be reverted in a single stand-up: 1. Write one column's exit criteria on the board, so 'finished with this stage' stops being a matter of opinion. 2. Split a column into *doing* and *done* sub-columns, which makes a hand-off queue visible for the first time. 3. Cap the work in progress at the one stage that visibly queues. 4. Give the class of work that keeps jumping the queue its own lane, plus an explicit rule for when it may jump. 5. Record a start date on each card, so the team can later say how long things actually take. Each has an observable consequence within a fortnight, which is what makes it an experiment rather than an opinion. ## Where teams get this wrong - **Treating the flow board as the method.** Visualisation with no policy ever changing produces a tidier status wall and no improvement at all. - **Drawing the process they wish they had.** A board that does not match reality stops being trusted quickly, and then it gets updated late on a Friday, if at all. - **Reading 'evolutionary' as 'unmeasured'.** Small does not mean casual: each change still needs a measure that would show whether it helped. - **Changing five things at once**, and then being unable to say which one moved the number. - **Waiting for permission to start.** The entire point of beginning from today's process is that no permission is required. A good answer closes the loop out loud: start from what exists, make it visible, change one explicit policy, watch the same measure, keep it or revert it. That cycle is the method; the board is only where it is played out.
- If no structure changes on day one, what has actually changed?Visibility and explicitness. The workflow that lived in people's heads is now drawn where everyone can see it, including the waiting stages nobody used to count, and the rules for moving work between stages are written down instead of assumed. That alone changes behaviour, because disagreements about whether something is finished become disagreements about a written policy that can be edited.
- What is the failure mode of a team that adopts the board but never changes a policy?It has bought the visualisation and skipped the method. The board becomes a status wall that costs time to maintain and produces no improvement, and within a couple of months people stop trusting it because it is updated only just before a meeting. The tell is that nobody can name a rule the team changed and what happened to the numbers afterwards.
- Does starting from the current process mean bad practices get preserved?It means they get preserved visibly, which is the point. A hand-off that wastes four days is far easier to argue about once it is a column with a queue in it than while it is an unwritten habit. The risk is real if the team stops there - the principle is start with what you do now, not stay with what you do now.
Closer to renovating an occupied house room by room than demolishing it and rebuilding: people keep living there, and each change is judged on its own before the next one starts.
saying these in an interview costs you the question
- Claims Kanban requires abolishing existing roles first
- Treats the flow board as the whole method
- Plans one large process redesign before starting
- Thinks evolutionary change means never measuring anything
- Draws the idealised workflow rather than the real one
- Changes several policies at once and claims success