TRADITIONAL/AGILE HYBRIDS

by Robert K. Wysocki, Ph.D., Senior Consultant, Cutter Consortium

In several client engagements, I have encountered situations that have me wondering just how agile is agile project management. The typical client had heard about agile project management and was curious. They were having a lot of problems with particular types of projects and were curious to find out whether any of these so-called agile approaches could help them out. The clients I have in mind were firmly entrenched in traditional linear approaches to project management and systems development and were not likely to explore a completely agile approach to their problem projects. Their low tolerance for risk and basic conservative culture would be show stoppers for them going agile.

In what follows, I will characterize what I would do were I asked to help these clients resolve their problem projects. The project and situation I use in the example are hypothetical but illustrate the point I want to make: that is, there are projects for which a hybrid approach that integrates traditional and adaptive project management processes can be successful.

The Situation

The client has defined the need for a new distribution system that includes a delivery truck routing application that had eluded the company's brightest minds. The requirements of the application were so sophisticated that a solution was not at all obvious. In fact, their brightest minds were having great difficulty even framing the routing application in terms of functions and features. A solution had to be found or the entire application would be useless. The immediate question facing the VP of logistics and the development team is how to approach such a project.

This situation is not unusual. It is a classic example of an application that must be developed. Most of the application is well defined and clearly documented. One significant part has not been defined nor documented; in fact, it is not much more than a black box. The organization has to find a solution because the success of the entire distribution system rests on it.

The Hybrid Approach

Suppose the project consists of five major requirements (A through E). Requirements A through D are completely specified. All of the functionality and features are identified and clearly documented. Requirement E, on the other hand, is different. The requirement is bleeding edge and little is known about it other than what it is supposed to do. Some of the functionality and a few of the features associated with that functionality might be known. If it weren't for requirement E, this project would follow a traditional linear approach such as the standard waterfall model. If the project consisted of nothing but requirement E, some type of agile or adaptive approach, such as the Adaptive Project Framework (APF), would be chosen. The standard waterfall model and the APF have very little in common, so how should we structure our approach to this seemingly complex management situation?

The resolution is actually quite simple. Here are the steps I recommend:

• Step 1: Complete the work breakdown structure for requirements A through D down to the task level.

• Step 2: For the time being, treat requirement E as a task

• Step 3: Build the dependency diagram showing all of the tasks from step 1 and 2.

• Step 4: Calculate the early and late schedules and the critical path.

As a result of step 4, you have the early start and late finish of all of the work that must be done to meet requirement E. You just don't know what that work entails. Treat the entire project using a traditional linear approach. Treat the work to meet requirement E using an adaptive approach. You have now embedded an adaptive approach in a traditional linear approach.

Looking at this approach from another perspective, you could think of this project as comprising two dependent projects. The first project uses a traditional linear approach to deliver on requirements A through D. The second project uses an adaptive approach to deliver on requirement E. The two projects are dependent upon one another. The second project gets its start and end date from the first project.

Conclusion

This concept of embedding one approach in another is quite robust. There are only two conditions that must be met:

• For the approach that is being embedded, you must be able to calculate a start date and an end date from the project in which it is being embedded.

• For the approach being embedded, there must be one predecessor task or milestone and one successor task or milestone from the project in which it is being embedded.

The second condition can actually be relaxed but to do so adds more complexity to the dependency structure between the two projects.

-- Robert K. Wysocki, Ph.D., Senior Consultant, Cutter Consortium