7.5 Process

In this section, we'll provide the details of the "how" for holistic iterative/incremental. Although our book is focused on creating good quality requirements for software products, we feel it is necessary to show how those requirements can effectively drive an HI/I lifecycle.

From a software process perspective, we've been sleeping while our businesspeople have been changing dramatically. The world of business in North America, and indeed around the world, has changed incredibly since the 1970s:

• Globalization of markets has increased competition and trade.

• Time-to-market has become a huge competitive advantage once cost and quality of products and services are equal (which is more likely to happen in a global economy).

• Price pressure keeps increasing, causing businesspeople to constantly re-examine what they can remove of their own costs.

• Business books of the last few decades have had titles like:

  - The Living Organization (Guillory 2000)

  - Thriving on Chaos (Peters 1991)

  - Leadership and the New Science, Second Edition (Wheatley 2001)

  - Birth of the Chaordic Age (Hock 2000)

  - Adaptive Enterprise (Haeckel 1999)

These are not new concepts in business. Some of these books are over 20 years old. Businesses have been borrowing from complexity science for some time now, to help them adapt to globalization and other complex environmental factors. In software, however, we seem to be clinging to the thought that we can stay "organized" while business is flying around in its chaordic state. ( Chaordic is a state of being at the edge of chaos and order.)

Yes, we're aware that several methodologies have arrived that tout the adaptive lifecycle. The RUP is the most popular, providing a highly detailed methodology centered on the iterative/incremental concept. XP is a set of process patterns that give advice as to how software could be created using iterative/incremental techniques. It is not meant to be a methodology; it does not describe a lifecycle nor does it provide artifact definitions. However, it is often thought of as a competitor to RUP, in that both describe an iterative/incremental way of developing software. (eXtreme Programming has no link whatever to Microsoft's Windows XP "eXPerience" operating system.)

What is interesting is that, although many organizations have purchased the books, CDs, and training for these methodologies, hardly any have actually "converted" to an iterative/incremental process. Organizations, including in-house shops and especially consulting firms, have merely relabeled their deliverable names , with requirements specification becoming use cases, dataflow diagrams becoming object model, and project plan becoming iteration plan, without really making the jump to iterative/incremental.

Here are some iterative/incremental myths commonplace in those organizations that we would like to dispel:

Iterations can be any length . Iteration length is extremely important. This is mostly due to human nature. Iteration length is best optimized to the length of time a person can effectively focus on a deadline and a set of functionality without losing concentration. Unfortunately for us humans , this is a very short time, only about 1 “3 weeks. Any longer than that, and we lose focus. Also, the focus issue is important with our business sponsors. How long are they willing to wait in their chaordic world before they want to see tangible progress? We're not talking about a release of the product into production necessarily, necessarily , just something that can answer the businessperson's query, "Let's see what you've done so far." And folks, showing them a stack of design documentation will not appease them. It must be running, working code, every 1 “3 weeks.

Iterative/incremental is just lots of small waterfalls . This is not entirely false, but it is a bit misrepresentative. The nature of a waterfall lifecycle changes when it is reduced down from 6 “9 “12 months to only 1 “3 weeks. Things become much less formal. The procedures that seemed so important become less so in a more narrowly focused iteration. The best way to find out which procedures are important and which ones haven't been helping is to try a small iteration with a small team and see what you can leave out.

Iterative/incremental can be managed the same way we managed waterfall ”task-by-task . This is dead wrong, and you'll die trying. Waterfall projects can be managed by task assignment, because we have (in theory) a situation with little change, and we can plan our tasks assignments far out into the future. Iterative/incremental assumes a dramatic amount of change, and therefore the project managers manage more to the set of requirements than to the set of tasks. Project managers divide the work according to the requirements (use cases), and then the team makes sure that those requirements get implemented in the iteration. Self-managed teams , as far as task assignments go, only work on a small scale. So, the idea of iterative/incremental is that, if you break up that large software application into many small pieces, each of which can be accomplished by a team of three to four people in 1 “3 weeks, your project managers can worry less about tasks and more about the series of requirements to implement.

We can still test manually . Again, by breaking up our project schedule into many mini- implementations (iterations), we change the nature of the lifecycle. When we test the first iteration of code, we test all the functionality the team built that week (or 2 “3 weeks). In the second iteration, we test iterations one plus two. Imagine the testing effort in iteration fifteen. Automated test tools are a must. Regression testing tools will test application functionality (Mercury Interactive WinRunner, Segue SilkTest, Rational Robot, and so on), and load/stress testing tools will test the architectural soundness of the application (Mercury Interactive LoadRunner, Segue SilkPerformer, Rational TeamTest, and so on).

We must keep our team from having to redo work . The impulse to keep teams from "rework" is a holdover from basing our software projects on industrial-age projects, such as building a bridge or creating a factory. Rework is essential to a business software project. Avoiding rework is part of "optimization." Projects that hold an optimization focus are those where the goal is well understood at the beginning of the lifecycle and changes are rare during the lifecycle. The opposite focus of optimizing is adaptivity. Adaptivity means that the team is trying different approaches, cutting its losses on things that don't work, and charging forward when something does work.

We need to deploy every iteration of code. This will be hard to do, and a bit wasteful in the early iterations. Most teams will need to postpone true deployment onto the target hardware/software/database environment until a few iterations have been created and it is worth undergoing the overhead of deployment.