Skip to main content

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.

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.


Popular posts from this blog

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else.

Here's what you should think about:

1.Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that:
a.You need your user experience people (if applicable) and your analysts at the beginning of the project, as always, b…

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…

How To Write A One-Page Proposal to an Executive

One day you may need to communicate with an executive. Pro tip 1:  executives do not have time for you to dim the lights and show them forty slides with charts composed of animated dancing leprechauns and flashing arrows that emerge from the void in a checkerboard pattern. Pro tip 2:   Guys, and gals with deep voices, executives also don't need you to use your "Radio Announcer Voice."

As a rule, what executives want is simple: one printed page. No matter what it is, it should be one page. And it should be printed, not emailed.  You should plan to hand it to the executive, and then you should be quiet when they read it and wait for their questions.  It's harder than it sounds.
 So how do you do it?  Here are the steps:
Write the deck that expresses your proposal in as many slides as it takes.  Use imaginative animation and blinking letters if you must.Remove your title slide.Insert a new slide at the front of the deck with "Appendix" written on it in big …