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.
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.



Comments

Popular posts from this blog

How Do You Vote Someone Off of Your Agile Team?

One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team.  You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall!   I know I wasn't picturing it that way for my first agile team, so I thought I should warn you.  (I thought I was going to get between six and eight original Agile Manifesto signers.  That didn't happen.). Why "warn" you (as opposed to "reassure" you, say)?  Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours.  In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone.  Now you are suddenly forced to interact in real time, perhaps in person, with written messag

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. From http://www.yogawithjohn.com/tag/yoga-class/ 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 a

Your Agile Transformation Needs to Start with a Quiet Phase

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/ I've observed some different agile transformation patterns, and maybe you have too: Just Do Standups   (Shoot, then Aim):   some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time. Pros:   you're very busy from the start. Cons:   what exactly are you doing and why? KPI-Driven Change (Aim, then Shoot) : some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indica