Thursday, December 15, 2005

Changing the Offer

Understanding customer tolerance can be one of the most important weapons in the improvement arsenal. It isn’t enough to understand what the customer values but to have the intimacy with the customer to understand their tolerance on delivery and variation from specification. This knowledge can enable a change in the offer to the customer to an offer that is tolerance aware. A tolerance aware offer can enable subordination decisions (changes in policy) that enable further exploitation of a constraint and increases throughput.

We used this technique in the XIT SE case study. We changed the offer. The old offer was based on providing a delivery date for each change request. This was calculated from an effort estimate and building a schedule of start and end dates for change requests scheduled against resources. This is traditional paradigm project management. But it was costing a lot - up to 40% of available capacity to provide this service.

However, the reality was that the customer tolerance to delivery did not require a precise date. So we changed the offer to the customer and provided a service level agreement which stated that from the day a change request was committed (inserted into the buffer in front of the development CCR) it would be delivered back within 25 working days. This SLA was calculated by studying historical data for time on task (touch time) and its variation. By recognizing that almost all change requests could be delivered within 25 days providing expediting wasn’t delaying them, and that 25 days was within customer tolerance, it was possible to construct and sell a new offer to the customer. As soon as we had customer buy-in to the new offer, we could change the policies regarding estimation and scheduling. The subordination decision was to eliminate estimation and traditional scheduling. This freed up capacity which was immediately exploited as increased throughput.

Wednesday, December 14, 2005

Drumming in the Dark

I get asked often, “Where do you start?” Where do you start, if you want to make improvements and follow the ideas in the Theory of Constraints, when you don’t know where the constraint is, or how to identify it?

The answer is pretty simple. If you have no worthwhile measurements and no real insight to your software development group’s productivity and performance, you simply drum at the rate of the output. As a batch of customer valued deliverables appear at the output, you allow a similar sized batch in at the input. This works regardless of your unit of value measure. It could be change requests (like the XIT SE example), or scenarios, or use cases, or features, or user stories, or function points or whatever you choose as a unit of value measurement.

What happens next? The constraint reveals itself! Parts of the system that truly have slack capacity will reveal themselves too, while the constraint will remain fully loaded. Because the input to the system is regulated at the rate of production of the system as a whole, and that rate is regulated by the rate of the constraint (even when it is hidden or unknown) then the system stabilizes. This stabilization provides the base platform on which policies can be changed (subordination decisions) in order to fully exploit the constraint. Subordination decisions may utilize slack capacity elsewhere in the system to help fully exploit the capacity of the constraint. The XIT SE example showed this with injection #3 that moved slack testing capacity into development (the CCR). Making these changes (subordination decisions) is what causes improvement to begin and sets the organization on a journey of continuous improvement.

Once the constraint is revealed, the drumming can be triggered off the constraint itself rather than the output of the system.

Friday, December 09, 2005

Operations Review

This is the last in my series of posts about things we did right at Sprintpcs.com. The monthly operations review was a clear indication that we deeply understood the separation of capacity in our “software factory” from the governance problem of allocating resources. I dedicated chapter 14 of my book to the subject but I left the real story to a footnote at the end of the chapter. Chapter 14 has been available as a free download since the book was published. Here is the story that I left to a footnote…

The monthly operations review became an integral part of life at Sprintpcs.com, ... The event was regularly attended by at least one executive vice president and often several. It was generally held on the 3rd Friday of each month at 2pm in an offsite meeting room. We typically chose to use the Johnson County Community College facilities in Overland Park, Kansas. The time was picked so that people could relax afterwards, go home and wind down for the weekend. Around 70 people attended the meeting. This included all line managers and higher from within the business unit and all succession candidates who were slated for promotion to line manager, plus all individual contributors holding the rank of manager. In addition the business units value chain partners were invited including directors of marketing who supplied our requirements and directors of support and customer care. The meeting always led off with the financial numbers presented by the respective business owners. Revenue was always first. Sprintpcs.com is both an e-commerce store and a support site. The revenue was driven from sales plus a “cost saving” from on-line support and self-service which was deemed to “save” money from the traditional call center support. After the revenue numbers came the costs - the budget spend, the headcount. Each set of figures presented as planned versus actual for each month and total for year to date. After the financial numbers, it was time to look at the productivity and quality data. We looked at throughput of projects and features. Then each GPM would present the project portfolio. We had 4 GPMs. The PMO would present the enterprise wide rollup. All new business coming to the unit was submitted to the PMO which acted as a choke point stemming off demand at a rate it could be consumed by the factory. What is most amazing, is how fast paced the meeting was. It was conducted and finished within 2 hours even though more than 10 departments would present several slides each and there would be conversation over the detail. The Director of Operations took minutes and identified issues. Each issue, or improvement suggestion, was allocated an owner. The issues from the previous meeting were always reviewed and updated and tracked to closure over a number of months. Operations review provided all of in the BU with transparency into what was going on. It made us all accountable. And it raised the level of discussion to one of objectivity. The metrics we reported each month gave us a way to measure productivity and improvement and it helped us to negotiate with customers and schedule projects when we had capacity. In a few short months, the introduction of monthly operations reviews with a large team of stakeholders changed the culture from anecdotal complaint, distrust, stress and frustration to one of openness, objectivity, transparency and trust.

Looking back now, this was very impressive. I’ve never seen it done so well and at such a large scale - 350 people is not a small business unit - before or since. The portfolio of projects was large. My own group typically had 5 projects in progress. There were 4 other groups plus shared resources such as test, user experience, and production management and maintenance group. I’d love to see this practice of operations review and the acknowledgement that we need to manage the operational capability of software factories separately from governance, become a common practice. No cloistered meetings of a select few executives passing round slides that have massaged data hiding the real truth. The way forward is an ops review broadcast on LiveMeeting running live reports from Visual Studio Team System for everyone in the BU to see and comment upon. No double bookkeeping. No Lies. No half truths. Just the facts about how we deliver software projects.

I’m calling this concept “Trustworthy Transparency” and it is a theme you’ll be hearing a lot more from me over this next year. It might be a new sound bite but it’s based on lessons I learned at Sprintpcs.com five years ago!

Thursday, December 08, 2005

December CTP

Jeff Beehler has announced the availability of the December Customer Technology Preview of Visual Studio 2005 Team System. This is the first version of VSTS which has a truly usable MSF for CMMI Process Improvement process template and guidance. This version is very close to what will be release early next year.

Randy Miller has also been busy making the Beta 3 Refresh process templates and guidance available from our respective MSDN workbench sites. Get the Beta 3 Refresh MSF for Agile Software Development build here and the CMMI version here.