Two words for Agile Business Analysts: Pan and Zoom

Do you have trouble wrapping your arms around the question "what do Agile Business Analysts do?"  I figured it out today!  And I will tell you!  And as a special bonus, I figured out what the Waterfall BAs do too--so if you didn't know, and you were worried--and who among us isn't--you can kill both birds with one blog.

Business analysts of every ilk do two things really well:

• They look at the big picture end-to-end.  They are able to describe concisely what your project is doing and why.  They are czars and czarinas of the "elevator pitch."  They see it all, and they make sure everyone else on the team sees it too.
• They look at every detail of your project pixel by pixel.  Who is the person in the room most likely to say: "wow, paragraph 4, sub-element 2 totally contradicts that chart on page 3 in the leftmost column."  The BA, that's who.  They are razor sharp.  They are intolerant of errors.  Any errors.  A BA is probably reading this saying "'any errors' isn't a complete sentence, Elena."

In other words, they "pan" and they "zoom."  The best BAs are unlike most other people in their ability to do both of these things really well.  So let's look at the difference between Agile BAs and Waterfall BAs.

From http://chocolatecamera.blogspot.com/2011_07_01_archive.html

Agile BA:  Mostly pan then mostly zoom.  A business analyst in an agile project separates panning from zooming, for the most part. 

During the project startup, the Agile BA keeps the team in "Pan" mode, even when they don't like it:

• The agile BA works with business subject matter experts to diagram a complete end-to-end story map describing the new software system to be built, in words an executive could understand.  Three features with accompanying profit and loss.  That type of thing.
• The agile BA enforces the discipline of considering system features holistically, and they get the team to determe what the minimum features need to be for the first software release.  And then they make the team let go of those other features for now--we wrote them down.  We'll get to them later, but now we need to focus.
• The agile BA does the hardest thing of all in a project inception phase:  they break those big features down into smaller pieces without going into detail.  What kind of heroes are these, who can divide some big data loading widget into 45 smaller parts and never once allow the team to descend into a discussion around a naming convention?  Agile BAs, that's who.

Once the project has moved into the familiar pattern of delivery iterations, the BA ensures that zooming occurs.  Lots and lots of detailed zooming:

• The agile BA ensures rigor around the way the requirements are expressed, even on teams with a single Product Owner who sits with the team.  The BA champions a standard format for capturing needed information, whether it is verbal or written.  Yes, even on a team that is collocated, where very little needs to be written down, someone needs to understand the details.  On a team of more than four people, one person may specialize in knowing the details, and that person will be your BA.
• On more complex projects, the agile BA may need to convene meetings with widely dispersed subject matter experts, get those people to focus, and record their decisions, still in a standard format.
• On really challenging agile projects where SMEs are dispersed and team members are even more dispersed, and all five continents are represented, the agile BA will maintain a coherent written set of documentation and a network of local experts to help everyone navigate through it.  And every detail will be right.

In the mean time, of course, the agile BA has not lost sight of the big picture, and typically leads discussions during "Backlog Grooming" meetings during each sprint, to ensure the big picture is kept up to date as the team learns things.  There's still a little "panning" that must go on, and the agile BA is flexible enough to be able to do this, even while focusing on details.

Waterfall BA:  Pan and zoom all at once.  Once you understand how an agile BA functions, it's hard to understand how waterfall BAs manage to do what they do.  Waterfall BAs are asked to both pan and zoom at the same time.

• During the early phases of a Waterfall project, the Business Analyst is asked to write a virtual novel.  Every chapter must be there, and each chapter must be complete and perfect, down to the punctuation.
• During the Waterfall "development" phase, where the software is actually being written, the BAs are asked to participate in a process called "Change Management" in which they are required to locate and fix things in their large-scale requirements document as the business changes its mind, and the developers run out of time.  In fact, at the end of each Waterfall release, everyone runs out of time, and the software will never quite match the requirements.  There just isn't enough time.

The truth is that ONLY a waterfall BA can fully understand the documents they write, because these documents are long and detailed, and people on the team who specialize in development or testing don't have time to make sense of a huge binder full of text, even if it's online.   And only a waterfall BA could bear the drudgery of revising their encyclopedia of requirements over and over again, every time something changes.  Waterfall BAs are heroes too, and what they do is really hard.  But we shouldn't ask them to do it in the first place.

As a member of the Business Analysis community, I need to end by saying that the "pan" and "zoom" analogy suggests that BAs are nothing more than "order takers" who somewhat mechanically record the world around them.  I hope the details above make it obvious that nothing could be farther from the truth.  Equating a good BA with a camera, because both can pan and zoom, is as silly as saying that chewing gum is equivalent to Crème brûlée, because both of them make snapping sounds.