Most agile methodologies use fixed iterations. Preferable to traditional approaches because the customer gets to see working code at the end of each iteration, and the project can frequently correct its course based on feedback. Moving to a fixed iteration forces you to take smaller steps, otherwise nothing will fit into an iteration.
How XP defines the iteration…
…and how Scrum defines the sprint.
Because most people associate Agile with XP and/or Scrum, it’s easy to assume that the fixed-length iteration or sprint is a precondition of agility. But…
This is the closest the Agile Manifesto principles come to talking about iteration length. “Frequent and Continuous”. Despite what many people think, there’s nothing inherently un-agile about not using a fixed iteration.
By concentrating so much on iterations as delivery timeboxes, we sometimes forget that the point is to actually iterate. Instead we try to get each story perfectly completed in the iteration/sprint. When a story isn’t finished in time, or there are issues raised at acceptance we have to put new stories in the backlog, or move the incomplete story into the next iteration. This causes all manner of confusion with velocity etc.
A quick detour into Lean Manufacturing (Toyota Production System). I am not an expert!
Central to Lean is the elimination of waste.
I don’t speak Japanese, but apparently that says ‘muda’. These are the seven main types of waste identified by Toyota.
Some of these can be applied to software development.
For now we’re mainly interested in reducing unnecessary inventory.
Literally ‘visual card’.
Used as a token for a downstream process to pull materials from an upstream process.
An assembly line where process B depends on the output of process A.
A keeps churning out parts as fast as it can, which leads to a build up of work in progress. This is managed by up-front process design and by observing the amount of inventory of part A.
The amount of inventory of part A is fixed (in this case two batches of three), and process B requests more as required. This is managed using kanbans – there are only two in the system, one per batch.
If process A has a kanban, it produces a batch of part A, and attaches the kanban. When process B uses up a batch, it returns the kanban to process A, which triggers production of more parts.
The amount of WIP is controlled by reducing the number of kanbans at different points in the production process. This exposes the bottlenecks in the system (the processes that are still running at full capacity when others are idle), allowing them to be addressed.
Need to prioritise the backlog first, to be able to pick the appropriate number of stories to commit to the iteration. Planning involves some analysis, to try and estimate whether stories will fit in the timebox.
Fixed time causes some problems. Might finish a story without enough time to start another (waiting), or not finish a story before the end of the iteration, and need to replan.
Stories completed early wait for acceptance (unnecessary inventory). Any rework required feeds into, and complicates, the planning for the next iteration.
What’s the simplest thing that could possibly work?
No iterations. No estimation. Stories just move through from the backlog to delivery as fast as possible. Customer decides which story to pull in from backlog when capacity becomes available. Analysis done just in time.
Short of whiteboard space, so our ‘swim lanes’ are drawers. We have backlog, live, ready for acceptance and done. Different projects will have different sets of lanes (eg if they have separate analysis and QA sign-off stages). Don’t confuse it with waterfall – stories move through independently (and as quickly as possible).
Think of cards as kanbans requesting features. The customer pulls features from the ‘done’ end, but because the feature needs to pass through each stage the kanban gets passed all the way back to the backlog. Obviously in practice it just starts in the backlog like a normal story card.
WIP limit of three in live (one per pair). Also have ‘blocked’ drawer off to the side, and yellow non-story cards for technical debt repayment etc. When a pair is available to work on a new story, agree with customer which one, and clarify acceptance criteria. Photos stuck on to show who ‘owns’ development of a story.
Bugs found after delivery are added to live stories on red cards, and addressed ASAP.
We write the ‘done’ date on each card so we can (kind of) track how fast we’re delivering. We ought to also note when the story moved out of (and possibly into) the backlog.
We currently aren’t estimating stories, but were previously using points. An alternative is to split stories until they’re all approximately the same estimated size, then just count stories in stead of points.
By recording when a story moved into ‘live’ and then into ‘done’, we can calculate a rough cycle time figure. This allows us to provide an ‘estimated queuing time’ (like Alton Towers). The same could be done for the beginning of the backlog.
Lean seems to focus more on cycle time than throughput, but we can also use the same numbers to estimate how far through the backlog we expect to get in a particular period of time. In practice we’ve found that the backlog stories and their priorities change too fast to make this a useful figure.
This was something we tried for a while, but it didn’t seem to provide much value and I was fed up with being the only person to ever update it.
Basically a chart of the size of each lane over time. Provides some visual indication of progress (or lack of it) and bottlenecks.
Simpler! Less time spent analysing stories in backlog. Less exposure to customer changing his mind. Acceptance/demo/deployment can happen at any time. No faffing around figuring out what to do with stories that cross the iteration boundary. Stories can be larger if necessary. Exposes bottlenecks.
Less explicit visibility of progress. May need different tools (ie not Scrumworks) if you can’t use a physical board.
Expanding this approach to multiple dependent teams could be interesting.
More like a production kanban system.
Customer requests (pulls) new feature from one team. They need additional functionality from a different team/system, so submit a request which they treat as a new story.
Potential issues with prioritisation if there are multiple customers or downstream process pulling from a single team (but the same happens with Scrum/XP if there isn’t a single customer/product owner).
Kanban and Iterationless Working
Kanban & Iterationless
Kerry Buckley, 20 May 2009
“A one- to four-week period. At the
beginning, the customer chooses the
stories to be implemented in the
iteration. At the end the customer
can run their functional tests to see
if the iteration succeeded.”
“A short burst of work lasting
approximately 30 days during
which an executable and other
deliverables are built by an
engineering team, as indicated by
the assigned backlog.”
“ Our highest priority is to satisfy
the customer through early and
continuous delivery of valuable