Refactoring the Agile Manifesto

For the rest of this chapter, we’ll explain our thinking behind the core agile subset and why it shaped up to be the list of practices that it is.

In this section, we examine whether the values put forward by the Agile Manifesto are a suitable basis for defining an agile process. At the risk of giving away the ending on page 1, the answer is that the agile values are basically sound but could do with a little tweaking to state the message less ambiguously. While that doesn’t sound like a very exciting conclusion, it does provide a useful basis for tailoring a development process to your own projects.

The Agile Values

The Agile Manifesto website has this to say about agile values:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.^[11.]

The agile goals (described in Chapter 1) are sometimes overlooked in the rush to address these values. The agile values are important, but they’re really there to fulfill the goals.

Taken at face value, the agile values suggest that processes and tools are second-class citizens—that as long as you have high-quality people working on your project, the order in which they do things doesn’t matter as much. For example, it wouldn’t matter as much if the team were to launch straight into coding without first eliciting some requirements from the customer. (This would, of course, be a recipe for disaster, quality staff or not!)

Bearing this in mind, we would like to “refactor” the agile values as follows:

• To get individuals interacting effectively, you need flexible processes and tools.

• To communicate unambiguously, you need minimal but sufficient documentation.

• To gain customer collaboration, you need to negotiate a contract first.

• To know when to change and to recognize that you are changing, you need a plan.

Of course, the preceding list goes beyond refactoring because we’re also changing the meaning—placing a different emphasis on and creating a caveat for each value. We understand that all agile processes take these additional caveats into account. However, we believe that for any agile process to be effective, it is as important to recognize these caveats up front as it is the original set of values.

Let’s look at each of these values in turn.

To Get Individuals Interacting Effectively, You Need Flexible Processes and Tools

While it is important to use quality staff in your project, the process itself remains a first-class citizen. Or, to put it more accurately, the need for a process remains paramount. What does need to be avoided is the canonization of a particular process as being “THE way we shall all adhere to rigidly” (as in, “These steps shall be followed precisely without exception,” “These documentation templates shall be used,” etc.). The process needs to be flexible; if the process isn’t optimal, then the people need to be able to fix it.

Equally, the tools you use to analyze and create new software need to be flexible enough to let you do the job without getting in your way. This doesn’t detract from their importance, however: without tools (including compilers, text editors—hey, even computers!), the project could take a very long time to finish.

The flip side to this is when a team insists on using a particular tool (e.g., the manager’s favorite programming language), even when it’s obviously not well suited to the task at hand. Recognizing the importance of tools in development doesn’t mean latching onto the “official corporate toolkit” or “company-standard super-expensive CASE tool” and stipulating its use—quite the opposite. If we recognize the importance of tools, then it’s obvious that the team must be given the flexibility to choose the right tools, every time.

To Communicate Unambiguously, You Need Minimal but Sufficient Documentation

Documentation is a communication tool to help keep everyone on the team on the same page. Object models (a type of documentation) are an important method of getting from analysis to design. “Just go read the code” really isn’t the best we can do.

As we discuss elsewhere in this book, effective documentation needs to be minimal yet sufficient, and we need to recognize which documents should be kept up to date and which ones have served their purpose and can therefore be discarded. Sometimes, a picture is worth 1,000 lines of code (and usually the picture is easier to read than 1,000 lines of code).

To Gain Customer Collaboration, You Need to Negotiate a Contract First

A contract (even one in the form of a verbal agreement or understanding) is important, because without one there is no project. The contract is the sealed negotiation between you and the customer—the agreement that states what will be delivered, by when, and how much it will cost, and it even can specify quality issues such as how many defects are acceptable. Depending on the type of contract, each of these items may be flexible, but the contract will (or should) state this.

Without thrashing out the issues just mentioned with the customer first (even if the contract just says, to sum up, “We agree to be flexible”), the project risks starting out on a shaky foundation.

To Know When to Change and to Recognize That You Are Changing, You Need a Plan

The project plan (whatever form it takes) is important because without it, no one knows how much progress has been made or what they’re supposed to do next, and the management (or customer) may get the jitters, so again, no project!

Most important, we need to be able to change the plan if it doesn’t reflect the current reality. This doesn’t lessen its importance in the slightest, however; it simply means that the plan has a different purpose from what some people might think. (We discuss plan-driven versus planning-driven projects in Chapter 9.)

The plan should also be visible to everybody and revisited frequently, although the original baseline should also be kept visible, so that by frequently adjusting the plan, we’re not fooling anyone (including ourselves) that we’re still “on track” if the schedule keeps getting pushed out every month.

Boiling Down the Values to Their Essence

As refactoring is the practice of simplifying things (granted, it’s usually applied to source code), we could further refactor the agile values until we are left with the following distilled version:

