Apart from the Agile Manifesto, and independent of the selected Agile approach, some important questions remain. What makes a project Agile? Which characteristics are displayed in Agile projects that distinguish them from traditional projects?

Characteristics of Agile

In our view, Agile projects share the following characteristics:

Short iterations

An Agile project is divided into short iterations. During each iteration, a portion of the software is analyzed, designed, developed, tested, accepted, and delivered. The iteration is time-boxed (usually two to four weeks), and we may or may not get a complete product. For this reason, the iterations are repeated several times until the final product is achieved.

Collaborating in teams

People in different roles, like analysts, developers, and testers, don’t work sequentially, but with each other as a multidisciplinary teams fully delivering software, each and every iteration.

Small unit of work

A portion of the software is delivered during each iteration. This therefore requires a small unit of work. The units are often user stories, sometimes screens, and sometimes smart use cases or features. We prefer to use the term work items.

Projects aren’t built entirely at once in Agile. The project is partitioned into short increments (or work items) that can be developed in parallel. The integration comes in later.

Responding to change

Agile projects embrace changes. At the start of each iteration, work items are selected from the list of remaining work items based on their priority at that moment in time. During the project, new work items are simply added to this list and in principle could be realized in the next iteration.

Note that the new work item may not be included, even in the next iteration. This all depends on the priorities and tasks. We’ll discuss the implementation of work items in the next iteration later.

Ongoing planning and measurement

Realizing work items in short iterations makes it possible to continuously measure and plan. That way, there’s still time to respond to scope, method, or team changes.

We may also feel after an iteration or two that the work done is no longer needed and can be simply discarded. Because the iterations are usually short, a lot of work and effort is usually not wasted.

Early and continuous testing

The sooner a project starts testing, the less effort is needed to correct errors. Because iterations deliver work item by work item, testing can start really early in the project.

Early testing reduces the risk of failure of the project later in its lifecycle. What could be riskier than postponing all testing until all development is completed? Many projects following the Waterfall approach failed because of late testing. It was determined too late that the architecture was flawed, or the components couldn’t be integrated.

By practicing continued testing in Agile development, we can easily avoid these pitfalls early on.

Early and frequent delivery

During each iteration, all activities that are necessary for the work items to be delivered are performed. The realized work items are immediately delivered, sometimes even deployed into production. That way, all infrastructural hurdles are also cleared at an early stage.

Because of early delivery, the client can see something tangible early. They can see if what they had in mind is actually what they need. In the traditional Waterfall process model, because a working product is delivered very late, it may happen that the end product isn’t what the client actually wanted, resulting in a project failure.

Simplified communication

Although it’s not mandatory, Agile projects use the simplest possible communication tools. Think of sticky notes with work items on the wall, or a simple spreadsheet with a list of all work items, for example.

Good communication is vital to project success. If communication isn’t clear to all team members, it can lead to a disastrous product, wasting everyone’s time and effort.

Co-location

Co-location argues that it’s best for teams to work in one location, preferably along with the customer and the users of the software. This makes communication quick and easy and is an asset to any project. Unfortunately, co-location isn’t always possible. For example, teams can be geographically distributed.

In conclusion these are the characteristics that make a project agile in our opinion. That’s not to say that we consider projects that don’t meet all these characteristics to be wrong, or even non-agile. It’s immaterial whether a project is truly agile, or only partially so. What’s important is that each project is performed optimally. Sometimes that’s very agile, sometimes a little less so.