Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Little bits of cardboard - a Kanban case study

2,948 views

Published on

Case study of implementation and adaptation of Kanban processes onto a software development team.

Published in: Technology, Business
  • Be the first to comment

Little bits of cardboard - a Kanban case study

  1. 1. Little bits of cardboard <br />A study of a project using Kanban processes<br />
  2. 2. New infrastructure project<br />Unknown and rapidly emerging requirements. <br />Architecture evolved as the project progressed.<br />New clients for the product meant rapidly emerging requirements<br />The application had to be deployed ASAP to meet contractual obligations<br />Details<br />
  3. 3. The project was at a standstill, cards were not moving across the board. <br />Large numbers of cards clogged the board and the team felt paralysed.<br />It was difficult to prioritise, as the backlog was so big and undefined<br />4 months of development work done with no production deployment of any code.<br />Problems<br />
  4. 4. The board before<br />Story card<br />Ready<br /> for test<br />Test failed<br />In test<br />Backlog<br />Signed off<br />Blocked<br />In Dev<br />Ready for Dev<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Jim<br />Jim<br />Mel<br />Mel<br />Tom<br />A story board can provide a lot of information about a team and how it is performing.<br />The team board had a lot of signals about were problems were occuring<br />
  5. 5. Problems<br />Story card<br />Ready<br /> for test<br />Test failed<br />In test<br />Backlog<br />Blocked<br />In Dev<br />Ready for Dev<br />Large backlog column:<br />The backlog column contained upcoming stories for the entire project<br />Competing priorities meant the development effort wasn’t focused<br />Stand ups tended to focus on backlog items that hadn’t even made the “Ready for Dev” – (current sprint) column.<br />Time was spent estimating and planning on stories that never ended up getting prioritised<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Jim<br />Jim<br />Mel<br />Mel<br />Tom<br />
  6. 6. In Dev<br />Story card<br />Story card<br />Story card<br />Story card<br />Jim<br />Jim<br />Mel<br />Mel<br />Tom<br />Problems<br />Team members were deployed across multiple cards, they found it frustrating and difficult to focus on getting things done.<br />
  7. 7. Problems<br />Story card<br />Blocked<br /><ul><li>Story cards would land in the blocked column and often stay there for days
  8. 8. The reasons for this were varied, but there was a lack of ownership or urgency</li></ul>Story card<br />Story card<br />
  9. 9. After a few different approaches were discussed, we trialled a Lean/Kanban approach/process<br /> This helped us focus on our constraints and get back to getting things done.<br />What we did next<br />
  10. 10. What is Kanban<br /><ul><li>This is Kanban</li></ul>Story card<br />Limit Work In Progress<br />Only start a new task/item when last item was complete<br />Balance demand against throughput <br />The cards become signals (Kanban) to indicate when something needs to happen<br />Creates a pull system where an empty slot triggers a demand for a card further up the supply chain.<br />
  11. 11. We started by limiting WIP (Work in progress) on the swim lanes, including the “In analysis” and “ready for Dev” lanes<br />How we got there<br />
  12. 12. Limiting WIP<br />Story card<br />Ready<br /> for test<br />2<br />Ready for <br />Sign off<br />3<br />In Analysis<br />2<br />Ready for Dev<br />2<br />In test<br />2<br />Signed off<br />Parking lot<br />In Dev<br />2<br />Something to talk about tomorrow<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Ben<br />Tom<br />Mel<br />Jim<br />Cards on the lanes limited to available pairs in the sprint.<br />New cards are demand pulled into the lanes to reach capacity as cards are completed and moved across.<br />Developers only allowed to be on ONE card<br />This ensured the cards coming through were really the “highest” priority<br />Helped minimise discussion and pre-work on low priority cards <br />
  13. 13. Worked out what the bare minimum was to get our “first” production release out, even if it meant the application was feature poor. <br />This was what is termed a “MMF” or “Minimum marketable feature”<br />Allowed us to target incremental delivery rather than “big bang”<br />if nothing else, this helped prove the “Path to Production” getting early feedback on performance across all your environments in invaluable.<br />“Please, just let us release something!”<br />
  14. 14. Release token/card<br />Story card<br />Ready<br /> for test<br />2<br />Ready for <br />Sign off<br />3<br />In Analysis<br />2<br />Ready for Dev<br />2<br />In test<br />2<br />Signed off<br />Parking lot<br />In Dev<br />2<br />Something to talk about tomorrow<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Ben<br />Tom<br />Mel<br />Jim<br />Release Card<br />Tom<br />JT<br />We introduced a “Release” token which followed the last of the cards in the MMF across the board. <br />This card behaved just as any other card did, occupying slots and requiring owners<br />Any card that followed the release card was not checked into the main trunk until after the release card was “signed off” – which meant deployed <br />We released when we had enough, not at the “end” of a sprint cycle.<br />
  15. 15. Reducing clutter/confusion<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Mel<br />Jim<br />Ready<br /> for test<br />2<br />Ready for <br />Sign off<br />3<br />In Analysis<br />2<br />Ready for Dev<br />2<br />In test<br />2<br />Signed off<br />Parking lot<br />In Dev<br />2<br />Something to talk about tomorrow<br />Reduced the amount of clutter that was on the board by removing the backlog column<br />Backlog items were removed and placed out of immediate sight <br />Removed the blocked column, changed how “blocked cards were dealt with” <br />Blocked cards had to find an owner, and therefore a swimlane, or were deprioritised<br />
  16. 16. Adding buffers<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Mel<br />Jim<br />Ready<br /> for test<br />2<br />Ready for <br />Sign off<br />3<br />In Analysis<br />2<br />Ready for Dev<br />2<br />In test<br />2<br />Signed off<br />Parking lot<br />In Dev<br />2<br />Something to talk about tomorrow<br />We got excited about removing lanes so;<br />We removed the test failed lane and created a buffer zone above “In Dev”. These cards were considered the highest priority in that lane.<br />Buffers added to other lanes as well, these helped create strong signals of constraints in the system that needed to be acted upon.<br />
  17. 17. Sprint cycle and release cycle were “uncoupled”<br />Planning was done, as required, not by timetables <br />Retained sprint cadence for “retros” and “demos”<br />Team aggressively split cards to look for smallest item of “business value”<br />Having limited “fixed backlog” meant we could react very quickly to change<br />Rolled technical stories into stories that deliver business value forced us to change course slowly and justify changes, also reduced Technical debt<br />What changed<br />
  18. 18. Delivering a constant stream of small but valuable stuff into production every week is VERY motivating.<br />Splitting stories can reveal just how little business value certain aspects of stories contain<br />We almost never get through everything that was “planned”<br />We almost always ended up doing stories that weren’t “planned”<br />Just-in-time stories can enable the business to leave decision of what’s important to the last possible moment.<br />Trying to deliver everything to everyone can lead to delivering nothing at all to anyone <br />What did we learn?<br />
  19. 19. Simplifies workflow<br />Reduces confusion<br />Encourages small incremental releases<br />Accepts and encourages change<br />Teams with highly flexible backlogs (BAU, support) are ideal candidates for Kanban<br />Allows teams to focus on their constraints and support them<br />Is motivating to developers<br />Forces prioritisation by limiting WIP <br />Works well for new product development teams<br />Take home message<br />
  20. 20. Thank you<br />

×