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:

1. 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!
2. 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).
3. 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.
4. 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.

Pages: 1 2