What Makes a Good Agile Logical Process?

Having discussed the elements that make up a software development approach, we’re now going to examine in a bit more detail the qualities we should look for in a logical process.

We Need an Obvious Logical Flow

While in an agile context, we’re unlikely to formally record traceability between deliverables, but it should at least be conceptually possible to trace from the earlier to the later deliverables. We must be able to see how the whole process hangs together, otherwise we’ll start making the wrong decisions as we model. In this sense, many earlier deliverables can be seen as abstractions (high-level views with detailed information missing) of later deliverables. For example, the classes in a first-cut domain model with no attributes or methods are likely to still be present in the final code of the system.

ICONIX Process meets this criterion by giving us four major stopover points on our way to working software:

• Requirements analysis, consisting of UI prototyping, use case identification, and domain modeling

• Analysis and preliminary design, consisting of detailed descriptions of use cases, robustness analysis, and a more fleshed-out domain model

• Detailed design, consisting of sequence diagramming and class modeling

• Implementation, consisting of code development and unit, integration, and system testing

We Don’t Want Unnecessary Dependencies Slowing Us Down

Instead, we want closely related deliverables to be grouped together. Our motivation in using a development process is to speed up and decrease the risk of the overall development, not to slow it down. Processes with unnecessary dependencies and/or poor grouping of deliverables are likely to slow us down if we adhere too strictly to them. A process that, for example, dictates that we develop a full set of use cases before we start a domain model will suffer from this problem.

Agile ICONIX avoids this problem by grouping heavily interrelated deliverables into the same basic step, assisting us in following Scott Ambler’s agile modeling principle of iterating to another model.^[3.] Domain modeling and use case analysis, for example, are clearly interrelated activities. Use case descriptions cross-reference the entities in the domain model, and by iterating between the two models, the process builds an inherent consistency into its approach, while enabling each technique to reinforce the other.

We Want Each Step to Clearly Move Us Toward Our True Goal of Working Software

A development process can be viewed as a sequence of steps to turn a fairly vague initial requirement into a solid software deliverable. Each step within the process must first and foremost add value, taking us nearer to our true goal of working software. To achieve this, the work we produce in each step must be structured to make the next steps easier. We’ll need to iterate to the next step, whether formally or informally, to ensure we’re making true progress.

For example, take the approach used within older-style processes such as SSADM. Analysis in SSADM was performed using, among other things, data flow diagrams (DFDs), which, while they undoubtedly assisted the analysts in clarifying their ideas, offered little or no assistance to the design and development team in structuring the software. Much of the work undertaken during analysis had to be redone, with the designers having to completely restructure analysis results. OO methods and notation avoid this pitfall to some degree, but some are still prone to this problem in some areas.

Again, each of the four basic steps in the Agile ICONIX process meets this requirement:

• Requirements analysis takes us from a vague list of requirements to a detailed description of the use cases that will make up the functional design of our system.

• Analysis and preliminary design gives us an accurate domain model of the system—an important step if we are to truly deliver the right system to our users.

• Detailed design gives us the fundamental class structure we are going to implement.

• Implementation gives us our working system.

Note that Agile ICONIX is an inherently incremental process, so each of these four steps typically addresses a subset of the overall system, with each increment building on the previous one.

We Want Guidance That Will Reduce Unnecessary Work Later On

We’re faced with many decisions when writing software. It’s important that we understand that some decisions are more important than others—there are high-impact decisions and there are low-impact decisions. High-impact decisions are those that will have a pervasive effect across our software and models. These decisions tend to be “architectural” in nature. Take, for example, the effect of changing a single-user system to be a concurrent multiuser system. This is a very high-impact change, and it will most likely affect a large percentage of our software. Low-impact decisions, on the other hand, are those that will have only a localized impact. Changing the implementation of a many-to-one relationship from a vector to a linked list is such a decision—its impact is clearly very limited.

From a logical process perspective, therefore, we’d like assistance in ensuring that we focus on high-impact decisions at an appropriate stage. Effectively, agility is about knowing which decisions have high impact and which decisions can be changed easily on the fly. By focusing our effort on the right decisions, we increase our agility.

ICONIX Process assists in this by putting a clear focus on understanding requirements, enabling us to get as much as possible of the “right system” developed in the first place, and also by recognizing that not all requirements are functional (i.e., can be expressed in use case terms) and that we must pay appropriate attention to these as well. Domain modeling enables us to get a grip on the fundamental way in which users perceive the “real world” and to build a system that meets this perception. Detailed class modeling helps us get more of our code right first time, reducing the need for unnecessary refactoring.

Being inherently incremental, Agile ICONIX does this without throwing away the benefits of empirical feedback. You get more right the first time, but if you (or your customer) do get it wrong, you can improve the system in the next increment. Agile ICONIX takes the best of both process-driven and feedback-driven approaches to software development, providing a truly agile and cost-effective approach to satisfying customer needs.

We Want Help Prioritizing, Scoping, Planning and Estimating, and Monitoring Work

We need a logical process that will help us scope and prioritize the work we’re going to undertake. We’ll usually achieve this by using deliverable structure (e.g., use cases) as the basis for discussion of what is important and what isn’t. Similarly, we’d like help in estimating how long work will take to complete, and we’d like a way to monitor our actual progress against our estimates to improve later estimating. A good logical process like Agile ICONIX will help us here by providing a structure upon which we can base and monitor our estimates.

We Want Broad Steps That Provide General Guidance

Given the rate of technology change in our business, many elements of software development are empirical in nature. We can’t attempt to provide a foolproof “algorithmic” sequence of micro-instructions describing how to go about writing software. An agile process like ICONIX doesn’t do this. It provides a broad-stroke sequence of granular steps—signposts, if you like—that help point us in the direction of our ultimate goal of a working software system.

We Don’t Have to Do Every Step (to the Nth Degree)

When we use an agile logical process, we are in charge, not the process. We have to always “model with a purpose,” to borrow a phrase from Scott Ambler, and make intelligent decisions about which deliverables to work on and when to stop working on them. The process is there to provide broad guidance, not to dictate our every action. Take care, however, not to skip a step just because you want to get to coding as soon as possible. Intelligent decision-making requires an evaluation of the pros and cons of the situation, and each step in the Agile ICONIX process has a clearly defined objective.

We Can Undertake Additional Activities (Coding, in Particular) at Any Point

As we discussed previously, some decisions are more important than others. We want to minimize the chance of getting high-impact decisions wrong, and to do this we need to follow Scott Ambler’s principle of “prove it with code.” We want to round-trip the development process to produce some working software that proves our decisions are correct. Agile logical processes like ICONIX don’t preclude us from undertaking other activities, in particular coding, that we deem appropriate at any point.

To summarize, our primary objective is to deliver reliable working software. If we adopt a development process, we do so because we believe it will help us meet that objective. An agile development process in particular is a development process that assists us in applying our overall agile philosophy and doesn’t constrain us in ways that violate the principles we are following.

^[3.]This is the Agile Modeling core practice “Iterate to Another Artifact” (Scott W. Ambler, Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process [Hoboken, NJ: John Wiley & Sons, 2002], p. 44). The premise is that each modeling artifact (use case, business process diagram, robustness diagram, etc.) provides insight into a particular area, so if you find yourself getting stuck on one artifact, try switching iteratively to a different artifact to get unstuck.