A customer driven application development lifecycle that:

RADical software development focuses on three areas: customer, product, and process. Much of the current literature on rapid development focuses on particular techniques (JAD, prototyping, timebox). To raise the chances that these projects are successful, and certainly for these projects to have an impact on changing the larger organization, we need to expand their focus.

Close to the Customer

Stanley Marcus of Neiman Marcus put the issue of customer and product as succinctly as anyone has, "There are only two things of importance. One is the customer, and the other is the product. If you take care of customers, they come back. If you take care of product, it doesn't come back. It's just that simple. And it's just that difficult."

There are a number of useful techniques to build a customer driven organization, but three seem to have particular application to a software development project:

Customer satisfaction surveys can take a variety of forms, from a written questionnaire to individual interviews. Each has benefits and shortcomings, but the key issue is to measure. A series of questions using a 1-7 scale is appropriate for qualitative measures. More quantitative measures can be developed as areas are highlighted by customers. The key questions are: "Which product and service characteristics are important to your customers? What is the relative importance of each of their wants?

JAD sessions have been touted for years as an important technique for gathering specifications (or design or other information) for software applications. They engage customers and developers in a common dialog, and speed the development process. The key short-coming of the process, not really JAD's themselves, is untimely feedback. Customers attend JAD sessions, usually get documented results, usually feel pretty good about the sessions, but product results are still ephemeral. Our contention is that without an evolutionary development cycle (discussed later) that produces interim product versions, the benefits of JAD are quickly dissipated. JADs need to be quickly followed by product versions, and then the next customer oriented technique -- the focus group meeting.

Like JAD sessions, customer focus groups are special meetings with several imperatives:

In a variety of projects, focus groups have proven to be remarkably successful. Customers like the fast turnaround: they evaluate a product rather than some indecipherable diagram, their comments are taken seriously -- and they invariably become what developers have wanted -- they become involved!

Results Oriented Quality

Is quality important? According to Capers Jones, "A cumulative defect removal rate of 95% on a project appears to be a nodal points where several benefits accrue ... these projects have the shortest schedules, the lowest quantity of effort, and the highest level of user satisfaction."^[2]

This leads to the question of what defines quality. Is it an intrinsic part of the product, or is it a some person's viewpoint? We use Jerry Weinberg's definition, "Quality is value to some person."^[3] Software "value" appears to have three broad characteristics -- Scope, Schedule, and Resources. Value is also tied to use. For example, what value would you consider Windows 3.1 to have if it was controlling your heart-lung machine? Given that usage, Windows would have very little value. But if you want to run a suite of integrated desktop applications, Windows has significant value.

So to succeed in the software development business, we must build high quality software, and that quality must be defined (primarily) by the customer. And whether we like it or not, whether we think it is fair or not, the one item that dissatisfies most customers of software products is speed of delivery. Our customer's perception of quality is highly "speed" oriented. The development process must be reengineered to meet this expectation.

Software Process Reengineering

If we are to attain processes that produce software at higher speed, we first need to closely examine the beliefs or attitudes about "control" . The goal of a development organization should be getting product out the door, i.e., delivery or throughput. Throughput is the rate at which the system generates money through sales.^[4]

Our belief in control leads to barriers to throughput. Belief in control leads to hierarchical layers of management. In large, multiple project software development organizations how much time loss is due to control points in development? Management reviews, data administration approvals, operations standards, supervisor reviews, architectural guidelines, design standards -- all developed with the best intentions, but as a whole place barriers in the way of finishing projects. Most development organizations end up with the equivalent of high "work in process inventory" and very little throughput. Per Goldratt's definition above, organizations are not paid for inventory, but for sales, delivery to the customer. The "waterfall" type development methodologies are an outgrowth of the belief in control.

As we talk about RADical development -- powerful tools, teams, JADs, etc. -- it could be one reason it works is that it emphasizes throughput, getting something out the door, and de-emphasizes control, blocking the door. Giving a team a clear objective, concentrating the resources, and getting obstacles out of the way is often half the secret in making rapid development successful.

