![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
In my July 2005 article, "Twelve tips for realistic scheduling in a software development project," I illustrated some techniques that can help you keep your sanity, which go beyond the usual tactics involving notes, checklists, milestone dates, and appointment books. My twelve tips stress prioritization, clarifying values, and comparing the relative worth of each activity. They combine the conventional checklists with preserving and enhancing relationships to accomplish the desired results.
In this article, I will discuss realistic scheduling at the next level, where we seek to manage shared resources over extended and multiple product timelines. These techniques show how to use the twelve tips within a real-world product development lifecycle. Although illustrated across a software development lifecycle, these techniques can be used by anyone who is responsible for multitasking and managing resources across various activities during the same timeline.
RUP and the product development cycle
The Rational Unified Process®, or RUP®, is a software engineering process that uses an iterative development approach. As shown in Figure 1, the RUP product development cycle includes four phases called Inception, Elaboration, Construction, and Transition.
Figure 1: Rational Unified Process is divided into four phases, each subdivided into iterations
In the Inception phase, the product idea or request for proposal is developed to the point that the funding decision can be made. In the Elaboration phase, the product vision and its architecture are defined. The Construction phase is where the software is brought from an executable architectural baseline to the point at which it is ready to be Transitioned to the user community, and in the Transition phase, the software is fully system tested and turned over to the user community.
Each phase is divided into iterations. The iterative approach integrates the requirement, design, coding, and testing elements progressively. It is a process of continuous integrations with the associated appropriate deliverables, milestones, and exit criteria1. These same four phases are replicated in every type of delivery mechanism, whether it is a major release or a smaller maintenance service release. The only significant difference is the length of each phase.
This paper isn't intended to explain or provide details on the Rational Unified Process. There are many articles and books on iterative development and RUP,2 but what the vast majority of these resources do not discuss is the timing of various releases and their impact on the development organization and teams. This article attempts to address this through extension and adaptation of the RUP framework to create more realistic schedules.
Consider this example. Prior to the general release of a "product under development Version 2.0," teams are starting the maintenance and service releases for that same product. This is because the code is frozen3 long before the product is actually released. This is to allow enough time for final system-level testing, final manufacturing activities, and deployment operations.
But even though the code is frozen on that version of the product branch, defects continue to be reported and fixed. The maintenance cycle on Version 2.0, which will result in release 2.1, consists of the same four RUP phases, although the cycles are shorter, as shown in Figure 2.
Figure 2: Example of a Version 2.0 product under current development involves a maintenance cycle before the product is even released.
To further complicate matters, imagine that this same product line had a previous release, Version 1.0, which is also continuously delivering maintenance releases (Versions 1.1, 1.2, 1.3, etc.). These service cycles are ongoing and in parallel with the current development of Version 2.0, as depicted in Figure 3.
Figure 3: The service cycles for Version 1.0 are ongoing and in parallel with the current development of Version 2.0.
Add to this complex scenario the planning cycle of the next major product version (Version 3.0). The Inception and Elaboration phases of the next major release also occur before we are done with Version 2.0, as shown in Figure 4.
Figure 4: The Inception and Elaboration phases of the next major release, Version 3.0, also occur prior to the general distribution of Version 2.0.
As you can see, a year in the life of a product includes not only the current product under development, but the previous product release's maintenance cycle, as well as the next release's design and prototyping. There are many activities going on in the same calendar timeline.
Typically, our program schedules focus on one product version at a time, but that can cause a huge problem: While the program schedules are single-tier, software development organizations often are not. These days, the software development teams (including development, test, technical writers, technical support, etc.) are lean organizations. The development, test, documentation, and other teams are shared across all of the product's versions. This is because we need similar skills and knowledge to support that product on each "code branch" -- that is, that development activity related to each product version. Because the level of effort required on the different versions varies according to the phase and activities, a particular resource isn't necessarily utilized 100 percent on each branch 100 percent of the time. This leads us to believe that we can share resources across all the various branches of the same product line, without additional headcount.
For instance, a coder with user interface coding experience is only needed on the support branch of Version 1.0 when there are defects associated with the user interface. Therefore, during the Inception, Elaboration, and Transition phases of Version 1.0, that coder will not be fully utilized. So, instead of duplicating resources with that same talent on each branch, that same coder can work on similar tasks that require that same skill on Version 2.
This is a reasonable strategy, as long as the various and parallel activities are considered when creating the shared program schedules.
Let's see what happens to program schedules when they are created in a single threaded or single-tier vacuum.
In a typical production year, there are various peaks in the level of effort for certain roles. This is shown in Figure 5 (same graphic as Figure 1), where for each discipline listed at the left, the effort rises or falls as development phases progress. For example, a coder's effort on each version branch may peak in the Construction phase. A business analyst's work peaks in the Inception phase and the beginning of the Elaboration phase. A tester's work peaks may be at the end of the Construction and in the Transition phases. Since the different phases occur at different times, it's feasible that the same coder, business analyst, or tester won't be 100 percent utilized at each phase of the current branch. Therefore, this resource can be redirected and shared across other Construction, Inception, or Transition phases, respectively, on a different version or product branch.
Figure 5: Different activities and roles peak at different times in a product delivery cycle. Therefore, it's feasible that a specific actor or role isn't 100 percent utilized 100 percent of the time.
In single-tier scheduling, other branches of effort are not considered. This form of scheduling considers only the effort required for a given branch (or tier), and an individual's level of effort is assumed at 100 percent across that branch. The iteration sizes are also typically scheduled at equal lengths. For instance, a program schedule might have three consecutive Construction iterations, each six weeks long. Once a team is given such a schedule, they go off to plan their feature delivery.
Consider what happens next. Proper iterative program management dictates that the practitioners doing the work should be the ones deciding how much they can accomplish in a given amount of time. In this example, the coders are asked how many features they can reasonably complete in those six-week intervals. They may even be able to accurately define their level of work for those six-week iterations. But in a single-tier scheduling environment, they scale their work independent of where a given six-week interval falls in the product's yearly lifecycle. Figure 6 shows three independent tiers of work effort, and their associated peaks and valleys of predictable effort.
Figure 6: Solid lines depict the natural peaks and valleys in effort for one role -- in this case, the coding team -- in the product's lifecycle.
What happens next is everyday life. They may have correctly estimated the number of Version 2.0 features for the allotted six weeks of time; but their six weeks fell during the weeks when they are needed to complete separately scheduled maintenance tasks on the Version 1.0 stream. Therefore, they were pulled from task to task to take care of other things during that six-week period. Even though they have correctly estimated their work load for six weeks, they were not given a full six weeks to complete those tasks. Consequently, some of the Version 2.0 features are "incomplete." The incomplete features fall into the next iteration, a trend that continues until the final iteration is heavily loaded. It's often the last iteration that presents teams with the most conflicts and time constraints, given that it's overlapping with both the previous release maintenance cycle, this current release's maintenance cycle, AND the next release design cycle. These conflicts are shown in Figure 7, highlighted in yellow.
| XML error: The image is not displayed because the width is greater than the maximum of 580 pixels. Please decrease the image width. |
Figure 7: In this example, a yellow stripe highlights the resource conflicts for the coding team in a single-tier scheduling solution.
Popular solutions to the resource conflicts include adding resources, reducing quality, or simply "adding time to the current schedule."4 What typically happens is that resources are redirected from other projects (creating delays and conflicts that jeopardize the schedules for those projects) and this project's construction period is extended so that it overlaps even more with both the maintenance cycles of the previous product stream (Version 1.0) and this product (Version 2.0), as well as the Construction phase of the next product line (Version 3.0). This creates more conflicts and task-switching, as illustrated in Figure 8 by the dotted line and the wider yellow stripe indicating a longer period of resource conflict.
| XML error: The image is not displayed because the width is greater than the maximum of 580 pixels. Please decrease the image width. |
Figure 8: Adding time to a single-tier schedule extends the conflict periods as illustrated by the dotted lines and enlarged yellow highlights.
Let's see how a multi-tier scheduling solution can help.
Multi-tier scheduling analysis
Often, to accommodate parallel projects across shared resources, managers elect to split resources into percentages. They may allocate 20 or 30 percent of a person to the maintenance branch and the rest on the current development branch. While this method accommodates for the resource conflicts average for the year, it also has its problems. For example, although one resource may average just 30 percent effort on the maintenance work for the entire year, when the same resource is needed on the maintenance branch, a 100 percent effort is required. Depending on the timing of this spike, the resource may already be scheduled at 70 to 80 percent on the current branch. During this critical time, therefore, the resource is over-allocated at 180 percent. The bottom line is clear: We've created a foreseeable and avoidable bottleneck on the resource and a delay in the schedule. So even if the resource allocation averages out across the year, it doesn't work well for the spike times, when the critical work is actually needed.
A multi-tier analysis of resource demands can produce more realistic schedules. As noted earlier, the peak level of effort for a coder is high in the Construction phase of each program branch.5 As shown in earlier diagrams, we can visually illustrate those peaks on each tier with a solid line. Once you replace the generic blue timeline with your actual milestone calendar dates, you have a very visible and useful tool that helps you identify exactly in which calendar weeks the bottlenecks and constraints will likely occur.6
Figure 9: Pink highlighted areas show where the spikes in resources will appear.
Using this multi-tier knowledge, we now create the single-tier program schedule.
Incorporating the multi-tier analysis solution to a single-tier schedule
It's normal to receive a skeleton top-level, single-tier program schedule from corporate planners that outlines marketing commitments and timelines. This skeleton schedule is your base. You are expected to mold and shape it into a realistic schedule. Although certain dates are "more fixed" than others (for example, the end-date in which product marketing and the sales team are publishing), the schedule itself is meant to be used as a starting point. This is an important concept to embrace. Your team may have little control over the end-date, but you have influence on how your team actually gets there.
For example, the master single-tier schedule in Figure 10 has the overall Construction phase divided into three six-week periods. At the end of each six-week iteration there are important deliverables and dependencies that are required. Obviously, it's important to deliver at those points.
Figure 10: Sample master schedule that has the overall Construction phase divided into three six-week periods, with important delivery dates at the end of each iteration.
As we reviewed in the previous section, normally in a single-tier schedule, managers ask our practitioners how many features they can deliver in each six-week iteration. We've previously shown how we can get into trouble using only that method. So let's walk through a similar scenario using our multi-tier schedule.
Because I have done my multi-tier analysis up front, I know that my resources will be pulled to do maintenance at the points highlighted in pink in Figure 9. Therefore, I need to proactively adjust my level of effort in my schedule to accommodate the maintenance spike. How do we accomplish this?
Using the multi-scheduling analysis, I realize that in the calendar time period between Version 2.0, Iteration2 and Iteration3, my resources will be required to focus on the maintenance branch (in support of the customers that already have Version 1.0).7
Bearing in mind that the Master Version 2.0 Schedule is just the framework, I realize that I don't have to have three six-week consecutive iterations. I can define more appropriate iteration lengths that accommodate my known and very real maintenance tasks, as mapped out in Figure 11.
Figure 11: Define and schedule your iteration lengths for Version 2.0 around the expected maintenance spike for Version 1.0.
At this point, I define my Version 2.0 iteration lengths around the maintenance spike for Version 1.0. I ask my practitioners to estimate how many features they can complete in a six-week Iteration1, a five-week Iteration2, and a four-week Iteration3. To make sure everyone on my team understands my definition of what "complete" means, I provide a detail task list template for everyone to use as an estimation worksheet.8 Using this technique, I've essentially completed a "feature scope" because I've reduced the time for which folks can complete their features. This "feature scope" is done prior to actual code and design, therefore, there is no risk that eliminating these features at this stage will generate errors or cost time.9 This also eliminates the time wasted in creating features that we can't deliver. By doing this up front, I have reduced the risk of having to add resources (pulling them from other projects and affecting their delivery schedules) or adding time to the schedule (creating additional delays for the customer, as well as additional resource conflicts across Version 1.0 and Version 3.0).
The forced buffer between Iteration2 and Iteration3 can also be used by other teammates to reduce defects, stabilize the product, and get early customer feedback.10
On top of those important goals, I have also complied with the important milestones defined by the overall master schedule at each six-week point. In fact, I've delivered the Iteration2 milestones early without the overhead of task switching.11
If the multi-tier scheduling technique seems simple, that's because it is. The multi-tier scheduling technique is not intended to be used in a vacuum. It should work with your other tools and be exercised according to your experience. Although this and my previous Twelve Scheduling Tips are not an exhaustive list of ways to improve scheduling, I'm confident that acknowledging and plotting your parallel tasks in this way will provide some ease to organizations that are taking on increasing workload. I'd be happy to hear from you regarding any of these ideas, especially if any of them help you and your team.
1 This incorporates Tip 7: Rigorously institute reasonable forcing functions.
2 For example, you can find definitive information on the Rational Unified Process in Philippe Kruchten's book, The Rational Unified Process: An Introduction.
3 No more code changes are submitted for this release.
4 Although removing features is also a viable solution in the earlier stages of a development cycle, in the last quarter of the Construction phase it's more time-consuming and risky to eliminate features that have already been integrated into the product's design. Other features are now dependent upon the existence of those components. Because it would take longer to remove and verify the effects, removal of features are rarely attempted in the last quarter of development.
5 The level of effort trends (peaks and valleys) for the different roles on a project (coder, tester, business analyst, etc.) may be shifted slightly to the right or left, depending upon the roles' activities. But the trend outlines remain similar. This method can also be used on an individual level, or in any place you have planned multiple streams of activities with a single resource.
6 This incorporates Tip 3: Identify critical paths and bottlenecks early.
7 This incorporates Tip 3: Identify critical paths and bottlenecks early.
8 This incorporates Tip 2: Document detail task lists.
9 This incorporates Tip 9: Accept progressive refinement, which accepts fewer feature commitments, combined with an aggressive "best effort" feature list.
10 This incorporates Tip 10: Reduce inventory wherever possible.
11 This incorporates Tip 1: Use the technique of sprints and buffers.
Laura Rose is the quality assurance manager responsible for automated performance test tools at IBM Rational. In addition to leading projects in both software programming and testing environments, she has thirteen years of programming experience and ten in test management. She has been a member of the American Society for Quality, the Triangle Quality Council, and the Triangle Information Systems Quality Association, and has published and presented at various test and quality conferences. You can reach her at llrose@us.ibm.com.
Table of contents
Local resources
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
