II. Problema de investigacion
2.1. Aproximacion tematica
2.1.2. Estudios relacionados
percent of available capacity. It was a great tradeoff. By dropping estimates, the team gained more than 33 percent of capacity at the risk of less than 1 percent of that capacity. This new policy empowered developers to manage risk and to speak up when necessary!
The first two changes were left to settle in for six months. A few minor changes were made during this period. As mentioned, a backlog purge policy was added; the weekly meeting with product owners also disappeared. The process was running so smoothly that Dragos had the Product Studio tool modified so it would send him an email when a slot became available in the input queue. He would then alert the product owners via email, who would decide among themselves who should pick next. A choice would be made and a request from the backlog was replenished into the queue within two hours of a slot becoming available.
Looking for Further Improvements
Dragos began looking for further improvement. He’d been studying historical data for tester productivity from his team and comparing it with other teams within XIT supplied by the same vendor. He suspected that the testers were not heavily loaded and had a lot of slack capacity. By implication the developers were a significant bottleneck. He decided to visit the team in India. On his return he instructed the vendor to make a headcount-allocation change. He reduced the test team from three to two and added another developer (Figure 4.6). This resulted in a near-linear increase in productivity, with the throughput for that quarter rising from 45 to 56.
Figure 4.6 Resource_leveling
44 Chapter 4 ❖ From Worst to Best in Five Quarters
Microsoft’s fiscal year was ending. Senior managers were noticing the significant improvement in productivity and the consistency of delivery from the XIT Sustained Engineering (software maintenance) team. Finally, management trusted in Dragos and the techniques he was employing. The department was allocated enough money for two more people: One developer and one additional tester were added in July 2005. The results were significant (Figure 4.7).
Results
The additional capacity was enough to increase throughput beyond demand. The result? The backlog was eliminated entirely on November 22, 2005. By this time the team had reduced the lead time to an average of 14 days against an 11-day engineering time. The due-date performance on the 25-day delivery time target was 98 percent. The throughput of requests had risen more than threefold, while lead times had dropped by more than 90 percent, and reliability improved almost as much. No changes were made to the software development or testing process. The people working in Hyderabad were unaware of any significant change. The PSP/
TSP method was unchanged and all the corporate governance, process, and vendor-contract requirements were fully met. The team won the Engineering Excellence Award for the second half of 2005. Dragos was rewarded with additional respon-sibilities, and the day-to-day management of the team was handed off to the local line manager in India, who relocated to Washington.
These improvements came about in part because of the incredible managerial skill of Dragos Dumitriu, but the basic elements of mapping a value stream, analyzing
Figure 4.7 Adding_additional_resources
Results 45
flow, setting WIP limits, and implementing a pull system were key enablers. Without the flow paradigm and the kanban approach of limiting WIP, the performance gains would not have been possible. Kanban enabled incremental changes with low politi-cal risk and low resistance to change.
Figure 4.8 Quarterly_throughput_overlaid_with_unit_cost
Figure 4.9 XIT_Sustaining_time_to_resolve,_shown_in_Microsoft_fiscal_years
46 Chapter 4 ❖ From Worst to Best in Five Quarters
The XIT case shows how a WIP-limited pull system was implemented on a dis-tributed project using offshore resources, and facilitated with an electronic tracking tool. There was no visual board and many of the more sophisticated features of the Kanban Method described in this book had yet to emerge. Nevertheless, what manager could ignore the possibility that a greater than 200 percent productivity improvement, with a 90 percent lead-time reduction, could be achieved with sig-nificantly improved predictability and with minimal political risk and resistance to change?
Results 47
Takeaways
❖ The first kanban system was implemented with the XIT Sustained Engineering software maintenance team at Microsoft, starting in 2004.
❖ The first kanban system used an electronic tracking tool.
❖ The first kanban system was implemented with an offshore team at a CMMI Model Level 5 appraised vendor in Hyderabad, India.
❖ The workflow should be sketched and visualized.
❖ The process should be described as an explicit set of policies.
❖ Kanban enables incremental changes.
❖ Kanban enables change with reduced political risk.
❖ Kanban enables change with minimal resistance.
❖ Kanban will reveal opportunities for improvement that do not involve complex changes to engineering methods.
❖ The first kanban system produced a greater than 200-percent produc-tivity boost, a 90-percent lead time reduction, and a similar improve-ment in predictability.
❖ Significant improvements are possible by managing bottlenecks, elimi-nating waste, and reducing the variability that affects customer expec-tations and satisfaction.
❖ Changes can take time to take full effect. This first case study took 15 months to enact.
49
I
n Japanese, the word kaizen literally means “continuous improve-ment.” A workplace culture where the entire workforce is focused on continually improving quality, productivity, and cus-tomer satisfaction is known as a “kaizen culture.” Very few busi-nesses have actually achieved such a culture. Companies like Toyota, where employee participation in their improvement pro-gram is close to 100 percent, and where, on average, each employee gets one suggestion implemented every year as part of on-going improvement, are very rare.In the software development world, the Software Engineering Institute (SEI) of Carnegie Mellon University has defined the high-est level of their Capability Maturity Model Integration (CMMI) as Optimizing. Optimizing implies that the quality and performance of the organization is continuously being refined. While not ex-plicitly stated, as the CMMI says little about culture, achieving optimizing behavior as an organization is more likely to happen within a kaizen culture.