If the Shoe Doesn't Fit

To the uninitiated, Agile software methods make radical recommendations for gathering and documenting functional requirements. For example, in Extreme Programming (XP) we replace up-front requirements analysis with incremental requirements definition, replace document-based communication with face-to-face communication between developers and subject matter experts (SMEs), and record requirements as automated functional tests.

This is not a fairy tale: The resulting requirements process is both efficient and effective. Communication is direct, clear, unambiguous, and verifiable. The "catch" is that this approach has the best chance of succeeding when the project meets all of the following critical success factors:

• A team is small enough to fit within a collocated space—ideally less than ten people but no more than twenty.
• SMEs are a permanent part of the team.
• SMEs have a clear vision for the system requirements and can effectively communicate this to developers.
• SMEs can express the requirements in the form of functional tests.
• Either the problem domain has a short learning curve or the developers have deep experience in a more complex domain.

A project that fits these criteria perfectly—like Cinderella fit into the glass slipper—is an ideal candidate for this Agile requirements process. However, not all projects are Cinderella projects. What if your team is large? What if there are language barriers? What if the SMEs have tunnel vision and don't understand the big picture? What if the physical office space cannot be reconfigured? What if the developers are new to a complex or critical domain? What should you do with these stepsister projects? It's important to have an answer because stepsister projects are far more common than Cinderella projects.

If the Shoe Doesn't Fit...
Act 1, Scene 1: A team of ten skilled developers is brought together to work on Bravo, a mission critical application for a complex business domain. This is the first time the team members have worked together, and none of them has worked in this domain or on a previous Agile project. Although a highly qualified SME is assigned to the project full time, this is her first involvement with a software development project and she lacks a clear vision of the end product.

Enter an Agile expert to conduct a readiness assessment for Bravo to determine if it is a good candidate for a particular Agile requirements process. It is readily apparent that the glass slipper does not fit. At this point the expert can lead Bravo down one of three alternative story lines.

The naïve expert story line continues with the expert guiding the Bravo team through the Agile requirements process even though it is a stepsister project. Risk is added to the project because this requirements process is too light for the project factors.

The purist expert story line continues with the expert walking away, insisting the Bravo team is not worthy of using an Agile requirements process. The team adopts a more familiar heavyweight, upfront requirements process instead. Waste is added to the project because this requirements process is too rigid and bulky for the project factors.

The pragmatic expert story line continues with the expert suggesting that if a particular glass slipper does not fit, the Bravo team can mold an Agile requirements process to fit its unique project footprint. The requirements process is as efficient and effective as possible, given the circumstances.

This article explores the pragmatic story line in more depth and offers thinking tools for understanding the distinctive characteristics of a project and strategies for shaping an Agile requirements process that is a snug fit. Our target is to minimize the effort in specifying requirements without introducing risk or