In a post on Agile Requirements Modeling, Scott Ambler wrote:
"It is the responsibility of project stakeholders to provide, clarify, specify, and prioritize requirements. Furthermore, it is the right of project stakeholders that developers invest the time to identify and understand those requirements."
Agile helps motivate a development team with shared goals. But, how does the customer proxy (those in charge of ensuring softare meets customer and business needs) extend shared goals beyond the development team to stakeholders? I have seen many development teams invest but I see fewer customer proxies making a similar transformation in this area. The role of the customer proxy is to elicit requirements from stakeholders, integrate input from various sources, and seek endorsement of the aggregated view. It is their job to insure the business needs are coherent and directed, not divergent.
So how do they accomplish this? Writing user stories on index cards as "a placeholder for a future conversation" is great when the stakeholders can be asked for their input on demand. Unfortunately, the existence of a customer proxy generally indicates that stakeholders are not available in this way. Without help from the customer proxy, the development team may not even know who to involve in the conversation.
In the past, I have relied on the familiar tools of MS Office: Word, Excel, and Visio to help solve this challenge. Yet, even for a small set of stakeholders, a number of problems emerge from such a document-centric approach.
- Error prone: Manual or document-position identification schemes can cause confusion when changes are made by multiple people at the same time.
- Extensive manual effort: Inputs from stakeholders come in the form of document edits which are painful to merge.
- Divergent interactions: Inputs from stakeholders come at different times, often complicating the merge problem as some feedback is against outdated information.
As a result of these problems, the distribute-review-update-reply cycle for requirements can take weeks or even months to complete. This is where the Agile idea of enabling, not controlling, change starts to apply to requirements.
One solution is to have stakeholders practice "continuous integration" for requirements. That is to say, they commit comments or changes to requirements to one repository that automates the tedious aspects of change management. A requirements management repository, such as CaliberRM, can automatically identify every requirement uniquely, can protect users from confusion of parallel development of requirements, and can make sure all stakeholders are looking at the same set and versions of requirements. It enables a single point of access for edit cycles so everyone stays on the same page. This shifts my role from "doing" requirements management as if it were contract negotiation, to "supervising" requirements management as a collaboration among stakeholders. For me, this is working smarter, not harder. For my stakeholders, this increases visibility and transparancy.
A repository approach also scales better, enabling members of the development team to get involved earlier. Whenever possible, try to bring members of the development team to business discussions. This helps establish trust between the development team and customer proxy. As they see the complicated sea of changing requirements, they can appreciate the judgment of the customer proxy and understand why their ability to accept changing requirements is so valued. A requirements repository also keeps the development team in the loop when they cannot be available in-person. Developers can be notified when a requirement is ready for estimation and QA can be invited to participate in on-line discussions to ensure the testability of requirements.
A requirements repository can make a big difference in collaborating with remote stakeholders in order to keep them happy and engaged, even before software is delivered.