Your SlideShare is downloading. ×
Little bits of cardboard - a Kanban case study
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Little bits of cardboard - a Kanban case study

2,397
views

Published on

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

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,397
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
64
Comments
0
Likes
1
Embeds 0
No embeds

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
  • 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

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