MGT 647 Module 3 Kanban and Flow Example

Forty-Six Items in Progress and a Five-Week Wait: Kanban and Flow for an Insurer's Claims Systems Team

Student Name

Master of Business Administration, Aspen University

MGT 647: Project Management Integration Framework

Instructor Name

Month Day, Year

Forty-Six Items in Progress and a Five-Week Wait: Kanban and Flow for an Insurer's Claims Systems Team

Lakeshore Mutual's claims systems support team keeps the company's claims platform running. Its eight members fix outages, make changes that state regulators require, adjust rules for adjusters and build small improvements requested by claims managers. Requesters complain that nothing gets done; the team complains that it is always busy. Both are right. This paper explains why Kanban, rather than Scrum, fits the team, analyzes its flow and designs a Kanban system.

Why Kanban Rather Than Scrum

Scrum, adopted by the claims app team in Module 2, commits a team to a sprint goal for two weeks. The support team cannot do that. A claims outage on a Monday morning cannot wait for the next sprint, and in a typical fortnight a third of the team's work was not known at the start. Kanban does not require fixed iterations. Work is pulled into the system as capacity frees up, and urgent items can be handled through explicit policies. It also asks for less upfront change, which matters for a team already stretched.

The Kanban Method

Anderson (2010) developed the Kanban method for knowledge work from experience with software maintenance teams. It begins from three principles: start with what you do now, agree to pursue incremental, evolutionary change, and respect current roles and responsibilities. Its core practices are to visualize the workflow, limit work in progress, manage flow, make process policies explicit, implement feedback loops and improve collaboratively using models. The method's distinctive feature is the work in progress limit: once a column is full, no new item can enter it until one leaves, which forces the team to finish before starting.

Why Queues Matter

Reinertsen (2009) argued that most product development organizations do not manage queues because they cannot see them. Unlike inventory in a factory, unfinished design and code sit invisibly in systems and inboxes. Yet queues create long cycle times, raise risk, delay feedback and lower quality and motivation. He urged organizations to measure the cost of delay, reduce batch sizes and use limits on work in progress to control queues directly. High utilization, often treated as efficiency, makes queues grow sharply as capacity is approached.

Measuring the Current Flow

Little (1961) gave a formal proof that, over the long run in a steady queue, the count of items present is the product of how fast items arrive and how long each one stays. Rearranged, average time equals work in progress divided by throughput. With 46 items in progress and 9.2 completed a week, an item takes about five weeks on average, which matches what requesters report. The relationship also shows the remedy: if throughput holds steady, halving work in progress halves the time each item takes.

Designing the Board

The board has columns for Ready, Analysis, Build, Test and Release, with limits of 4, 3, 6, 3 and 2, so no more than eighteen items are in progress. Four classes of service make policies explicit. Outages are expedited, with one swim lane allowed to exceed limits. Fixed date items, such as regulatory changes, are scheduled back from their deadline. Standard items flow in order. Small improvements and technical debt receive a fixed share of capacity, about 15%, so they are not starved.

Making Policies Explicit

Anderson's practice of explicit policies prevents the board from becoming a picture that everyone reads differently. Each column has a written exit rule. An item leaves Analysis only when the requester has agreed the acceptance criteria. It leaves Build only when code is reviewed by a second engineer. It leaves Test only when a claims user has tried it in the test environment. Blocked items get a red marker and are discussed first at the daily meeting. New work enters Ready only at the weekly replenishment meeting, where the claims operations manager and the team lead choose from waiting requests, so requesters know when and how their work is considered instead of lobbying individual engineers.

Cost of Delay

Reinertsen's emphasis on the cost of delay helps decide what to pull next. Not every request loses value at the same rate. A regulatory change has a deadline after which the company faces penalties, so its cost of delay is low until the date approaches and then very high. A broken rule that sends small claims to senior adjusters costs a measurable amount each week in adjuster time. A cosmetic improvement costs little to delay. Asking requesters to describe what a week's delay costs, even roughly, gives the replenishment meeting a better basis for ordering work than who complains loudest.

Feedback Loops

The team meets at the board for fifteen minutes each morning, walking from right to left, from Release back to Ready, so attention goes first to finishing. Replenishment happens weekly. Once a month, a service delivery review with claims managers looks at cycle time, throughput, blocked time and the mix of work by class of service, and adjusts limits if a column is constantly starved or overloaded.

Expected Results

At eighteen items and 9.2 completed a week, Little's law gives an average of about two weeks. The calculation assumes throughput holds steady; in practice, limits often raise throughput because less switching between tasks means more finishing. The team will test the assumption by tracking throughput and cycle time each week for three months. The first weeks will feel slower, because the team must finish or deliberately drop many of the 46 items before it can start new ones. Some requesters will be told that their item has been closed rather than left waiting indefinitely, which is uncomfortable but honest.

Conclusion

Anderson's method, Reinertsen's argument about queues and Little's law together show why the support team felt busy while requesters waited, and how limits on work in progress can cut waiting from five weeks to about two.

References

Anderson, D. J. (2010). Kanban: Successful evolutionary change for your technology business. Blue Hole Press.

Little, J. D. C. (1961). A proof for the queuing formula: L = λW. Operations Research, 9(3), 383-387. https://doi.org/10.1287/opre.9.3.383

Reinertsen, D. G. (2009). The principles of product development flow: Second generation lean product development. Celeritas Publishing.