Potential for Agility

by Suzanne Robertson, Senior Consultant, Cutter Consortium

An agile requirements strategy is one where there is no wasted effort. All the effort you spend on requirements (meeting, interviewing, modeling, reviewing, prototyping, documenting, testing -- everything) brings you closer to being able to meet your project's goals. But not all projects have the same potential for agility. Large numbers of stakeholders, scattered development teams, varying levels of experience, and other factors that make it difficult to get answers and make decisions all influence your potential for agility. To help make your requirements strategy as agile as it can possibly be it is useful to consider the agility potential for your project.

Rabbit Projects

Rabbit projects, like their namesake, are small and fast. If your project has the characteristics of a rabbit, then you have the highest potential for agility. Rabbit projects typically occur where close stakeholder participation is possible. The developers and the domain experts are either physically located in the same place or have developed a way of working where distance does not impede the ability to share ideas and make decisions. Rabbit projects are iterative. They gather requirements in small units (typically one business use case at a time) and then implement the solution piece by piece, using the implementation to get feedback from the stakeholders. Rabbit projects are not focused on a process that delivers a requirements specification; instead, they have a process that discovers and communicates requirements one logical chunk at a time. Rabbit projects benefit from having a sketch of a requirements knowledge model on their whiteboard so that stakeholders have some consistent way of talking to each other. However, these projects will not produce formal deliverables for each one of the classes of knowledge. If these teams sketch a work context and come up with a list of business events, then they might choose to do business use case scenarios for the most complex ones and keep a list of naming conventions so that everyone can see them.

Rabbit projects benefit from paying attention to all the classes of requirements knowledge, but the amount of time and effort that the teams spend in representing the knowledge is minimized because they share their understanding by talking to each other.

Horse Projects

Horse projects have less potential for agility. They are larger than rabbit projects and hence more constrained by the size of the project and the organization. There is more need to have a formal process for representing classes of knowledge. Horse projects are the most common corporate projects. There is a need to formalize the documentation for some of the classes of requirements knowledge because it is likely that requirements must be handed from one department to another. Another factor is that these projects usually involve more than a few stakeholders, often in a number of locations.

Horse projects are working from the same knowledge model as rabbit projects, but they need a more formal process for how each of the classes of knowledge is discovered, who is responsible for it, and how it must be represented both in terms of notation and documents. This extra bureaucracy is necessary in order to exploit the potential for agility by making communication of understanding easier. But there is a trap here and that is that horse projects often start to work by rote and stop questioning whether a particular activity or deliverable is necessary in all cases. To keep a horse galloping, you need to keep questioning whether everything in the saddlebags is still necessary.

Elephant Projects

Elephant projects have the least potential for agility. These projects have a long duration and hence like elephants need a long memory. Sometimes they are so long that none of the people involved at the start of the project are still there at the end. They involve many stakeholders in many locations at many levels of authority and interest. Their technical infrastructure is diverse, and there are many developers involved. These projects often outsource part of their development, often to another country. Owing to this huge diversity, the elephant project has a need for a very formal and consistent representation of the requirements knowledge -- one that is not open to interpretation. That representation is normally in the form of a requirements specification document.

When elephant projects decide how to represent their requirements knowledge, the notation and format for how each class and relationship will be represented is often mandated by organizational or industry standards.

The truth is that even in the most extreme of elephant projects there is still potential for agility. You can exploit this potential if you have a consistent way of partitioning the elephant and keeping track of the connections between the pieces. Within the large project, you can discover a number of linked smaller projects, and some of these pieces -- especially the ones with colocated stakeholders -- can be more agile than others.

I welcome your comments on this issue of the Cutter Edge and encourage you to send your insights on the market in general to me at srobertson@cutter.com.

-- Suzanne Robertson, Senior Consultant, Cutter Consortium