• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Little bits of cardboard - a Kanban case study
 

Little bits of cardboard - a Kanban case study

on

  • 2,766 views

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.

Statistics

Views

Total Views
2,766
Views on SlideShare
2,763
Embed Views
3

Actions

Likes
1
Downloads
62
Comments
0

1 Embed 3

http://www.slideshare.net 3

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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

Little bits of cardboard - a Kanban case study Little bits of cardboard - a Kanban case study Presentation Transcript

  • Little bits of cardboard
    A study of a project using Kanban processes
  • 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
  • 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
  • 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
  • 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
  • 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.
  • Problems
    Story card
    Blocked
    • 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
    Story card
    Story card
  • 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
  • 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.
  • 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
  • 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
  • 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!”
  • 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.
  • 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
  • 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.
  • 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
  • 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?
  • 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
  • Thank you