Business Analysis and Agile

I've worked on Agile projects now for about the last five years, on and off. And it's fair to say those projects have met with varying levels of success. The reason being, I think, because as with anything there is the theory, the principles and logical constructs that look great on paper, and then there's the reality of business environments and project resources and complexities that live down in the details of your deliverable. I've said it before, and I stand by it, that a good Business Analyst, any IT professional really, needs to be flexible and to be able to apply knowledge, to cater it and tailor it to best meet the problem at hand. The textbook is there for reference, not daily planning.

In principle, Agile may tell you that my job as a Business Analyst is actually redundant. There are plenty of Agile practitioners out there that follow this to the letter. And while I'm not going to debate that too much - it's not for me to challenge someone else's interpretation of the methodology - I am going to give some examples from experience where I've seen that in action, and how badly wrong it seems to have gone in each instance. I'm sure there are times where that has worked like a dream, it's just that I haven't seen any. To my mind, the theory is not necessarily wrong. If you're working on a relatively small and contained deliverable, which has a very clear stakeholder, and that stakeholder can transition to be your Product Owner, and that Product Owner is incredibly knowledgeable about what they want and how they want it, then I can see that may well be a resounding success. One question though: how many projects have you worked on lately that are like that? Given the increasing complexity of IT strategy and architecture that incorporates component integrations, outsourcing and offshore development, solutions that run in parallel with other projects and programmes generating tons and tons of dependencies, these simple and self-contained deliverables are becoming more and more rare.

Failures

Example one: a six week project than ran for over nine months. It was already six months in when I landed on it. I went along to standup, I looked at the board, I couldn't make head nor tail of the tickets on there. They were all low level development tasks, usually described by a single sentence in technical language. None of them seemed to relate to each other. None of them were linked to a story which might explain what the task was supposed to achieve. The consequences of that were many: the Product Owner and Delivery Manager struggled to see what was going on, and what for; the Testers didn't know where to start with looking for success criteria for their test cases; the Developers were working in silos on their own bits of whatever the overall solution was, all doing it differently, not following any real standards, with conflicts arising between different pieces of code all over the place. It was a bit of a nightmare. But all of these working practices paled into insignificance compared to the fundamental problem: we were trying to deliver a marketing report drawn from a lot of different data sources to a third party vendor. A representative from that vendor should, in theory, have been the Product Owner. Nobody on the team had ever spoken to them. The requirements were being channeled via the in-house marketing guys, but they didn't really understand what we needed to deliver either, and none of them were made the Product Owner. Our Product Owner was someone else entirely. So how exactly is that supposed to work then?

What I found, because the main principle of Agile that everyone does seem to latch onto, even when ignoring all the others, was that we'd just 'made a start with what we knew'. And what we knew was but a small percentage of the things that we really needed to know. We'd lined up the sources we thought we needed, all of them assumed to a certain extent. In some of them there were gaps because of fundamental misunderstandings. Some of them we had spent an awful lot of time on sorting out unnecessary elements that weren't even needed to meet the deliverable. The biggest gaping chasm of all was what we were supposed to do with the data once we'd gathered it? How did it map to the set of attributes in the required report? What were the aggregations we required, the calculations, the transformations? Nobody knew, and I spent a good three months under pressure, with developers throwing blocked tickets at me daily, trying to untangle the mess we were in. My point is, they had started without a Business Analyst, who needs a Business Analyst, and then a Business Analyst had to fix it.

Example two: a failed transformation programme. The company I was at were trying to replatform their core business with a product being marketed by a third party. This third party was in the same line of business and had been successful out in Europe so was now selling its own platform to other people. They worked with an Agile model internally, and had lots of Product Owners who had contributed to its development for their own trading purposes. They had no Business Analysts. Up until that point, they hadn't seemed to need them. But no Business Analysts meant no analytical capability. No analytical capability meant no capacity for gap analysis. You try working through how to make a third party platform align to your business model when the people you are speaking to can't grasp why your business model might be different to theirs, or how what they've been working on for the past five years could be, or would even need to be, any different than the functions that match their own day job. They understood their jobs. They understood the requirements that would need to be satisfied to make their jobs easier. They had no skillset for understanding anybody else's job and the requirements that may need to be satisfied for them.

The programme failed because of spiraling costs that all emanated from the same source: the assumption that two companies, doing the same sort of thing albeit in two different markets, would be able to work from the same system. As it became clearer and clearer that they couldn't, the cost of change mounted to an unsustainable level. Not to ram the point home any further than I need to, but that kind of feasibility work, the due diligence of understanding operating models and key differences between them, is kind of what a Business Analyst does, is it not?

The Agile Business Analyst

