PM 400 Week 4 Kanban and Flow Measures Example

Thirty-One Requests in Progress and None Finishing: Kanban and Flow Measures for a Library's Systems Team

[Student Name]

University of Phoenix

PM/400: Agile Management and Tailoring

Week 4 Assignment

[Instructor Name]

[Date]

Desert Sky Library District, its systems team, requests and measures are composites written for a model paper.

Desert Sky Library District, the imagined southern Arizona library system in this course, finished migrating its catalog and circulation system to a new cloud platform last month. Since then its two system librarians, Priya Raman and Dale Ortiz, have been overwhelmed. Requests arrive from 14 branches by email, phone and hallway conversation: a patron record that merged wrongly, a notice template in the wrong language, a branch whose holds shelf report is blank, a new item type for the makerspace's equipment. At the start of this analysis there were 31 requests open, and branch managers said simple fixes took weeks. This paper applies Kanban to the team's work and uses flow measures to judge the result.

Why Kanban, Not Sprints

The app team in Week 3 uses Scrum because its work can be planned in two-week goals. The systems team's work is different: dozens of small, unrelated requests arrive unpredictably, some urgent, most taking less than a day of effort. Committing to a sprint backlog would mean either ignoring urgent problems for two weeks or breaking the sprint constantly. Kanban, which manages a continuous flow of work, fits better. Anderson (2010) described the method as starting from the current process, visualizing it, limiting work in progress and improving step by step, rather than imposing a new framework all at once.

Mapping the Workflow

The team mapped the steps a request actually passes through and turned them into columns on a shared electronic board: new requests; triaged, with priority and type set; waiting for information from the branch; in progress; testing with the branch; and done. Every request became a card with its branch, type and date received. The first board showed what nobody had seen: 9 cards in progress at once for two people, 11 waiting for branch information, 6 in testing and 5 untouched in triage.

Limits and Policies

The team set work-in-progress limits: no more than four cards in progress, two per librarian, and no more than five in testing. When a column is full, no new card may enter it; instead, the librarians help clear the full column, for example by calling a branch to finish testing. Written policies made the rules visible. Urgent requests, defined as anything stopping checkouts or exposing patron data, may bypass the in-progress limit, with at most one urgent card at a time. Requests waiting for branch information more than five working days are closed with a note and can be reopened. All requests must come through the board's request form, so hallway requests no longer vanish.

A full column is not a reason to start something new; it is a signal to help finish what is already there.

Baseline Flow Measures

Over the four weeks before the board, the team finished an average of about 9 requests a week, while about 31 were in the system at any time. Little (1961) gave the formal proof of a queuing rule now used far beyond factories: when a system is steady, the count of things sitting in it is the product of how fast they leave and how long each one stays. Applied here, average time in the system is about 31 divided by 9, or about 3.4 weeks per request, which matched the branch managers' complaints. Cycle time, from the start of work to done, averaged only about 2.5 working days: most of a request's life was spent waiting, not being worked on.

Six Weeks With Limits

Ahmad et al. (2013) reviewed studies of Kanban in software development and reported benefits including better visibility of work, improved understanding of processes and better coordination, along with challenges such as lack of training and organizational culture. Desert Sky's experience matched both. After six weeks with limits:

Throughput rose from about 9 to about 11 requests a week, mostly because fewer requests were left half-finished.

Average work in the system fell from about 31 to about 16 items.

Average time in the system fell to about 16 divided by 11, or about 1.5 weeks, and branch-reported waits confirmed the drop.

Cycle time stayed near 2.5 days, showing that the gain came from less waiting, not faster work.

The main challenge was culture: two branch managers kept emailing requests directly. The deputy director reminded all managers that the board form is the only route.

Reading the Cumulative Flow Diagram

The team's cumulative flow diagram, which plots the number of cards in each column over time, showed the waiting-for-information band widening in weeks two and three. That pointed to a bottleneck outside the team: branches slow to answer questions. The team added a required field to the request form for the patron or item barcode and a screenshot, which cut the waiting band nearly in half by week five.

What the Branches Noticed

The change was visible outside the team. Before the board, branch managers had no way to see whether a request had been received, so many sent the same request two or three times, which inflated the queue. With a shared board they could look up their own cards, see which column each sat in and answer questions faster when a card moved into the waiting column. Duplicate requests, counted from the triage column, fell from about one in six to fewer than one in twenty. The Mesa Verde branch manager, who had been the loudest critic, asked whether her branch's own maintenance requests to facilities could be run the same way.

Next Improvements

Three improvements are planned: a service level expectation that 85 percent of non-urgent requests finish within ten working days, measured monthly; a weekly 20-minute replenishment meeting with the deputy director to order the triage column; and a monthly review of request types, since recurring problems such as notice template errors may need a permanent fix rather than repeated cards.

Conclusion

The systems team's problem was not slow work but too much work started at once, hidden queues and requests waiting on branches. Visualizing the real workflow, limiting work in progress, writing explicit policies and measuring flow cut the average wait from about 3.4 weeks to about 1.5 weeks. Flow measures showed why: the work itself did not get faster, but it stopped waiting.

References

Ahmad, M. O., Markkula, J., & Oivo, M. (2013). Kanban in software development: A systematic literature review. In 2013 39th Euromicro Conference on Software Engineering and Advanced Applications (pp. 9-16). IEEE. https://doi.org/10.1109/SEAA.2013.28

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