7.4 Introducing the Holistic IterativeIncremental Use-Case-Driven Project Lifecycle

7.4 Introducing the Holistic Iterative/Incremental Use-Case-Driven Project Lifecycle

Introducing the Holistic Iterative/Incremental Lifecycle ( HI /I or Hi-Eye)

DEFINITION:

The words iterative and incremental are often, incorrectly, used interchangeably. Understanding each term is important to knowledge of the overall approach.

Iterative means redoing something several times, increasing richness, comprehensiveness, and consistency each time.

Incremental means creating something piece by piece and integrating the pieces into the whole a little at a time.

7.4.1 The Meaning of Iterative

Look at the illustration where the totem pole is being constructed iteratively. Notice how the artisan goes through stages of doneness, making each pass a little more detailed and defined. He may have to shave off some carved bits of wood in a later pass. In software development, we call this recoding, or, more accurately, refactoring.

Another metaphor for iterative development might be painting a house. First, you put on a primer coat. This is often a completely different color from the one you are going to use later, maybe beige or white, but it works well for the primer. You just slap it on, not worrying about whether it is perfectly even or whether it looks nice. Then you add the first coat of the finishing paint. This coat is the right color, but it is still a little uneven when you apply it. Perhaps another coat is required to smooth out the color and texture because some parts of the wood soak up more paint than others. In the final iteration, you apply the finishing coat of paint. This paint must be evenly applied and nicely textured. It should look exactly right in all places. It should cover every area of the wall, even the nooks and crannies.

In the context of this book, an iterative approach to requirements specification includes the refinement of use cases and business rules through a series of brushstrokes, which we categorize as Facade, Filled, and Focused iterations.

In The Unified Software Development Process (Jacobson 1999), the authors outline several things that iteration is not:

• Random hacking

• A playpen for developers

• Something that affects only developers

  Iterative Totem Pole Construction

  

• Redesigning the same thing over and over until the developers finally chance on something that works

• Unpredictable

• An excuse for failing to plan and manage

7.4.2 The Meaning of Incremental

In incremental development, you create something in small parts. If you were building a house incrementally, you'd build one room at a time. First, you'd put up the bathroom. Then you'd add the kitchen. You'd put a door on this tiny house to keep the elements out. At this point you could begin living in it. Next , you'd add a bedroom. Then a living room. Later, a dining room and extra bedroom. The creation of each room is not willy-nilly ”it follows a design ”and the benefit is that you can start living in the house a lot sooner than if you waited until the whole house was built. What's more, you will need heating, ventilation , plumbing, and electricity for just the bathroom, the first increment. So you get to try working with these subsystems early in the project, giving yourself an opportunity to evaluate the risks and problems very early. If you find you've used inadequate wiring in the first increment, you need to rip it out of the walls of only one room, a big savings over if you had built the whole house already. With houses , the builders are already quite knowledgeable about the process and constraints, so they tend not to need this incremental approach. But with software, a much less mature industry, we need help from the incremental approach, in every case except where the goal is crystal clear and the environment is exceptionally stable, which doesn't happen often.

Incremental House Construction

Alistair Cockburn calls this kind of methodology build-deliver-learn. By cutting the application into lots of small chunks of functionality and delivering them separately, you get a chance to learn from your mistakes during the early iterations.

In the context of this book, an incremental approach to requirements specification includes completing batches of use cases and business rules together, but not assuming that all artifacts must be completed at the same time. For instance, of a total of 25 identified use cases, your team may create 5, then proceed through analysis/design/construction/testing/deployment for those 5. While those use cases are being built, part of the team can tackle the next five, and so on.

SEE ALSO:

http:// members .aol.com/acockburn

7.4.3 The Meaning of Holistic

Looking at an iterative/incremental lifecycle, one shortfall tends to be evident. If you are creating software piece-by-piece, and iterating to make it right, how do you keep the big picture in mind? How do you ensure that the pieces work together effectively to solve the overall goal?

These are reasonable questions. A major risk of failure in iterative/incremental projects is the loss of focus on the big picture and an end product that is a mish-mash of pieces that do not operate as a whole.

One side of the solution to this paradox is software architecture. Software architecture (a term borrowed from the building industry) is the underlying structure of a software application. The person in charge of this is the software architect. This role becomes even more crucial in an iterative/incremental project, because now the architecture needs to play the role of keeping these iterations focused on the end goal. In a waterfall project, many architects fell into the role of defining hardware/software standards and then stood aside as the program code was created. No more! An architect is a hands-on manager who ensures that the end product hangs together. Architecture encompasses many aspects: component interfaces, application layers /tiers, deployment environment, security, multiprocessing, data access, configuration management, coding and data communication standards, hardware, and package usage.

A second side of the solution to a holistic iterative/incremental process is business strategy alignment. If software architecture is about staying true to the technological vision of the application, then business strategy alignment is about staying true to the business vision of the application.

