Kanban and Iterationless Working
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Kanban and Iterationless Working

  • 1,755 views
Uploaded on

From the BT Developer Day held at Osmosoft on 20 Jan 2010.

From the BT Developer Day held at Osmosoft on 20 Jan 2010.

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,755
On Slideshare
1,753
From Embeds
2
Number of Embeds
1

Actions

Shares
Downloads
15
Comments
0
Likes
1

Embeds 2

http://www.slideshare.net 2

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Waterfall
  • 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.
  • 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.
  • A quick detour into Lean Manufacturing (Toyota Production System). I am not an expert! One of the key aspects of 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. Iterative development removes a lot of waste, but fixed iterations can still cause unnecessary waiting (for a feature to be planned into an iteration, and for an iteration to be deployed), and any completed features not deployed are 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.
  • Backlog sorted into themes. Queue for top few backlog items (chosen by customer). Now have queue, analysis, development, acceptance and done. Explicit criteria for moving between stages. WIP limit for each stage. Buffers for features which have met transition criteria but don’t fit in next stage because of WIP limits. Done means accepted by customer and deployed on live system. Expedite lane for emergency stories (not subject to WIP limit). We don’t often use it.
  • 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 and imbalances.
  • Less explicit visibility of progress. Miss satisfaction and celebration from completing an iteration.

Transcript

  • 1. Kanban & iterationless working
    • Kerry Buckley, 20 January 2010
  • 2. Iteration
  • 3. In the beginning was the waterfall
  • 4. Plan Design Impl Test Deliver Plan Design Impl Test Deliver Plan Design Impl Test Deliver Plan Design Impl Test Deliver
  • 5. Why iterations?
  • 6. XP: iteration
    • “ 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.”
  • 7. Scrum: sprint
    • “ 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.”
  • 8. Agile
    • “ Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
  • 9. Agile
    • “ Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
  • 10. Learning from Lean
  • 11. Waste ( 無駄 )
    • Overproduction
    • Waiting
    • Transporting
    • Inappropriate Processing
    • Unnecessary Inventory
    • Unnecessary or Excess Motion
    • Defects
  • 12. Waste ( 無駄 )
    • Overproduction – Extra Features
    • Waiting – Waiting, Including Customers
    • Transporting – Handoffs
    • Inappropriate Processing – Extra Steps
    • Unnecessary Inventory – Backlog; Undeployed Code
    • Unnecessary or Excess Motion – Finding Information
    • Defects – Defects Not Caught by Tests
  • 13. Kanban 看板 看板
  • 14. Push A B
  • 15. Pull A B
  • 16. Waste in Iterations
  • 17. Prio Plan Impl Impl Impl Accept Deliver Implement Impl Impl Impl Impl (oops)
  • 18. WTSTTCPW?
  • 19. Pick Impl Accept Deliver Pick Impl Accept Deliver Pick Impl Accept Deliver Accept Rework Accept Deliver Pick Impl
  • 20. Our first attempt
  • 21.  
  • 22. Retrospection
    • WTF does that card mean?
    • ‘Done’ stories not being deployed
    • Missing regular celebration of completion
    • Unwieldy backlog
    • Can get away with very little estimation
  • 23. Iteration two!
  • 24.  
  • 25. Estimation and tracking
  • 26.  
  • 27. Advantages
  • 28. Disadvantages
  • 29. end