Requirements Analysis, Humbled
I was listening to a great interview today featuring Suzanne and James Robertson of the Atlantic Systems Guild where they discuss “big ‘A’ Agile” versus “little ‘a’ agile”. That is, how stepping back from the (ironically*, rigid) processes of the central Agile methodologies (Kanban, Crystal, etc.) we can take away just the good bits, the key lessons, which agile thinking has taught.
It prompted the following thoughts about requirements analysis.
Requirements Analysis is Not Dead
Agile isn’t supposed to throw RA out the window. When the Agile guys say “we value responding to change over following a plan” they don’t mean “have no plan”, they just mean it’s better to be able to respond to change.
Development with agile-like methods can in fact lower the barrier to entry on requirements gathering.
How agile can help you with RA
Agility-based development produces artefacts: User stories on index cards and post-its, whiteboard drawings from stand up meetings, lab book notes, annotated documents, and more. Your team is already procuding these physical things as part of their job. Digitally, project information is being poured into your bugtracker (such as JIRA), your chat channel (Slack), your CI/CD (Jenkins) and your company wiki.
All artefacts are permissible forms of requirements gathering
For the physical items; we all have cameras all the time, so why not make easy digital copies of every little artefact and store them somewhere?
Why not take the originals and stick them up on a (sufficiently large) wall in the group space?
Communicating to clients
“Ah yes, but you can’t give a scrapbook of photos and user stories to a client in a big folio labelled ‘Requirements’” – true.
Translation is necessary when a stakeholder will not be able to understand the original format. If you need a contract-style set of requirements, then that can be translated from what your team has gathered. Nonetheless, the gathering has actually already happened. And it was less painful because it was part of their everyday processes.
Humbled
I’m calling this “Requirements Analysis, Humbled” because we demote the requirements to being a consequence of our workday and thought processes. The requirements are no longer enthroned by the devotion of specific time and effort. They no longer inhabit perfect 30-page white paper documents (necessarily) but can be pulled together from the everyday scraps of analysis and engineering work which your team is subconciously carrying out.
Advantages
The easier it is to gather requirements, the earlier you’ll do it, and early RA means:
- You clarify stakeholder goals
- You have longer to get it right
- You can prioritise goals sooner
Discussion: @stegriff and ste@stegriff co uk
* Ironic because Agile advocates “Individuals and interactions over processes and tools” and yet these highly codified, consultant-endorsed processes are recently very popular ways of “doing Agile”.