What Makes a Project Agile?

A variety of practices, principles, values, and other factors go into making a project agile. In this section, we describe the more important ones (we also sum up these practices as a “top 10” list at the end of this chapter).

Tuning the Process As You Go Along

A doomed project is one that fails to adapt its development process as it goes along. If a particular practice obviously isn’t working, it should be replaced with a practice that does work for your team.

Keeping It Low Ceremony

Keeping a process low ceremony is the art of producing just enough documentation to proceed, and having just enough process hoops to jump through to provide some structure and coordination, without slowing down the team. For example, if a team is unable to start programming because another 100 pages of design documentation need to be written (using the extensive company template with 12 pages of “front matter,” of course), then that would classify as a high-ceremony project.

ICONIX Process aims to keep the project low ceremony, by identifying a minimum set of UML diagrams that can be produced to get reliably from use cases to code with as few hoops to jump through as possible.

Enhancing Agility Through Good Design

If sufficient time is spent on getting the architecture and design right near the start of the project, then it becomes a lot easier to extend and modify the design later on (when changes are traditionally more expensive).

As we describe later in this chapter, Robert C. Martin identifies the need for continuous care—that is, constant attention to the design and the state of the source code. If the design begins to fray at the edges (e.g., because some functionality is being added that the design wasn’t originally intended to cope with), then time needs to be spent readjusting the design and tidying up the code through refactoring. The alternative—just shoehorning the new functionality in (also known as hacking)—means that the problem never goes away, and over time it just gets worse.

However, a vital extra component can also help to keep the design extensible: time spent on up-front design. Contrary to popular belief, designing for change doesn’t mean adding layers of indirection to your code. Unless there’s a really good reason for it, this sort of design ultimately just produces more code, making it more difficult to modify later.

Instead, designing for change (also known as defensive programming) means following sound, object-oriented (OO) design principles, the following in particular:

• Keep the code in a highly modular state. Make sure each class has just one responsibility, and that it handles that responsibility well. Also, make sure each method performs just one task (e.g., by delegating to other methods).

• Keep your classes highly cohesive and loosely coupled. Make sure everything in each class fits well and is there to fulfill the reason for the class’s existence. Try to reduce the number of dependencies between classes.

• Don’t overcomment your code. Any code that you have control over should be made self-explanatory (see the next point), reducing the need for comments. The exception is with calls to library code that you have no control over; often, some deftly placed comments can help a lot here.

• Use method names that describe the method’s purpose, not how the method achieves that purpose. For example, instead of calling a method addToList(String str), call it addToCatalog(String productID).

• Use class names that are closer to the problem domain than the implementation details. We’ll explore this in more detail when we talk about domain models in Chapter 3.

• Don’t overcommit. That is, don’t use a concrete type where a more abstract type would suffice. For example, if you’ve declared a return type as a java.util.ArrayList, you might find it’s better to declare the return type as a Collection interface instead. And speaking of interfaces…

• Use interfaces as return types and parameter types wherever possible.

Improving Communication and Teamwork

One of the most important factors separating agile development methods from traditional development methods is the focus on people. For example, Agile Modeling promotes communication and teamwork through the following practices:

• Active stakeholder participation

• Modeling with others

• Displaying models publicly

• Collective ownership

You build systems for your stakeholders. It is their requirements that you need to fulfill, they are the source of critical information, and they need to make important decisions such as the setting of priorities. For iterative and incremental development to succeed, your stakeholders must be available to provide information, to work with you to explore their requirements, and to make decisions in a timely manner. In other words, your stakeholders must be actively involved with your project.

Software development is a lot like swimming: it is very dangerous to do it alone. Whenever you work on something by yourself, you risk going in an inappropriate direction and not realizing you’re doing so. Furthermore, you risk making a common mistake due to lack of experience with or knowledge of a technique or technology. This is why it’s so important for design work to be collaborative: by modeling with one or more people, the quality of your work is likely to be much greater, you’re likely to get the job done faster, and the information gained during the modeling effort is communicated to everyone involved.

BUT WHAT ABOUT RESPECTING YOUR CO-WORKERS?

Agile processes do place a greater emphasis on the people factor, but it’s debatable whether this is intrinsically what makes a project agile. Respecting your co-workers is equally important on nonagile projects, for example. If people feel valued, they’ll be more productive, and more willing to participate and contribute actively to the project.

Reducing Exposure to the Forces of Change