There are four key aspects to reengineering the software development process.

1. The overall process, the software development life cycle, must undergo a transformation from a static, documentation orientation to a dynamic, evolutionary, product orientation.
2. Doing activities faster requires a skill at "timeboxed" project management techniques.
3. An evolutionary life cycle will not yield the desired benefits without promoting high performance, dedicated teams.
4. Transformation to a RADical approach does not mean abandoning the critical software and information engineering skills gained in the last 15 years. Instead, these skills need to be redirected into -- continuous application engineering.

Evolutionary Product Development

Traditionally the model for software development has been the "waterfall model." Most of the commercially available methodology products follow this approach. While waterfall methods brought some stability and order to the chaos of earlier development efforts, their shortcomings are becoming increasingly apparent and many software development organizations are lost in the "swamp" of waterfall development.

Maintainability and life cycle costs have been a major reason for installing software engineering techniques and methodologies. One issue often raised with rapid development is that of maintainability due to poor design or architectural planning. If rapid development is implemented as a return to coding without thinking, then the issue is valid. Done properly, maintainability in an evolutionary environment is even better! Why? Because the essence of evolutionary development is change, incorporating a large volume of customer changes as the project progresses is require of the process. In order to do these effectively, the development approach focuses on making change easy, including good design, architecture, coding guidelines, etc. This tests the change process over and over again as the project progresses. Done properly, evolutionary development produces more maintainable products.

The evolutionary model produces appropriate documentation, but focuses on delivering versions of the product. The documentation produced is more appropriate to the phase at hand, and it "evolves" just like the product. For example, the first release might include a "sketch" of a data model, and the final release might include a complete data model.

Evolutionary development speeds the process and improves feedback. It can:

1. Establish applications that can evolve over time
2. Accommodate changing business needs
3. Adapt development processes to the application
4. Deliver earlier benefits to customers
5. Reduce the risks of major failures
6. Help in gaining customer confidence early in the process.

The following figures show different perspectives on an evolutionary development process. Figure 1, illustrates that each application is both initiated as a project and planned in an evolutionary mode. Evolutionary planning would include developing high-level requirements, segmenting the application (if required), initiating an overall architectural framework (especially if several segments are identified), and planning the iterative version cycles.

Figure 1 -- The Evolutionary Life Cycle

Figure 2 shows that evolutionary planning occurs prior to any development work. For small applications, this front end work may be very brief, essentially setting up the project. At the end of the project there is usually an installation phase (internal products) or a manufacturing/ distribution phase (external products). Between planning and release there may be several major versions (milestones) and a series of interim versions. With more than one application segment, there is usually a combined integration/ quality assurance/ beta test phase as part of manufacturing/installation.

Figure 2 -- Evolutionary Versions

Figure 3 -- Evolutionary Versions

Figure 3 shows the converging nature of an evolutionary project. By constant attention to and involvement of the customer through JADs, customer focus groups, and ongoing project participation, the projects "converge" on success. Within a version, a tighter 1 day (continuous) to 3 week cycle would operate as shown by the interim version arrow in the figure. A major customer focus group session defines the end-point of a version.

Timeboxed Project Management

Good project management is even more important as the pace of projects accelerates. There is little time for the delays experienced on long projects. Quick decisions are needed. Barriers are not merely eliminated, they are anticipated. Meetings cannot be delayed until next week. The project focus -- goals, objectives, constraints -- must be clearly articulated and re-reinforced. Selecting the right projects for an evolutionary approach is critical to success. The executive sponsor, who is the prime customer decision maker commissioning the project, needs to be a very active participant.

It is not the intent of this article to repeat the tenets of good project management. However, the following are of particular importance to accelerated projects:

The final important point about RADical projects is to make noise. Keep the project's progress visible to the team, customers, and management. Since RADical development will be new for many organizations make sure to market it well. Part of this "visibility" is to ensure improvements are measurable...things like elapsed time for projects, total resources expended, function points delivered, perceived quality by the customer, and change requests processed need to be monitored and reported on a regular basis.