Business strategy alignment makes the assumption that a business strategy exists. A strategy is much more than a mission statement. It may consist of mission, vision, values, and a set of high-level steps that will get the business moving toward those goals. Then the individual initiatives undertaken within the organization need to be tied back to the strategy. Usually, some type of framework is required to do this. We use the Purdue Enterprise Reference Architecture (PERA) to accomplish this alignment back to the business strategy. It is a generic business model that provides alignment of technology initiatives back to the business strategy. If the business strategy is not defined, PERA helps create one. PERA is in the public domain; it is not proprietary to us or any other consulting company.

SEE:

http://iies.www.ecn.purdue.edu/IIES/PLAIC/PERA/Publications

7.4.4 The Meaning of Adaptivity

The use case process needs to be as adaptive as a living organism.

The goal of the holistic iterative/incremental lifecycle is to achieve adaptivity. We show our definition of adaptivity here:

adaptivity n. 1 . capability of making suitable or fitting a specific situation

Again, two terms are often used interchangeably: adaptivity and adaptability. But adaptability is a different quality:

adaptability n. 1 . capability of being made suitable or fitted to a specific situation

Using these definitions, adaptivity is much more dynamic than adaptability. An adaptive system will adapt itself to a new situation. An adaptable system can be changed to suit a new situation, but it will not change itself.

For example, when a business requirement changes, an adaptive software development team is able to take it in stride without missing a beat. An adaptable team can incorporate the changed requirement, but there is disruption and a loss of productivity as the group rethinks its approach.

Of course, the application of these terms is relative. Is any software development team completely adaptive? We've never seen it. However, in comparing a team to the industry, you could see that a particular team can handle changes much more easily and effortlessly than other teams , and therefore judge it to be an adaptive team.

7.4.5 Complex Adaptive Systems

The concept of adaptivity has gained tremendous visibility in the past ten years with the acceleration of research into complex adaptive systems. In the Santa Fe Institute in New Mexico, scientists from many disciplines (economics, physics, biology, chemistry , computer science, and others) came together to begin their study of why complex systems behaved in ways that seemed completely strange and unpredictable (Waldrop 1992). They knew that small changes to a single variable in a complex system could reverberate through the system until it had gone into what appeared to be complete chaos. To sum up their goal, these scientists were determined to make sense of chaos. (Sound like any software projects you've experienced lately?)

As they progressed, they found that complex adaptive systems do, indeed, act in a consistent way. Complex adaptive systems include a pond ecosystem, the human brain and body, city traffic, a business, an airport, an industry, a country, a stock market, and the weather. A description of chaos theory (which ideas preceded complexity) often goes like this: A butterfly flapping its wing in Singapore can create a hurricane in South Carolina. The idea is that small changes of a small number of the input variables into a complex adaptive system can cause very large changes to occur in the system.

Using large computer models to track the changes in the systems when input variables changed, they found that these systems had a center point to which they would return after the reverberations of input changes. They called this center point a "strange attractor." Using this as an anchor for more research, they found that these seemingly " chaotic " systems operate in a consistent, although not predictable, way.

In software, we have begun to realize ”after much learning from our mistakes ”that our projects and processes are complex adaptive systems. People are unpredictable by definition. Requirements and business priorities change constantly. Technology is like a treadmill moving and changing and improving. These factors contribute to a very dynamic environment, one that resembles a living organism much more than a machine (Highsmith 2000). This means we need to be focused on making our processes adaptive instead of optimizing, which is our current focus. Tools and models like the Capability Maturity Model (CMM) and its derivatives, ISO 9000 quality certification and others, focus on optimizing an organization to produce as much as possible with as few resources as possible. This works for an organization where change is not an issue; however, most of our organizations have constant change as a very prominent issue. For us, adaptivity is the key.

Listen for the metaphors that are used on your projects. If you regularly hear the following metaphors, you can be pretty sure the team thinks of itself as a machine:

• "We need to work together like cogs in a wheel."

• "This team is running like a top."

• "The squeaky wheel gets the oil."

• "Those businesspeople are always changing their minds."

• "We are a lean, mean programming machine!"

• "Let's crank out that code."

• "We will let this project go for another month before we turn it off."

• "He really threw a wrench/spanner in the works when he added that requirement."

On the other hand, if these are the metaphors you hear, your team thinks of itself as a living organism, adaptive to change:

• "Let's see where this takes us."

• "It's okay, we can change right along with the business."

• "This product has grown into something good."

• "Let's breathe life into this product."

• "This product will evolve into something more comprehensive in the next release."

The project that most resembles a living organism is the project that will effectively keep up with the business. The project that resembles a machine will break down and cause problems in any business situation that is fast-changing, dynamic, and unpredictable. Your goal is to move your corner of the world toward becoming a living organism. But how?