1. Kanban in IT
    1. Government
      1. Ministry of Social Development - New Zealand - Russel Healy - 2011
        1. Context
          1. Christchurch Earthquake Employment Support System (payment of subsidies)
          2. Online Application system to distribute relief subsidies
          3. External consultant brought in to lead the project
        2. The Story
          1. Feb 2011 New Zealand earthquake @ Christchurch
          2. most of business district destroyed
          3. 2 days later, the Government of NZ announces that people could apply for a subsidy. The system to do so didn't exist yet
          4. The challenge was to build the system in 6 weeks
          5. After a weekend of development, chaos & confusion ensues
          6. Subtopic 1
          7. The stress makes the PM leave
          8. Russel is brought in to help
          9. It was unclear what was going on
          10. Rusel started by creating a tracking board
          11. Workflow
          12. Tasks
          13. Who was working on what
          14. Visualization of all the work showed lots of WIP
          15. Team was overburdened and stressed
          16. Limit of WIP to 2 per person
          17. Sustainable pace and focus on delivery
          18. There was large "cloud" of requirements
          19. Repleshisment meeting introduced, with a 2 day horizon
          20. Prioritization question: "what functionality do users need in 2 days?"
          21. Small tasks & small batches
          22. Two releases a day
          23. Continuous management of end-to-end flow (from commitment to release)
        3. Effects
          1. Sense of calm and progress, relief from stress
          2. Transparency of status for all stakeholders
          3. Engagement and shared understanding for the whole team
          4. Removal of interruptions
          5. Rapid delivery
          6. 1 day lead time for features
          7. system in production in matter of days
          8. new releases deployed twice a day
          9. IMPACT: The smallest number of business failures after any comparable natural disaster anywhere in the world
      2. Government of Quebec Tax Agency - Canada - Nicolas Mercier & Frédéric Paquet - 2016-17
        1. Context
          1. Government PMO
          2. Portfolio Kanban
          3. External consultants (CGI) to coach senior leadership
        2. The Story
          1. Traditional project challenges
          2. Project planning
          3. Iron Triangle
          4. Recursive padding
          5. Watermelon indicators
          6. Plan becomes Sci-Fi
          7. To keep projects alive, you need an army of PCOs and PMs
          8. You still can't answer the question of "how are projects going?"
          9. Started at the team level
          10. Agile training (Kanban principles & values)
          11. Maturity Model
          12. Reveal
          13. Stabilize
          14. Thrive
          15. Result: good at team level, but no impact at all at the portfolio level
          16. Change of strategy: Flight Levels
          17. Visualize the system as a whole, at project level
          18. People talking in front of the board brought visibility and understanding
          19. Concluded that there was too much WIP
          20. We started limiting WIP (soft limits)
          21. Noticed that there was no feedback loop at the coordination level (in between portfolio and teams)
          22. Noticed more problems: WIP, dependencies, competing objectives
          23. Focus on managing end-to-end flow
          24. decentralized decisions (pushing down decisions from portfolio down to coordination or team)
          25. Increased trust
          26. support the system
          27. Implemented "kaizen events" for continuous improvement
          28. Next: going outside IT
      3. Department of Labor - USA - Joey Spooner - 2015-16
        1. Context
          1. Office of Public Affairs, Electronic Communications division
          2. Several applications to be maintained
          3. QA & Release service for other departments
          4. Project in risk of failure
          5. Kanban used to stabilize and evolve Scrum (Scrumban)
          6. External coach working with department manager
        2. The Story
          1. Proto-Kanban stage (2015)
          2. They had tried Scrum initially, and the Developers loved it
          3. Started by visualizing the work end-to-end, leaving Scrum untouched
          4. individual tasks grouped by story
          5. Different types of work visualized separately
          6. Explicit process steps
          7. Introduced new ticket design to show ownership and trackign dates for each process step
          8. Replaced sprint planning with "batches" of 3 weeks of work
          9. Introduced data to the retrospectives, and using it to make decisions
          10. Full Kanban stage
          11. Started doing some Kanban training with getKanban
          12. Designed new Kanban system using the Kick-start guide
          13. Introduced Kanban cadences
          14. Replenishment replaced sprint planning
          15. Daily standups focused on blockers rather than people reporting
          16. SDR instead of Retrospectives
          17. Delivery planning instead of release sprints
          18. Replaced story points with "standardize sizing"
          19. This exposed work poorly specified/understood
          20. Portfolio board (above the teams) was eventually created
        3. Effects
          1. Visual representation of what was being delivered
          2. Data available to analyze what was going on
          3. Better collaboration between development/QA
          4. Process improvements introduced upstream (better Analysis)
          5. Better predictability through forecasting
          6. Increased ability to take on improvement initiatives
    2. Banking & Financial Services
      1. Private Bank - Germany - Susanne Bartel - 2016-17
        1. Context
          1. Company: Private Bank in Germany
          2. Scope: IT Department (Operations)
          3. Kanban + SAFe
          4. External coaches brought in as team trainers & coaches
        2. The Story
          1. Training sessions
          2. STATIK
          3. Team workshops to understand roles
          4. Revisit motivation of change
          5. Agile intro workshops
          6. Immersion Workshops w/Flowlab for Managers
          7. Boards started appearing
          8. Portfolio management
        3. Effects
          1. Transparency
          2. Empathy
          3. Trust
          4. Common language
          5. Insights about capability
      2. PingAn Bank - China - Adam Wu - 2017
        1. Context
          1. Large bank in China
          2. Credit Card division
          3. Kanban + "Spotify model"
          4. External coaches working with leadership & teams
        2. The Story
          1. Empower the CTO
          2. Break the silos, reorg into tribes (Spotify)
          3. Setup requirements hierarchy
          4. Visualize the flow
          5. Establish release and communication cadences
          6. Establish operations review and flow conditioning mechanism
          7. Build quality in
          8. Metrics to measure results
      3. CapitalOne - USA - Eric Green & Christina Murto - 2015-17
        1. Context
          1. Digital Bank
          2. Agile transformation was getting stale
          3. Scrum
          4. SAFe
          5. Team Kanban
          6. 150 teams, 10 organizational areas
          7. External consultant + internal coaches, through enterprise transformation office
        2. The Story
          1. Be like water to avoid resistance
          2. Opt-in model
          3. Support for change agents
          4. Broad socialization of results to Leadership
          5. Blocker clustering
          6. Leaders "walk the walls"
          7. Training program
          8. "process archeology" (modified STATIK)
        3. Effects
          1. Increased in throughput
          2. Decreased time to market
          3. Increased susainability (work-life balance)
          4. Increases social capital (trust)
      4. JP Morgan Chase - USA - Adam Hsu - 2013-17
        1. Context
          1. Large IT organization
          2. Slow adoption of Agile in the organization, mostly with Scrum
          3. Internal Organizational Coach
        2. The Story
          1. Started with an assessment of current practices
          2. "I want you to go do something different" (non prescriptive direction for change)
          3. We started with Scrum
          4. There was some good experience with Scrum, we decided to build on that
          5. One of the teams volunteered to go first (The Innovators)
          6. Good results with the first team generated interest in more teams
          7. We started looking into Kanban as alternative to Scrum
          8. Then team came and said they didn't think Scrum wouldn't work for them (service/ops team)
          9. Other teams started finding that Scrum wasn't working with them
          10. We started learning about Kanban; later, became AKTs
          11. Created our own Kanban 101 training program
          12. Teams started getting good results, and asking for more
          13. We started seeing (shallow) Kanban appearing everywhere
          14. Personal Kanban
          15. Aggregated Team Kanban
          16. Basic WIP control
          17. We started doing STATIK, to mix Scrum with Kanban
          18. Crossing the Chasm
          19. Exploit the Niche (dissatisfaction with Scrum)
          20. teams inundated with demand beyond software development (maintenance, defects, prod support, etc.)
          21. teams supporting tools for other teams
          22. teams taking too much work into their sprints
          23. teams feeling constrained by ceremonies
          24. teams spending more time refining stories than doing work
          25. teams frustrated by waiting for external dependencies
          26. More social proof
          27. Leaders telling their story to other leaders
          28. Annual internal conference
          29. Mass communication (newsletters)
          30. More advanced training (KMP)
          31. Late Majority kicks in: more teams come asking for help
          32. Kanban expands to the "intake"
      5. Fannie Mae - USA - Mick Ahmad & Vikas Kapila - 2017
        1. Context
          1. Housing Market Insurance
          2. Some agile adoption wrapped in a traditional Waterfall SDLC
          3. Waterfall mindset
          4. Perception of Kanban as only for production support
          5. Some agile adoption in form of Scrum, but mostly as mini-waterfalls
          6. ALM Tool migration project
          7. Replacing Aging infrastructure & tooling
          8. Difficulty implementing DevOps
          9. 180 project teams
          10. Internal Product Manager, external consultant
        2. The Story
          1. Initially, Scrum was introduced
          2. Project Managers sent to training
          3. Agile terminology adopted, but not the behaviours
          4. After 6 months the Tooling team hadn't delivered anyting; busy work and "churn"
          5. Leadership recognized the urgency
          6. External consultant (AKT) brought in as Product Manager
          7. Dedicated Product Owner (from the company)
          8. Dedicated, cross-functional end-to-end team
          9. Understanding the current process
          10. Anatomy of Lead Time: 67% waiting time
          11. Sources of waste (using 7 Wastes from Lean)
          12. Product Manager introduced new ideas
          13. Roadmap and prioritization for the product
          14. Kanban practices for teams
          15. Prioritization and sequencing based on CoD
          16. Kanban cadences (up to SDR)
          17. Program-level Kanban
        3. Effects
          1. Project rescued: Tool delivered by 7 team members in 8 weeks
          2. Increased visibility
          3. Predictable cadence of delivery
          4. Incremental roadmap
    3. Retail
      1. Ocado - UK - Anna Miedzianowska - 2017
        1. Context
          1. Largest online only grocery retailer
          2. Portfolio Kanban
          3. Head of Product leading the design of the board
        2. The Story
          1. Our ecosystem of teams is complicated: lots of dependencies
          2. Our focus was on getting teams more efficient, but we forgot about the Customer Lead time
          3. Lots of waiting time in between teams
          4. Local prioritization (done by each team) introduces further delay
          5. Step 1. Introduce a portfolio wall
          6. Visualized workflow end-to-end
          7. Visualize all "major" project work only
          8. Standardized project card
          9. Sponsor & Owner
          10. Deadline
          11. Elevator Pitch
          12. 1. What?
          13. 2. Why?
          14. 3. How?
          15. 4. Success
          16. 5. Risks
          17. 6. Benefits
          18. 7. Failure
          19. Teams working on it
          20. Lots of initial push back from POs
          21. Yet another meeting, listening to things not relevant to me
          22. Why do I need to justify what the sponsors need?
          23. Are you going to change my decisions?
          24. Why isn't this digita? what about remote people?
          25. We found one team was listed in most cards and had become the bottleneck
          26. It led to the question of: could there be other cases like this?
          27. Step 2. Visualize ALL work
          28. We noticed there was LOTS of stuff going on
          29. Board became unusable
          30. Step 3. Goal oriented product wall
          31. In Progress column organized in Goal Lenes
          32. Rock solid platform
          33. Customer Experience
          34. Sell More
          35. More Capacity
          36. Reduce Operational Cost
          37. Special lanes
          38. On Hold
          39. Expedite
          40. Unknown goal (?)
          41. Step 4. Expose flow bottlenecks
          42. Let's put a dots for each week the project is still on the board
          43. The result was cards covered in dots!
          44. Started visualizing team capacity with colours
          45. Green: team can accept new work
          46. Yellow: team busy for some time; can't take new work
          47. Red: team struggling, needs help
          48. Step 5. Visualize completion level (0-100%)
          49. Most projects were "almost done" all the time
          50. We introduced visualization of Cost of Delay
          51. Next Step: shift focus & forecasting
          52. We talk about blockers
          53. Otherwise, shift focus
          54. Let's talk about what's new and coming
          55. Let's talk about what we're learning from delivered items
          56. We have lots of data, we can simulate and forecast instead of estimate
        3. Lessons
          1. Get everyone together first
          2. Start simple, build together
          3. Be clear on WHY
          4. Retrospect often
          5. Central, accessible location (for the board)
          6. Celebrate
    4. Food Services
      1. McDonald's/RDI - Brazil - Rodrigo Rosauro - 2012-17
        1. Context
          1. Originally a Subsdiary of McDonald's, now a Capgemini company
          2. Restaurant automation & e-commerce software used at restaurants
          3. From Scrum to Kanban
          4. Internal Team Lead (later KCP)
        2. The Story
          1. The Customer becomes unhappy
          2. 18-month lead time was considered a threat to the dominance in the market
          3. Long test & stabilization periods required to release
          4. New software architecture was introduced, and was taken as opportunity for introducing new process
          5. Scrum came into play
          6. Felt awkward
          7. Lots of time spent in meetings
          8. Overtime right from the beginning
          9. The problem was a steep learning curve we didn't have time for
          10. What if we try Kanban?
          11. Started with visualization; started to note bottlenecks
          12. We didn't really change the process, but the flow improved
          13. Then we decided to take formal Kanban training (KMP)
          14. Kaizen
          15. Moved to digital board (Jira)
          16. Added "waiting" columns to the board
          17. JIT replenishment & refinement
          18. QA as part of the team
          19. WIP limits
          20. x-functional swarming
          21. Then the Business comes up with an idea they wanted to try
          22. Implemented end-to-end delivery kanban, with Customer involved
          23. Business could add or remove feature requests as long as it wasn't started yet
          24. We failed fast! :-)
        3. Effects
          1. Project achieved a 6-fold improvement in Time to Market
          2. A whole new development experience for the business that enabled experimentation and change
    5. Travel
      1. eDreams Odigeo - Spain & Europe - Ivan Font - 2016
        1. Context
          1. Company-wide transformation
          2. Team, ESP
          3. Internal coaches & trainers, working with leadership & teams
        2. Coaching model
          1. 3 full time coaches (FTEs)
          2. Engagement model
          3. Setup
          4. Team Assessment
          5. Kanban Training
          6. Flow Design
          7. Boost/Continuous Support
          8. Continuous Improvement
          9. Coach stays with the team until Boost stage
          10. Team has a "flow manager" rotating role
        3. Story
          1. Sources of Dissatisfaction
          2. Slow product development
          3. Complex dependencies
          4. Long prioritization process
          5. No way to measure capacity
          6. Awkward estimation process
          7. 300% overtime
          8. Lost business opportunities
          9. Long lead times
          10. Silos
          11. Started by breaking silos
          12. x-functional teams
          13. Service teams
          14. Effects
          15. Less dependencies
          16. Improved coordination
          17. improved transparency
          18. improved maintenance
          19. No connection to business outcomes
          20. New goal: Autonomous teams
          21. First step: Product Organization
          22. 3 "Scout" teams first, the rest later
          23. Hired full time coaches
          24. Connected them to the organization
          25. ESP training
          26. Basic Kanban training
          27. STATIK
          28. Metrics
          29. Team roll-out Metrics
          30. Team Healthchecks
          31. Lead Time
          32. Flow Efficiency
          33. Depth of Kanban
          34. Connecting Services
          35. Feedback loops
          36. Working agreements around dependencies
          37. Next steps
          38. SLAs per team
          39. ESP cadences
          40. Portfolio
          41. Kanban in the business
          42. What hapenned then? (2018)
          43. Autonomous teams didn't work very well
          44. Work on Communication & social networks
          45. Systems Thinking
          46. Domains by E-to-E value chains
      2. Best Day - Mexico - Ivan Font - 2018
        1. Context
          1. Company-wide transformation
          2. Team & Portfolio level
          3. Internal coach/trainer working with teams
        2. The Story
          1. Initial state
          2. Shadow teams
          3. Perception of slow development
          4. Complex dependencies
          5. Little measurement
          6. Awkward estimation process
          7. HIPO/long prioritization process
          8. High degree of variation in delivery
          9. Demand higher than capacity
          10. 1st step: Manage demand at Portfolio level
          11. Demand shaping
          12. POD model with x-functional teams
          13. 2nd step: Product Organization Pilot
          14. Better communication
          15. Greater transparency
          16. Greater commitment
          17. Focus in UX
          18. Better balance between demand & capability
          19. greater frequency of delivery
          20. greater collaboration between initiatives
          21. greater self-management
          22. 3rd step: Product Org roll-out
          23. Kanban training team by team
          24. Product Management training
          25. Kanban boards
          26. Making it social to promote learning
          27. Lean coffee
          28. book clubs
          29. 4rd step: Working on Management Culture
        3. Challenges
          1. Visualization slow at the beginning, then catches on
          2. Limiting WIP is the hardest
          3. Manage Flow requires an 'aha!' moment because it's counterintuitive
          4. Feedback loops: don't focus only on the "bad news"
          5. Improvement and evolution: very hard to setup metrics
    6. Social Networking
      1. Tupalo - Austria - Nina Schwab - 2010-17
        1. Context
          1. Local businesses review ("Your Local Guide")
          2. Trivago competitor
          3. Small start-up
          4. Project Manager leading Kanban adoption
        2. The Story
          1. Internal dissatisfaction
          2. not advancing the core product
          3. Too many projects
          4. Priorities not clear
          5. not enough transparency
          6. Started with Development
          7. Kanban board 1
          8. Kanban board 3: multi-level
          9. Later, moved to other departments
          10. Community Management
          11. Marketing
          12. PR
          13. Events/Campaigns
          14. Dropped estimation eventually and replaced it with small work items
          15. Most meetings eventually were done on-demand, rather than on a schedule
          16. Then, the business context changed, and the company had to change, including more remote work
          17. Digital, online Kanban tool introduced
        3. Effects
          1. faster delivery, more focus (WIP Limits)
          2. more transparency, communication (stand-up meetings)
          3. better prioritization (through CoS, queue policies)
    7. Healthcare Services
      1. Optum - USA - Jeanine McGuire - 2016
        1. Context
          1. Health care analytics
          2. Global organization, lots of telecommuters
          3. Six Sigma culture
          4. Dragos was here
          5. Internal AKTs working through a Transformation initiative
        2. The Story
          1. Growth challenge, lots of change, do more with less
          2. Enterprise transformatio program (Apex)
          3. online training modules
          4. online knowledge base
          5. Reading list
          6. Quick reference
          7. Tools & Templates
          8. Discussion forums
          9. Maturity assessment (for Leaders!)
          10. Self-assess in 5 dimensions
          11. Integration across their value chain
          12. Foundation (documentation of process)
          13. Performance management (metrics)
          14. WIP management (Kanban)
          15. Automation
          16. Continuous improvement
          17. Leaders expected to create an action plan
          18. adoption activities
          19. expert guidance & support
          20. Kanban adoption
          21. 2 tools
          22. CA Agile
          23. Swift Kanban
          24. Training
          25. Kanban 101
          26. KMP 1 (through internal AKTs)
          27. Tool specific training
          28. Technology Services (workstation infrastructure support)
          29. "we're missing our SLAs", too much WIP
          30. People sent to training, identified WIP limits as solution
          31. Daily huddles review analytics
          32. Project work kept in a separate Kanban board
          33. IT Engineering Team
          34. Process codified in work types with checklists
          35. Customers identified through parent/child relationships in kanban tool
          36. Reduced admin costs by reducing time per ticket
          37. Software Development Team
          38. Kanban board with explicit policies
          39. analytics used in daily huddles
        3. Lessons
          1. Professional training investment paid off
          2. Integration with corporate learning channels was key
          3. Internal AKTs really helped
          4. Post-training coaching is challenging. Teams get stuck at proto-Kanban, frustrated, abanon
          5. Misconception of Kanban as IT-only tool
          6. Internal sharing of case studies enables learning
    8. Digital Product Dev Services
      1. Optimizely - USA - Jeff Zych & Keith Nottonson - 2016-17
        1. Context
          1. A/B testing products
          2. From Scrum to Kanban/ESP
          3. Upstream/Discovery Kanban
          4. Head of Design leading change of process; internal coach supporting
        2. The Story
          1. Scrum had reached its limits
          2. Designers didn't have a space to do their work
          3. Research has no place in Agile
          4. Product Managers were too caught up with the ceremonies of Scrum and didn't have time to understand their customers
          5. Engineers had to do lots of rework when designers introduced changes
          6. Stakeholders unhappy because they couldn't get their requests in
          7. Customers unhappy with quality
          8. Process in general optimized for delivery but not for discovery
          9. We decided to separate Discovery from Delivery, and visualize the flow
          10. Kanban cadences introduced later, and evolved over time
        3. Effects
          1. Improved coordination and alignment
          2. Throughput doubled
          3. Saved lots of time from meetings
          4. happier designers & researchers
          5. Better prioritization (including saying NO)
  2. Kanban outside IT
    1. Health Care / Hospital
      1. Salvation Army Bongsu Hospital - Indonesia - Marcus Hammarbeg - 2013
        1. Context
          1. Hospital recovery after roof collapsed
          2. Non-IT case study
          3. General work management
          4. Executive coach working with managers
        2. The Story
          1. Reconstruction effort
          2. Targets to profitability
          3. Empowering the General Manager
    2. Architecture & Engineering
      1. Clark Nexsen - USA - William Keen - 2016-18
        1. Context
          1. Construction, Bridge Inspection
          2. Scope: Projects, Departments
          3. Managers working as coaches/trainers
        2. The Story
          1. Two experiments
          2. Architectural Project (building)
          3. Two Engineering Deptartments: Infrastructure & Transportation
          4. Started with Training
          5. 3 agendas, principles, values
          6. Simulations
          7. Modeled the work
          8. Daily Meetings
          9. Regular reflections
        3. Effects
          1. Quality
          2. Profitability
          3. Insights
    3. Training Services
      1. Middlegrass - USA - Melinda Solomon - 2012-17
        1. Context
          1. Agile Training program for the US Federal Government
        2. The Story
          1. Started with a request to create a training class, that became so popular that created lots of demand
          2. We had to make sense of the chaos
          3. visualize all the work
          4. get all the commitments on the wall
          5. What is all this stuff?
          6. various sources of work
          7. Federal Agency
          8. Student Evals
          9. Agency outreach
          10. Contractor management
          11. 6 major types of work
          12. Development of New courses
          13. Regularly-scheduled classes
          14. Agency briefings
          15. Course content updates
          16. Regulatory/remote enhancements
          17. Unplanned work (ad-hoc)
          18. Visualization
          19. 3 boards
          20. New Opportunities
          21. Upcoming classes (fixed-date items)
          22. Other Work
          23. LImit WIP
          24. We did this after getting really good at visualizing work
          25. Started with limited number of avatars per person
          26. Multiple ways of limiting WIP were introduced later
          27. Fixed date items limited by time (?)
          28. Other work still limited by avatar number
          29. Course work with Max WIP, but also limited to 1 per person
          30. Collect Measurements
          31. Only after getting comfortable with WIP limits
          32. Every sticky gets stamped with the date
          33. Done stickies are removed at month's end
          34. Monthly metrics published to internal Slack channel, and used in retros
          35. Used data to make decisions and influence change
          36. Blockers used to change a policy
          37. Mix of work used to decide on priorities
          38. Data on capacity used for hiring
          39. Managing Capacity
          40. Once we had data, we could plan capacity better
          41. Capacity reserved for Unplanned Work
          42. One day a week allocated for post-class work
          43. Starting studying student retention & satisfaction
    4. Advertising
      1. Vistaprint - Europe & USA - David Grabel - 2016
        1. Context
          1. In-house Advertising Agency serving the Marketing department
          2. Product development improved to the point where the Agency became their bottleneck
          3. Internal coach brought in to help improved
        2. The Story
          1. Lots of blame going around
          2. Agency blamed for being late
          3. Email service blamed for consuming too much resources
          4. Team members frustrated
          5. Over 45+ days to produce a promotional email
          6. Email service flow efficiency = 3%
          7. Started by visualizing the workflow and the work
          8. Later
          9. WIP
          10. Classes of Service
          11. Tracking Lead TIme
          12. Process changes introduced later to reduce delay & manage flow
          13. buddy checks (pairing)
          14. Explicit policies
          15. Improving feedback loops
          16. Encouraging collaboration & experimentation
          17. Experiment to push decisions down to team members
          18. Experiment on mobbing
          19. Teams given explicit permission from executives to experiment (and fail)
        3. Effects
          1. Delivering value sooner
          2. 83% reduction in lead time
          3. Only 20% of work delivered late
          4. Transparency of data & goals
          5. Frequent collaboration
          6. Reflection
  3. LKU Classics
    1. Heavy Equipement Manufacturing
      1. Sandvik IT - Sweden - Christophe Achouiantz - 2010-13
        1. Context
          1. System Development Office (methods office). 3 internal coaches
          2. mining & construction equipment manufacturer
          3. large scale, company wide Kanban roll-out
        2. The Story
          1. The company wanted a "standard development process"
          2. Careful analysis showed that giving the teams the means to get in control of their workflow would yield the best impact
          3. Next step was to create awareness of the flow problems and how Kanban could be a solution
          4. Teams were too busy, so a "kick-start" model was created
          5. 1 day "kick-start" workshop
          6. Shared understanding of team's purpose
          7. Agree on policies to do the work
          8. Vsualization & daily meeting
          9. 2-hour "booster" sessions after that
          10. A "flow manager" role was introduced
          11. To help teams improve over time, "depth of Kanban" was used
        3. Effects
          1. Better priorization of work
          2. Less task switching
          3. More focus on quality
          4. Better team collaboration
          5. Better customer collaboration
          6. More customer involvement
          7. Shorter lead times
          8. Less stress
          9. Creation of an environment where changes can stick
    2. Neuroscience Games
      1. Posit Science - USA - Janice Linden-Reed - 2009
        1. Context
          1. neuroscience-based games to improve neuroplasticity in older adults
          2. three "tribes": neuroscientists, game developers, and business people
          3. Project Manager leading the process change
          4. Scumban story
        2. The Story
          1. From ad-hoc process to Scrum
          2. 2003-05: initial development of the idea, following and ad-hoc process
          3. 2005: successful product, but unmaintanable code-base
          4. Scrum introduced as a way to stabilize the development process
          5. Janice joins the company as PM and leads a successful Scrum implementation
          6. 2007: successful launch of the new version of the product
          7. Scrum no longer adequate
          8. Two products in the market: the focus changed from pure product developm,ent to sales, production support, and finances
          9. Stress increased substantially: the teams couldn't cope with the demand coming from multiple sources (Global Warming conditions)
          10. Lots of blocked work, due to preemption. Very frustrating Sprint Planning. Lots of WIP (most work started at the beginning of the sprint)
          11. A suggestion to abandon Scrum was rejected by the team; they believed that they needed to try harder and Scrum would work again.
          12. From Scrum to Proto-Kanban
          13. 3 simple changes
          14. extend the visual board to include upstream analysis
          15. personal WIP limits (3 items/person, visualized with avatars)
          16. drop estimation in hours, and replace it with t-shirt sizing
          17. They "discovered" that the same people are working both in upstream elaboration (unplanned) and downstream delivery (planned), causing lots of multi-tasking
          18. The developers were more focused and less anxious about whether or not they could meet their promises. The workflow was unpredictable and there was still too much work, including a portion that was unplanned.
          19. Kanban system
          20. New terminology introduced during retrospectives
          21. WIP
          22. Class of Service
          23. Cost of Delay
          24. There was the realization that Scum wasn't helping them any longer
          25. Constant unplanned work couldn't wait until the next sprint
          26. The Business was pushing work irrespective of how busy they were
          27. Priorities kept changing, causing lots of "fragmentation"
          28. changes
          29. WIP limits for the workflow, not just individuals
          30. Classes of Service to deal with the impact over time
          31. Classification of features using Market Risk taxonomy + 60/40 capacity allocation
          32. From Sprints to Flow
          33. changes
          34. sprints elimninated
          35. sprint planning replaced with on-demand replenishment
          36. Asynchronous commitments & Release cadence
          37. estimation replaced by SLA
          38. Analysis and story break down deferred until commitment
          39. Feature request form to ensure "Readiness"
          40. Policy for "too big" features
          41. Do it anyways
          42. Trim it down
          43. Throw it back
          44. Whole team working on 1 feature at a time
          45. remained the same
          46. PO and SM roles
          47. Demos & Retros
          48. Daily Standup
    3. Energy
      1. Visotech - Austria - Klaus Leopold
        1. Context
          1. Software for managing energy companies in the European market
          2. Producers
          3. Traders
          4. Operators
          5. Sellers
          6. Changes in regulation to fragment the value chain into multiple companies, lead to increased complexity in both functionality and integration needs
          7. Kanban initiative led by dev managers, with light support from Coach
        2. The Story
          1. Kanban introduced to increase transparency
          2. Lots of work to be done, unclear priorities
          3. Visualization through a Kanban board introduced to help with visibility
          4. An Integration Department is created to focus on client-driven integrations
          5. Predicting when work would be done got increasingly difficult
          6. Kanban gets deeper
          7. A new board for the Integration Dept was created during a 2-day workshop
          8. The team notices that they had different kinds of work, resulting in different horizontal lanes
          9. A new process step (Documentation) was made explicit
          10. Managing the larger picture
          11. End-to-end visualization of projects across various teams
          12. Rersource Planning board
          13. Kanban expands to Technical Support
    4. Car Manufacturing
      1. Volvo - Sweden - Karin R. & Anders Jonsson - 2012
        1. Context
          1. SWC: Volvo subsidiary in charge of developing and maintaining the claims system
          2. Warranty claims system for heavy-duty vehicles (trucks, buses), used by Volvo dealers
          3. Traditional waterfall SDLC, with quarterly releases
          4. 2008 economic downturn caused reductions in stuff and delay of enhancements
          5. Kanban introduced by Delivery Manager and internal Coach
        2. The Story
          1. The Problem
          2. Two high priority projects are started: North America consolidation, regional data segregation
          3. The size of the team trippled, and distributed between Europe and India
          4. Confusion, lack of transparency, stress increased
          5. The Change
          6. Transparency helps the team release for the first time
          7. The SDM decides to introduce Kanban
          8. They started by visualizing all the work, modeled after Volvo's standard process gates
          9. After their first release, they added a new board to track defects
          10. visualization is observed to help with self-organization and speed
          11. Kanban provides insights on the system of work
          12. Visualizing work makes evident that requirements were too big and vague
          13. There was too much multitasking
          14. Work was bundled in large batches, with slow flow, and no movement on the board
          15. Fundamental changes introduced
          16. Without drastic changes, the project will not deliver on time
          17. Original Kanban board, representing their waterfall process, discontinued
          18. Large requirements split into smaller chunks
          19. Personal WIP limits
          20. Finishing tasks, before starting a new one
    5. Fashion
      1. Net-a-Porter - UK - David Lowe - 2012
        1. Context
          1. High-end online fashion retailer
          2. Mutiple teams, organized by application component
          3. Team-level Kanban adoption introduced by internal coach and Team Lead
        2. The Story
          1. Scrum adopted to help bring structure to an ad-hoc process
          2. Initially, Scrum worked, but then it became a source of frustration
          3. Meeting sprint commitments was difficult due to unforseen events and dependencies
          4. Time spent in estimation was also a signifcant source of dissatisfaction
          5. Kanban is suggested as an alternative
          6. They started by mapping the workflow on a Kanban board, and work visualized with tickets
          7. WIP limits were introduced later
          8. Stand-up meeting focus changed from people to work items
          9. The process evolved
          10. Bottlenecks started to be identified
          11. WIP limits where adjusted and better understood
          12. Buffer steps were added in the flow, to smooth it out
          13. Retrospectives changed to 1/2 day, once a month
          14. Lead time metrics started being collected
          15. Kanban started spreading to other teams
    6. Car Sales
      1. Mobile.de/eBay - Germany - Holger Hammel - 2011
        1. Context
          1. Online platform for buying/selling cars
          2. Development Manager leading Kanban adoption
          3. Team Kanban from scratch
        2. The Story
          1. There was initially both Scrum and Kanban experience in the company
          2. Scrum initially adopted to improve delivery, but there was increasing dissatisfaction
          3. flow of ideas
          4. visibility of all ongoing projects
          5. predictable delivery
          6. Some teams introduced Kanban on top of Scrum, as a way to address those dissatisfactions
          7. When a new Mobile Development team was established, it was decided it would rely only on Kanban
          8. no iterations, no estimations, and no deadlines, just a constant flow of communication, learning, and delivery.
          9. Initial Kanban board had two columns: planned, ongoing
          10. With this simple process, they delivered a new version of the iOS app in a few months
          11. Eventually, the team learnt that they needed to visualize work in a way that was customer recognizable
          12. Epics were used to represent groups of stories meaningful to stakeholders
          13. A two-tier board was introduced
          14. Epics used to control flow: developers can work only on stories for 1 epic at a time
          15. Epics used as success and validation metric
          16. Then, they found that they needed a way to visualize the big picture
          17. Vision columns added to represent pre-planning phase (upstream flow)
          18. Then, Testing became the bottleneck (1 tester for 12 devs!)
          19. Developers took a more active role on testing
          20. Automation was introduced
          21. Cross-team testing was introduced
          22. With a smooth development process in place, they switched attention to introducing Lean Startup ideas to validate hypothesis for new products
    7. Construction
      1. Nemetschek SCIA - Czech Rep - Patrick Steyaert - 2010
        1. Context
          1. Development team for Scia Engineer, a calculation software used by construction engineers.
          2. Releases were slowing down, if finishing at all
          3. External consultant engaged in improvement
          4. Scrumban story
        2. The Story
          1. Scrum introduced in 2005
          2. It was seen as a solution to lack of clarity in roles and responsibilities, lack of focus, and slow release pace
          3. The developers used to be involved in product decisions, but now they were segregated from it
          4. By 2009, delivery delays have been fixed, but discontent caused many of the developers to quit
          5. Collaboration between development and product wasn't working
          6. Kanban introduced as a way to promote more collaboration
          7. The next big change was the reengineering of the Reporting application
          8. Scrum was kept at the team level, but the end-to-end process was modeled with 3 boards
          9. Discovery
          10. Expert System Requirements
          11. Delivery
          12. Operation review meetings were held with the teams
    8. Sports Equipment
      1. Blizzard Sports - Austria - Eric-Jan Kaak - 2011
        1. Context
          1. High-End ski manufacturing
          2. Increasing unpredictability of the weather created the risk of overproduction. The company adopted Lean Manufacturing principles to optimize production
          3. The CIO decided to implement a similar Lean approach to improve IT
        2. The Story
          1. The IT department had an ad-hoc process
          2. No system for prioritization or tracking requests
          3. Long delays and unpredictable delivery
          4. Multitasking
          5. Internal clients not notified when requests were done
          6. The team started by visualizing the work
          7. They focused on finishing, rather than starting
          8. Multitasking was reduced by adopting a WIP limit
          9. Internal clients started writing their requests on stickies, rather than send them by email
          10. Dependencies on an external software vendor were visualized, so that delays could be managed
          11. Another board was setup to track upcoming and outgoing work
          12. Kanban started spreading to other departments
    9. Government
      1. Land Surveying & Geospatial Agency - German Gov - 2010
        1. Context
          1. Technical Modernization Department of the government office that produces maps and georeferenced data
          2. Managers leading the change, with the help of external trainer
        2. The Story
          1. The department was seriously overburdened with work coming from the rest of the office. Delays were accumulating
          2. There were lots of dependencies between internal groups and external vendors
          3. A hybrid between Scrum and Kanban was introduced
          4. minimal changes
          5. New role: PO
          6. Small Stories and estimation
          7. Kanban board
          8. Daily standup meeting
          9. Daily meetings were quickly abandoned because people found difficult to talk about their work
          10. The board also eventually was abandoned
          11. Second attempt, with an external facilitator
          12. Reintroduction of daily meeting and Retrospectives
          13. Retrospectives allowed people to open up and start collaborating
          14. The board was redesigned, and people started making their work visible again
          15. Collaboration eventually became more fluid
  4. Early Adopters (2008)
    1. Yahoo! (USA)
    2. BBC, IPC Media (London, UK)
    3. NBC Universal (USA)
    4. Motley Fool (USA)
    5. Constant Contact, Ultimate (USA)
  5. The "Origin" Stories
    1. Microsoft XIT - Dragos Dimitrius & DJA - 2004
    2. Corbis - DJA - 2006
  6. Type of Story
    1. Scrumban story
    2. Project/Team Kanban
    3. Organizational/Department Adoption
    4. Portfolio Kanban