Little bits of cardboard	<br />A study of a project using Kanban processes<br />
New infrastructure project<br />Unknown and rapidly emerging requirements. <br />Architecture evolved as the project progr...
The project was at a standstill, cards were not moving across the board. <br />Large numbers of cards clogged the board an...
The board before<br />Story card<br />Ready<br /> for test<br />Test failed<br />In test<br />Backlog<br />Signed off<br /...
Problems<br />Story card<br />Ready<br /> for test<br />Test failed<br />In test<br />Backlog<br />Blocked<br />In Dev<br ...
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 />P...
Problems<br />Story card<br />Blocked<br /><ul><li>Story cards would land in the blocked column and often stay there for days
The reasons for this were varied, but there was a lack of ownership or urgency</li></ul>Story card<br />Story card<br />
After a few different approaches were discussed, we trialled a Lean/Kanban approach/process<br /> This helped us focus on ...
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...
We started by limiting WIP (Work in progress) on the swim lanes, including the “In analysis” and “ready for Dev” lanes<br ...
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...
Worked out what the bare minimum was to get our “first” production release out, even if it meant the application was featu...
Release token/card<br />Story card<br />Ready<br /> for test<br />2<br />Ready for <br />Sign off<br />3<br />In Analysis<...
Reducing clutter/confusion<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card...
Adding buffers<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story card<br />Story ...
Sprint cycle and release cycle were “uncoupled”<br />Planning was done, as required, not by timetables <br />Retained spri...
Delivering a constant stream of small but valuable stuff into production every week is VERY motivating.<br />Splitting sto...
Simplifies workflow<br />Reduces confusion<br />Encourages small incremental releases<br />Accepts and encourages change<b...
Upcoming SlideShare
Loading in...5
×

Little bits of cardboard - a Kanban case study

2,456

Published on

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

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,456
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
65
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • This shows a typical agile story board. There is an area for the sprint backlog, the Work in progress and signed off work.
  • Japanese for “visual (kan) card(ban)”Kaizen – improvement (pause, reflect, adapt)Muda - waste
  • Transcript of "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 />
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×