The premise behind this idea is simple: making changes halfway through an iteration is expensive and can cause bugs as the new requirements get shoehorned into an unsuspecting design. So to reduce the likelihood of requirements being introduced halfway through an iteration, keep the iterations short. This is like a boxer creating a smaller target by turning side-on to his opponent.

We can also reduce the likelihood of requirements changing at the most inopportune moment by getting from use cases to code in as short a time frame as possible. We do this by spending a little extra time focusing on the requirements and the design modeling (when a change in the requirements is welcomed), so that we cut a straight line to the source code, developing short iterations in short spaces of time.

Measuring Progress with Working Software

If working software has been delivered to the customer, then we know we’ve made at least some progress (even delivering a small amount of working functionality to the customer is a lot further than some projects get). Working software can also be used to measure (in precise terms) how near to completion the project is (see Chapter 9 for more on agile planning).

But how do we know that the software is working? “Working” doesn’t just mean “doesn’t crash”; it means that the software matches up with the customer’s requirements—that is, it does what it’s meant to do. Testing the software against the requirements (often referred to as customer acceptance testing or functional testing) is generally how we verify that the software works.

During analysis and design, you should constantly ask yourself, “How am I going to test this?” If you can’t test something, then you should seriously consider whether you should be building it. Considering testability while modeling is important because it keeps the team focused on realistic designs. Furthermore, it gives the team a head start on writing the test cases, as some thought has already been put into them. Model reviews, described in Chapter 3, are also a good option for validating both the requirements and the design.

Agile Project Management

As with improving communication and teamwork, the people factor plays a large part in agile project management. In many ways, this is no different from the “traditional” project management role: it’s about managing groups of people and keeping them at their optimum efficiency without burning them out.

In practical terms, this might simply involve seating people near appropriate colleagues so that they’re more inclined to communicate well, moving individuals across teams so that the correct skill sets are applied to individual problems, and so on.

Agile Planning

The very term “agile planning” might strike some people as oxymoronic. How can you create a plan for something that by its very nature keeps changing? In fact, the more volatile a project’s requirements, the more agile planning is needed.

Agile planning operates at two levels:

• Adaptive planning: This involves planning ahead, tracking changes, and adapting the plan as the project progresses. Predictive planning, on the other hand, involves making predictions such as “On June 14, we’ll start doing module A, and it will take 4 days for Eric to write it.” Adaptive planning stands in stark contrast to predictive planning, because adaptive planning involves synchronizing the plan with reality as we go along.^[5.]

• Planning for agility: This entails preparing for the unknown so that when changes take place, their impact is kept to a minimum. Agile planning is a way of anticipating and controlling change.

Typically, agile planning consists of various practices, including performing short, fixed-length iterations (usually of 1 to 2 weeks); regularly reviewing the project plan; time boxing (i.e., specifying a fixed amount of time in which to deliver a variable amount of functionality); and tracking velocity (i.e., the rate at which new working software is being delivered).

Managing Change

While some agile methodologies tell us to “embrace change,” we prefer to see change as something that should be actively managed—controlled, even. This doesn’t mean discouraging change (that wouldn’t be very agile, after all), but instead keeping a pragmatic focus on the costs involved in making a change to the requirements at a late stage in the project.

If the customer is made aware that change isn’t free, and that the cost to fix a requirements defect increases exponentially the longer it’s left, she might prefer to take the hit and leave a requirement as is, at least until the next release. For the customer to make an objective decision, she needs accurate planning data, including cost estimates. So a big part of managing change is tracking project velocity (see Chapter 9).

Delivering the System That the Customer Wants at the End of the Project, Not What He Thought He Wanted at the Start

This goal is probably the most intrinsically agile of the agile factors listed here. The customer might, in all good faith, specify a set of requirements at the start of the project, believing them to be correct. During the project, however, things change. The business changes, causing the goalposts to shift; our understanding (and the customer’s understanding) of the problem domain grows; our understanding of the required solution increases; and the design evolves, meaning a better solution is sometimes found.

Agility is all about recognizing that these things happen in just about every software project and, rather than trying to suppress them (e.g., by “freezing” requirements with another 8 months to go before the deadline), we use change to our advantage to drive the project toward the working system that is the most optimal for the user’s needs.

We can use a variety of practices to achieve this goal. In fact, pretty much all of the agile practices contribute to this goal in some way.

^[5.]See Martin Fowler’s paper “The New Methodology” at www.thoughtworks.com/us/library/newMethodology.pdf.