Down the years I've worked with a lot of different methodologies and the thing I found really early on is that none of them fundamentally change what you do as a Business Analyst. Agile is one of the better methods I think, personally, but the methodical and logical approaches I take to elicit and then validate and document requirements is pretty much the same under this approach as it has been under any other. Analysis is analysis is analysis. If you're looking to transition to it as a way of working, then my advice is to be aware of just three minor things, and then everything else will fall into place:

Documentation

You've probably spent most of your career writing requirements specifications - business requirements, maybe functional requirements, requirements catalogues, traceability matrices etc. etc. All of that goes away under Agile. And it's incredibly liberating once you get used to it. You write each requirement as a ticket on your board of choice - Jira, Mingle, Trello, whatever. The ticket has a story which conforms to a standard, "As a..., I want to..., So that...". That way you capture the Actor/Stakeholder, the main requirement, and the reason for doing it. Underneath that you add Acceptance Criteria, each one a declarative statement that must be deemed to be true when the code has been delivered. It's simple, it's logical, it gets everything a developer and tester needs down nice and neatly. Anyone else can then create tickets for specific tasks they need to do to support your requirement, but they do this in a hierarchy underneath your story, or linked to your story.

Of course, sometimes requirements need more detail than this, but that's fine. You can document these in a Wiki page - I usually use Confluence - and provide the link to the page in the ticket so the devs and testers can navigate there for further information or context. On my last project, I created a lot of Wiki pages, starting with a scope definition and project description, a few diagrams because everyone loves diagrams, then subsequent pages containing specifics around data mappings and complex calculations that were tied back to Jira tickets. I might have, for example, a piece of Acceptance Criteria that says "all fields are drawn from the exact database sources outlined here in Confluence"...

Timing

When writing those specifications I mentioned above, you will have undoubtedly been doing that as one big exercise - getting together the requirements for the whole project up front. Under Agile you don't need to do that. You start with an overview and then pick out only the things that need immediate attention to drill down into for now. You can get those tickets up on the board, get the devs working on them, and then go off and pick up the next couple of things that need your attention. If you do it right, you should be able to stagger your analysis which gives you more time, actually, to do it than you would otherwise get under waterfall. And you'll be contributing to a more efficient throughput of work for the whole team.

In Public View

This is often the hardest one for Business Analysts to live with, but you need to accept that you're working under Agile in a nice big glass box. Everyone will be able to see your requirements as you do them. A lot of BAs I know don't like Agile for this very reason. They like to get all their ducks in a row before they present them to anyone else. And I get that. There is always some developer somewhere who will look at a ticket that you haven't finished with yet and start grumbling that it doesn't give him what he needs. But that's the nature of the beast. You're perfectly entitled to tell that developer that the code he is currently working on doesn't yet give the stakeholder what they need. Of course it doesn't, it's not finished yet! The whole point of Agile is collaborative working, the agility to be doing things just in time for the next person in the delivery chain, the flexibility for requirements to firm up at the last second. You have to accept that your methods will be on show, but if you can do that, then that's more than half the battle.

Structure

This is the last thing I'm going to say about it, but just because Agile allows you to be more fluid about how you do things doesn't mean you can dispense with structure altogether. There is a reason why all Agile ticketing systems support the concepts of Epics, Stories, Tasks and Subtasks. That's because different people in the team need detail at different levels in order to do their jobs properly. My rule of thumb is this:

• Each deliverable has a set of Epics so management types can see how its all broken down
• Each Story is associated to one of those Epics
• Every Story has a User Story and Acceptance Criteria as described above, to help developers and testers
• Every Task is associated to an Epic and linked to a Story
• A Task can be written by anyone and doesn't need a Story or A/C, but should have a clear description of what it is supposed to achieve
• Every Subtask is created underneath either a Task or a Story. This can have whatever information a developer deems is helpful in it, it doesn't need to make sense to anyone other than him. But because it rolls upwards, it's clear to see what it's supporting and what it's helping to deliver

If you create a hierarchy in this way, then you are able to view the project from top to bottom, from bottom to top, from any direction you choose. It's all joined up and it all makes sense, to anybody. You can create proper burnup or burndown charts from it, you can have sensible discussions about it at standup, you can manage it and navigate through it and work on it with the minimal amount of confusion.

It's tempting in some ways to think of Agile as a buzzword (and, let's be honest, it is). It's tempting to think of it as the latest fad that will likely go away at some point. But it has been around for a while now and is being adopted by more and more companies all the time. The future looks to be Agile, or certainly some evolution of its current form. But be sensible about it - just do what you already do, but adjust it slightly to fit the approach, and everything will be just fine. Trust your instincts as an analyst, you'll know when it's working right.