Neither people over process nor process over people, but people and process and pragmatism.

It might seem as though we’re nitpicking an obviously generic manifesto, but these issues have broad ramifications for the process that you choose for your own projects and the level to which you tailor it. For example, launching into designing and coding without doing in-depth requirements exploration up front might seem like a good idea because your programmers are highly skilled and can drive the design, as they code, to whatever the requirements turn out to be. This is an incredibly inefficient way of doing things, though. There has to be a better way …

Giving the Customers What They Want

To explore the requirements in depth and have a better chance of giving the customer something he can use (and getting the requirements right early in the project), you’ll need a process that does the following. The techniques for eliciting the in-depth requirements might vary, but the basis is simply the following:^[12.]

• Run away from any technology; assume no solution. Focus on the problem domain. Describe everything in terms of user experience—for example, “A day in the life of …” (In other words, do some storyboarding and write as many valid use cases as you and the project stakeholders can think of.)

• Make sure the proposed solution is a good fit with both the user needs and the business needs (ROI). They may well be different. You have many masters.

• Describe everything you can imagine (within reason, of course—don’t take this wording too literally) in detail. Do not attempt to produce production code yet. This takes discipline. (Prototypes are different, of course. Effective prototyping helps to elicit further, better, and more accurate requirements from the customer and users.)

• Once you have wrung the towel dry (i.e., you can get no more information from the customer and users, and the described scenarios are widely accepted as being a realistic and accurate portrayal of what needs to be done and what is desired to be done), then you can start designing and coding.

The basic principle is to take aim—very good aim—and then fire in a straight line, like firing an arrow straight to a target.

Note 

But will the target still be in the same place by the time the arrow gets there? The essence of agility is to account for the possibility that the target might move. A good way to account for this is to release in smaller increments (1–3 months, as we discuss in Chapter 9). In other words, fire the arrow over short distances. Standing close to your target increases your chances of a bull’s-eye every time.

This is the best way to be agile: develop your software quickly and reliably. Reducing development time is like a boxer presenting a smaller target to his opponent: it reduces your project’s exposure to the forces of change.

Is it really possible to take such an approach and still fulfill your agile goals? It is, because spending sufficient time up front is an investment. It reduces the amount of time you will need to rewrite code later on.

As previously suggested, the behavior requirements can be defined using use cases (and there are detailed guidelines for doing so that work reliably). Since we can do this, we’d be dumb not to. We can still use short iterations, small increments, aggressive unit testing, automated acceptance testing, and so on (i.e., we can leverage many agile techniques).

It’s worth emphasizing this point:

Well-defined and reliable guidelines exist for doing use case–driven development.

(Originally Jacobson’s Object-Oriented Software Engineering [OOSE],^[13.] this is now refined as ICONIX Process.)

The existence of these well-defined guidelines means that jumping prematurely to code isn’t a very good idea, because you lose the benefits associated with following them.

Refactored Manifesto Summary

To recap our “refactored” agile values

• The process is as important as the individuals. The individuals create the product, but the process helps the individuals to keep themselves out of mischief along the way.

• Having just enough documentation is as important as having working software. The software is the finished product, but documentation enables communication within your team and thus helps to get you there. In addition, it lets you check whether you reached the place you really meant to. The documentation also enables the next stage of the project, the all-important maintenance phase (i.e., the next round of functionality).

• Contract negotiation is as important as customer collaboration. The customer is king, but without the contract you won’t have a customer.

• Following a plan is as important as responding to change. Effective planning manages change and keeps chaos under control.

CHANGE IS GOOD, BUT IT’S ALSO EXPENSIVE

Imagine that you’re painting a house white and, after a week of intensive brushing, you’ve reached the final wall. Nearly there … but then the customer suddenly changes her mind and wants the house to be a nice shade of blue. It would, of course, be pointless to continue and finish painting the current wall white—it’s best to switch to blue as soon as possible. The longer you wait, the more costly and pointless it is for the customer.

But however quickly you switch to the new requirement, it’s going to be expensive for the customer, because pretty much the entire house will need to be redone. So the overall project will end up costing nearly twice as much as originally anticipated. (Note that not all requirements changes are created equal; the problem is worse if you start with dark blue and decide to switch to white, as you’ll need an extra coat of primer.)

Software agility can help to reduce the costs of switching, but it can’t recoup the costs that have already been spent on developing to the old requirements. This is why, even in an agile world, it’s as essential as ever to do our utmost to get the requirements right, as early as possible. This means asking the customer hard questions (which she probably won’t like), interviewing users, and so on.

^[11.]See www.agilemanifesto.org.

^[12.]Thanks to Dino Fancellu of www.javelinsoft.com for this list.

^[13.]Ivar Jacobson, Object-Oriented Software Engineering: A Use Case Driven Approach (New York: Addison-Wesley, 1992).