I recently worked at an insurance company (let’s call it Freesurance) that had mandated a “glide plane” process to bring a semblance of regularity to the chaotic development practices in place. All projects were to pass through specified stages of the glide plane at specified times. Glide planes were staggered to start every month.
Employees were mandated to enter all tickets (work requests, enhancements, and bug fixes) into a requirement-tracking tool. All tickets were to track through each of the following phases.
- New: All new work requests (tickets) should be entered into the requirement-tracking tool by the business analysts or by the development teams. Tickets must be entered at least 91 days before a scheduled monthly release.
- Acknowledged: A service level agreement (SLA) mandated that the business must acknowledge tickets within 7 days of receipt of the ticket – 84 days prior to release. This 7-day period was used to triage the tickets to remove duplicates, close tickets if no action was going to be undertaken, and to prioritize the items.
- Accepted: The IS department is tasked by the business to analyze and estimate the tickets — target 63 days prior to release.
- Business Requirements: The business analysts were required to complete the business requirements 42 days prior to release.
- Committed: IS would commit to the tickets, 28 days prior to release, that it thought it could complete — create functional specifications, construct, unit test, and build within the release dates.
- IN/OUT List: Final date to decide whether tickets are going to be included in this release or not.
- Constructed: IS completes coding, unit testing, and delivering final build 14 days prior to release.
- Resolved: Business analysts complete all testing 7 days prior to release.
- Closed: Code merged into the production environment (“going live”) on implementation day; Business signs-off on the release within 5 days of implementation.
The goal of any development system is to deliver customer-defined value, effectively, and with a minimum of waste. Systems that deliver value more efficiently are preferable to those that deliver value in a relatively expensive manner. One of the greatest contributors to inefficiency, poor quality, and high costs is waste (activities that do not add value to the end user).
While the “glide plane” concept sounds good in theory, it suffers from a few major drawbacks:
- The glide plane does little to eliminate wasteful activities that do not add value to the end user. At Freesurance, over the 96 day (2304 hour) glide plane cycle, value is added during only 10 business days (80 business hours) during construction. This evaluates to a best case scenario of approximately 3.5% of the available time being used for value add activities. In actuality, overall productivity is further degraded by excessive rework and multi-tasking. Ouch!
- The glide plane ultimately leads to excess work in progress — too many requirements are being investigated, sized, designed, and implemented at the same time. Time is wasted on investigating requirements that are not committed to being delivered and on backing out, at the last possible moment, implemented requirements which no longer hold true (scrap and rework).
- The overlapping nature of the glide plane deliverables ensures that team members are not working solely on the current iteration; their focus is diluted by having to wrap up the previous release and to begin actively planning for the next release.
- Multiple streams of work means that any single stream disruption can disrupt all streams. Critical bugs introduced in an implemented release have to be fixed, tested, and redeployed into production, therby, cutting the time available to work on the current iteration.
The “Glide Plane” concept is quite prevalent in software development organizations. The name of the process and the actual implementation (phases and schedules) may differ, but the underlying thought process and the resulting problems are the same in these organizations.
W. Edwards Deming had said that “the system causes 80 percent of the problems in a business, and the system is management’s responsibility.” This is very obvious in Freesurance’s case; teams can accomplish much by putting in heroic efforts release-after-release, but the pace is unsustainable. Teams burn-out and productivity plunges or key members leave for other jobs. Sadly, management is unaware of the underlying problems and does little to fix the offending policies. All too often, management ends up appealing for (and sometimes demanding) longer work hours and providing incentives to get teams to work harder; the underlying problems, that are management’s responsibility, remain unresolved.
The results at Freesurance were not surprising: teams were over-worked and burnt-out; developers were pushing “brittle” code into production to meet the mandated deadlines; support and maintenance was a nightmare and costs for emergency bug fixes were shooting up; customers were constantly complaining about the long lead times and the poor quality of monthly deliverables; IS management was not helping by constantly telling the teams that they “needed to get their act together” and that they needed to “work smarter”.
Sadly, divisional management was only concerned with meeting the dates mandated by the “glide plane”; not one of them was willing to look at the system as a whole — after all, sticking your neck out in an uncertain environment could result in your head being handed to you on a platter. Management (and teams) optimized locally (to try and meet the dates), and willfully disregarded the whole.
As a result, the teams suffered, and the company suffered. The “glide plane” obscured the importance of increasing throughput and reducing cycle time per unit value. Management should instead have focussed on smoothening the process flows, increasing focus, removing waste, and increasing customer value delivered every month. Sadly, an attitude of “we know best” prevented them from seeing what was very obvious to an outsider; it prevented learning; it prevented any improvement. An attitude of re-evaluating existing practices and beliefs would have made the shortcomings obvious. A systems perspective would have prevented local optimization. But none of these are possible without a degree of personal agility — the desire and willingness to accept responsibility for the situation and the desire to do something about it.