I like to think I’m agile. Most of the time I’m working as an analyst on projects, split between business and system analysis tasks. I talk with the business experts and help them define their requirements from requests to change or add new behaviour to adapt to business needs. In an ideal agile world I’d be redundant, as the business would have resource to allocate experts to work alongside developers in the project team. Fortunately for me and many other analysts the business are rarely flushed with enough experienced business experts and must rely on a go between to convey their message. I like to think I add value by removing any preconceived notions the business may have in specifying how they want the new functionality to work, by filtering their requirements and extracting what they want it to do. I might write a story that details a change to an operational report or define a new addition to the product set. I seek estimates from the developers and feed this back to the business for approval. As a go-between, I’m fulfilling a legitimate agile role.
But is there really a need for an agile analyst? Is the term an oxymoron? It’s a question often asked by companies starting out on the agile path. CEOs read agile books about empowerment and business sponsors and plough in with pilot projects that bring swift results. They attend seminars and see the productivity of pair programming. Six months or so after the heady kick-off meeting and countless show and tell sessions the business realise they have more work to do than automation can bring. Who’s going to handle the customer support lines? Who will send the white mail and respond to written enquiries? Just what does Sox mean to audit? Soon the full time business sponsor is part time or has little or no time to spare at all. We’ve seen it happen on several projects.
Beyond the consultant’s vocabulary of business process change and IT infrastructure lays the reality of an end-to-end process. In the haste to embrace agility the business may forget this. But I like to think the analyst never will. The agile analyst can fill the gap when the initial sponsor retreats or play the role of surrogate business expert when full time secondment was never an option. They may even re-badge themselves as product specialists.
I like to think the agile analyst brings a few more tools and techniques that the businesses sponsor or developer could rarely provide. As an analyst I can create models and unambiguous diagrams that slay endless business arguments. For example, a state diagram that clarify exactly in which circumstances we will accept a certain business event. Or I can create a data model that captures the legitimate rules for relating product to service. It’s true, once these business requirements are understood by the developers my effort if no longer required, I’ve fulfilled my role. But when significant changes are required later on the analyst can again help filter and convey requirements without bias of technical forethought.
