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