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