High Performance Teams

There is a tremendous emphasis in many organizations today on "teams." This is often stated as a goal of moving from a hierarchical, top-down organization to an empowered, team-oriented organization. This team orientation is one of the foundation blocks for many process improvement efforts. Software development organizations seem to be good candidates for this "team" orientation, but building teams, much less high performance teams, takes enormous skill and discipline, and, oh yes, a dusting of luck!

There is considerable difference between a real team and a group of people who work together. Given the proper environment, results can be startling:

A jelled team is a group of people so strongly knit that the whole is greater than the sum of its parts. ...Once a team begins to jell, the probability of success goes up dramatically. The team can become almost unstoppable, a juggernaut for success.^[5]

Teams can just as easily degenerate into being less than the sum of its parts. So what ingredients go into making successful teams? One of the best answers to this question comes from Katzenbach and Smith The Wisdom of Teams.^[6] We use their definition of a "realī team as a framework for building good software development teams:

Truly jelled teams develop their own sense of reward because they believe in the project's vision. They are willing to subordinate their personal agendas and rewards to those of the team, and thereby provide the foundation that allows the team to far outperform a group of individuals. It is not easy. Building the trust to achieve mutual accountability involves hard work, and the personal risk associated with resolving conflicts. Many groups avoid that risk and thereby deny themselves the chance to be a real team. Building high performance teams begins with individuals willing to take this personal responsibility.^[7]

Continuous Application Engineering

Some proponents of rapid development methods see them as a replacement for software and information engineering techniques. In addition, many writers of iterative and prototyping methods eschew formal techniques. But abandoning what we have learned about building high quality systems is not the answer. Many of the frustrations with software engineering have come about from two sources.

First, the confusion between the techniques themselves (data flow modeling, entity relationship modeling, object modeling) and the "Methodologies" that have been developed to incorporate many of these techniques. No matter what kind of project is undertaken, some analysis work is required. We need to use whatever appropriate techniques we have in our tool bag to accomplish that analysis.

Whether you are a "software engineer" or an "information engineer" or an "object engineer," don't abandon the useful techniques developed over the years. As mentioned during the discussion of the evolutionary life cycle, the analysis activity lasts throughout the project, as do other major technical activities. The more skilled the analyst, designer, data modeler, or programmer is at these techniques, the faster, and better the project will be. In fact, without these skills, RADical projects will not be any more successful than traditional ones.

Conclusions

At the beginning of this article we stated its objectives as two fold: "First, to provide a framework for achieving successful accelerated projects. Second, to show how RADical project success, viewed within the larger organizational context can be the catalyst for transforming software development processes."

Hopefully, we have kindled interest in the transformation process by showing a glimpse of potential results, and a framework for achieving them. A transformation process begins with a single project having the goal of delivering visible and tangible benefits to the customer. That first project should focus on project related skills and delivering a useful software product to the customer. A second series of projects might then focus on delivering useful products, and refining the evolutionary process. A third series of projects might then be undertaken with a further goal of implementing the organizational and management changes needed. This three pronged attack should be viewed as a 12 to 18 month undertaking. Each project is used both as a vehicle for longer range transformation and to focus on various aspects of the RADical Process.

Reengineering processes involves major changes and major change is extremely difficult. But the driving global competitive forces to change are awesome -- heightening customer dissatisfaction with information technologies' inability to keep pace. If information technology is one key to reengineering corporations, it is time to think seriously about reengineering the engineers.

Footnotes

1. Hammer, Michael, "One on One Interview," Computerworld, January 24, 1994.
2. Jones, Capers, Applied Software Measurement, 1992.
3. Weinberg, Jerry, Quality Software Management, Vols. 1 (1992) & 2 (1993).
4. Goldratt, Eliyau and Robert Fox, The Race, 1986.
5. DeMarco, Tom and Tim Lister, Peopleware, 1987.
6. Katzenbach, Jon and Douglas Smith, The Wisdom of Teams, 1993.
7. Jim Highsmith, "Software Ascents," American Programmer, June 1992, pp. 20-26.