A New Copy!

Chapter 13, Pull Policies, of Daniel S. Vacanti’s Actionable Agile Metrics for Predictability: An Introduction (buy a copy today) begins Part 4: “Putting It All Together for Predictability” . Pull policies define how work is accepted by a team and gets worked on. Pull policies are important because they affect cycle time and predictability.

Chapter 13 Pull  policies

Almost everyone that has been introduced to the concepts of flow,  kanban, or scrumban has been introduced to the idea of class-of-service (CoS).  Arguably, if you have ever stood in a line only to see someone go around the line understands different classes of service. A family member works in the airport, they always go to the head of the queue; airport employees are a class of service.  Vacanti uses the airport example in great detail at the beginning of the chapter to illustrate the impact of classes of service. I suggest reading the example at least twice before you finally put the book away (it is that good).  

Class of service is “a policy or set of policies around the order in which work items are pulled from a given process once those items are committed to.”  

The TSA and airport have established a policy to expedite airport employees being screened and entering the sterile area of the airport (TSA’s words – not mine) that puts them ahead of the people already in the line.

Several clarifications are presented before the chapter dives into showing the impact of using class-of-service on predictability.  The first is that work type and class of service are not the same thing.  In a typical team, there might be many kinds of work being performed, development, enhancements, and maintenance. Each might have a different flow of work, these are different work types. However, if they all are governed by a policy for how work is pulled, they do not represent different classes of service.  The second reminder or clarification is that class of service does not attach until an item has been pulled into the process. Just because my family member is an airport employee, unless I am in the queue to go through security it does not attach an expedited CoS for other activities. Also, if no one is in the line to go through security there is no need expedite the process.  The same would be true if an emergency issue was committed to  by the team and the required fix date was within the team’s SLA for cycle time., there would be no reason to put the work in an expedited CoS. CoS affects how work is committed to by the team (pulled off the backlog to replenish the committed and ready column discussed earlier).  

The second part of the chapter walks the reader through four scenarios that show the impact of adding a simple expedited CoS to a flow of work.  Vacanti uses a simple flow in all four scenarios.  The flow has steps for specification, development, and testing.  For the sake of simplicity, each step averages 20 days for each work item.  The work in process (WIP) limit is 2 items for specification, 2 for development and 1 for testing.

In the first scenario, work enters in a strict first-in, first out (FIFO) approach.  This means that the decision about which items are pulled next is based solely on which items entered the board first. Running a statistical simulation of this scenario shows that 85% of the items complete in at most 50 days.  

In the next scenario, Vacanti replaces the FIFO with a random draw of work items.  In this cases since there are no assumptions of preparation or readiness the cycle time increases at the 85% line to 60 days. (FIFO sure seems better than random).

The third scenario show is going back to a FIFO entry but adds an expedited CoS.  It is assumed that there will always be one and only one item being expedited.  The simulation shows an overall increase of cycle time to 65 days at the 85% line on the scatterplot.

Running the simulation with random entry and the expedited CoS yields a cycle time of 100 days at the 85% line.  

The basic takeaways from the four simulations are that expediting work will tend to have a negative impact on cycle time and that even what appear to be minor changes in policy can have a big impact on a team’s ability to be predictable.

As a side note, Vacanti discusses the idea of first in first serve (just like restaurant queuing). Instead of first in, first out the whoever is ready first goes first.  To illustrate, say a party of 10 go into a restaurant and get seated just ahead of me. If I decide on what I want first I generally will get my order taken and served first.  This is often more akin to what occurs in a typical software team.  

Near the end of the chapter Vacanti introduces the concept of slack. As has been noted more than a few times on the Software Process and Measurement Cast blog, a process running at full capacity can’t absorb any shocks, or in the case of chapter 13, any expedited items. Vacanti uses FedEx as an example of the planned use of slack in a process to ensure the ability to meet their commitments and SLA. The statement that lean is not just about reducing waste but also the effective, efficient and predictable delivery of customer value is important when we consider the need for classes of service.

Simply put, if we can’t predict expedited items and have to accept them and commit to their delivery, slack is required or flow will be negatively impacted.

The final conversation in the chapter is about the use of business value as a pull strategy.  Vacanti argues that since business value is a guess or estimate until the work is implemented that should be considered only during queue replenishment and not as a factor controlling the flow of work through the process

Bottom line: If possible try to avoid implementing CoS. CoS messes up predictability and slows work down.

 

Previous Installments

Introduction and Game Plan

Week 2: Flow, Flow Metrics, and Predictability

Week 3: The Basics of Flow Metrics

Week 4: An Introduction to Little’s Law

Week 5: Introduction to CFDs

Week 6: Workflow Metrics and CFDs

Week 7: Flow Metrics and CFSs

Week 8: Conservation of Flow, Part I

Week 9: Conservation of Flow, Part II

Week 10: Flow Debt

Week 11: Introduction to Cycle Time Scatterplots

Week 12: Cycle Time Histograms

Week13: Interpreting Cycle Time Scatterplots

Week 14: Service Level Agreements

 

Support the author (and the blog), buy a copy of Actionable Agile Metrics for Predictability: An Introduction by Daniel S. Vacanti

Book

Kindle

Get your copy and begin reading (or re-reading)!