IV. Aproximacion al objeto de estudio
4.2. Teorización de unidades temáticas
As described in chapter 4, in 2004, Dragos Dumitriu introduced a kanban system with his XIT Sustaining Engineering team at Microsoft. The upstream business partners were four product managers who represented several business units. They focused and prioritized change requests for the 80 or so IT systems supported by XIT.
Making On-Demand or Ad Hoc Prioritization 109
When Dragos and I designed the kanban system for introduction with XIT, we designed an input queue big enough to cope with at least one week of throughput.
Despite the fact that all four business representatives and Dragos were based in Redmond, Washington, on the Microsoft campus, the prioritization meeting would take place by phone. The Microsoft campus is huge. Buildings numbers go into the hundreds, although there are actually only about 40 buildings in total. The area covered is several square miles and transport between sections of the campus is by minibus or Toyota Prius. Many “softies” prefer conference calls for coordination meetings rather than face-to-face. This has a negative impact on the level of trust and social capital in their workforce, but it facilitates efficiency.
So Dragos established a weekly phone call to prioritize new change requests into their backlog. The four product managers represented business units that provided funding via inter-company budget transfer to fund Dragos’ team. Based on this funding, it was possible to determine roughly how many times someone should get to pick an item from the backlog. The product manager who provided six tenths of the funding would get to pick three from every five opportunities. Others would get to select items in a similar way based on their level of funding. The product manager who provided least funding would get to pick roughly once in every 11 times. We might describe this as a weighted round-robin method of selection.
So the rules of the XIT prioritization collaborative cooperative game were simple.
Each week the product managers would refill the open slots in the input queue—
typically three slots. Each of them would get to choose based on their position in the round-robin queue. The target lead time in the service-level agreement was 25 days.
So if they got a chance to choose a change request for development, they would ask themselves, “Which of the items in my backlog do I most want delivered 25 days from now?” The order in which they got to choose was very clear and simple based on their level of funding for the department.
Due to the simple nature of these rules, the meeting was finished very quickly.
It became clear that a coordinating phone call really wasn’t necessary. Dragos had the Microsoft Product Studio (a forerunner to Visual Studio Team System, Team Foundation Server) database provide an email from a trigger that indicated when a slot became free. He would then forward that email to the four product manag-ers. They would quickly agree whose turn it was to choose an item and that person would select something. Typically, an empty slot in the queue was replenished within two hours.
The exceptionally low coordination costs, coupled with the low transaction costs related to the decision not to estimate change requests, along with the relatively high maturity of the team involved, allowed Microsoft XIT to dispense with regularly scheduled prioritization meetings.
110 Chapter 9 ❖ Establishing an Input Cadence
It is worth noting that Microsoft in Redmond is roughly the equivalent of a CMMI-ML3 organization and that the vendor being used for XIT development and testing was a CMMI-ML5 team based in Hyderabad, India. So this team had the advantage of low coordination costs, low transaction costs, and particularly high levels of organizational maturity. The net effect of all three meant that on-demand prioritization meetings made the team more effective.
As a general rule, you should choose ad hoc or on-demand prioritization when you have a relatively high level of organizational maturity, low transaction costs, and low coordination costs of prioritization. Otherwise, it is better to use a regularly scheduled prioritization meeting and coordinate selection of input queue items with a regular cadence.
Making On-Demand or Ad Hoc Prioritization 111
Takeaways
❖ “Prioritization cadence” means an agreed-upon regular interval between meetings to prioritize new work into the input queue for development.
❖ Kanban removes potential dysfunction around the coordination of iteration planning in Agile methods by decoupling the prioritization cadence from the development lead time and delivery.
❖ Prioritization of new work requests such as user stories involves coordi-nation of many people from various functions. All of this coordicoordi-nation has a measurable cost.
❖ Estimation to facilitate prioritization decisions represents the transac-tion costs in both time and money associated with prioritizatransac-tion. These costs can be determined and tracked.
❖ Policies concerning the method of prioritization and the inputs for deci-sion making represent the rules of the collaborative cooperative game of prioritizing in Kanban applied to software development.
❖ Planning games used in Agile methods do not scale easily and can repre-sent a significant coordination cost for larger teams with broader focus than a single product line.
❖ Prioritization cadence can be established by encouraging those involved in prioritization decision making to meet as regularly as is reasonable based on the transaction and coordination costs involved.
❖ Efficiency and cadence of prioritization can be increased by focusing on reducing its transaction and coordination costs.
❖ Frequent prioritization meetings build trust.
❖ Scheduling regular prioritization meetings reduces coordination costs and is particularly useful in lower-maturity organizations.
❖ Ad hoc or on-demand prioritization can make sense for high-maturity organizations with established high levels of trust and with low transac-tion and coordinatransac-tion costs associated with the policies for prioritiza-tion decision making.
113
A
s discussed in chapter 2, one of the five core properties in the Kanban Method is that work-in-progress is limited. So it’s true to say that one of the most important decisions you’ll make when introducing Kanban is choosing limits for work-in-progress throughout the workflow.Chapter 15 advises that the work-in-progress limits should be agreed upon by consensus with up- and downstream stakeholders and senior management. It is true that limits could be unilater-ally declared; however, there is power in gaining a consensus and obtaining a commitment from external stakeholders regarding the WIP-limit policy. When your team and process is put under stress you can fall back on the collaborative agreement around which there is consensus. You can redirect the discussion to a redefini-tion of the process rather than agree to bend, stretch, or otherwise misuse the system as designed and implemented. Building consen-sus is a way to maintain WIP-limit discipline and avoid having to override or abandon a limit.