Kanban and Iterationless Working
•Descargar como ZIP, PDF•
0 recomendaciones•393 vistas
Slides from a talk to our project team at work.
Recomendados
Más contenido relacionado
Similar a Kanban and Iterationless Working
Similar a Kanban and Iterationless Working (20)
Más de Kerry Buckley
Más de Kerry Buckley (19)
Último
Último (20)
Kanban and Iterationless Working
- 1. Kanban & Iterationless Working Kerry Buckley, 20 May 2009
- 3. 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.”
- 4. 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.”
- 5. Agile “ Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
- 6. Iterating vs Iterations
- 8. Waste ( ) • Overproduction • Waiting • Transporting • Inappropriate Processing • Unnecessary Inventory • Unnecessary or Excess Motion • Defects
- 9. 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
- 10. Kanban
- 11. Push A B
- 12. Pull A B
- 14. Implement Impl Prio Plan Impl Impl Impl Accept Deliver Impl Impl Impl (oops)
- 15. WTSTTCPW?
- 16. Pick Impl Accept Deliver Pick Impl Accept Deliver Pick Impl Accept Deliver Pick Impl Accept Rework Accept Deliver
- 17. Our System
- 21. Advantages
- 22. Disadvantages
- 23. Multiple Teams?
- 24. end
Notas del editor
- 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).