...copyright Elena Yatzeck, 2010-2017

Wednesday, October 24, 2012

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.



Friday, October 19, 2012

The Agile Lumberjack: Why Batched Requirements Are Not As Sensible As You Think

Let's say you're a Business Analyst, and you're okay.  You've done your job for years.  You are a subject matter expert in your own right, and you get the job done. 

Suddenly, a sparkly-eyed Agile Guru (SEAG) shows up at your workplace and asks you to stop writing a "requirements document" that holistically describes the software your developer friends will be building.  Instead, the SEAG insists that you use a set of index cards to "hint" at what needs to be built, tape the cards to a wall, and plan to focus on the details of each card later, right before the developer starts to build it.  And maybe you won't even write those details down then, either.  You'll take the "hint" from the card, have a "conversation" with the developer, everyone will nod enthusiastically, and off you go to find out more about a different hinty card.

Really, when you put it that way, it sounds totally crazy.

This is why some analysts have a very hard time with agile at first.  Analysts are the conscience of an agile team.  They are the people who draw the big picture from tiny, precise details.  They get the details right, but they can always place the details into a larger context.  They see the forest because they can see the veins on the leaves of every tree.

http://en.wikipedia.org/wiki/The_Lumberjack_Song
Why in the world would you NOT want to develop software in such a sensible way?  Aim, then shoot, you might say.  Map, then deforest.  And so on.  Actually, no.

What Toyota learned in the 1950s competing with Ford is that you have to be very careful about building your "economies of scale."  It might seem to you that it's more efficient to "just sit down and write all the requirements at once" than to intersperse writing requirements with developing software to meet the requirements, but empirically this is not so.  Consider this schematic view of a simple development life cycle -- requirements, development, and test of 10 software widgets:
Diagrams based on a really wonderful blog at:  http://rasmusson.wordpress.com/2008/04/16/batch-vs-continuous-flow-processing/

Done in the "economy of scale" requirements batch, followed by a development batch, and then by a testing batch, the first widget rolls out to your production web site after 51 hours, or maybe you wait to do a release, and all 10 widgets roll out in a total of 60 hours.  Nice.

But what if instead of batching the work by "role," you instead batched it by "widget?"  Viewed from solely your perspective as an analyst, it seems uncomfortable.  But if you think in terms of the whole system, this mode of operating is amazingly efficient.
You do the requirements for just one feature and hand it to the developers.  Then you move onto the second.  You work continuously on just one requirement at a time.  Devs work on building just one widget at a time.  Testers work on just one set of tests at a time.  The regrouping makes a remarkable difference in terms of time to market for your widgets.
  • Let's say you decide to release all of your widgets to market at once, once they're all tested, and let's say each widget earns your company $10K per hour once it is deployed.  Your "group by widget" strategy earns the company $1.8M more than the "group by role" strategy did ($10K times 18 hours times 10 widgets)
  • But if you have the flexibility to release your widgets to your production site as they get done, the benefits are even greater.  The first widget gets done in 12 hours rather than 51.  If this is a money-making widget for you, and it's worth $10K per hour to your business, that difference is worth $390K for just the one widget, and you get an additional influx of revenue for each widget that comes in ahead of the eventual 60 minute mark.
You will notice that this system still isn't optimal.  What would make sense would be to see whether the development work could be split into smaller pieces and done in parallel, so that the elapsed time per widget would be 1 hour for requirements, 1 hour for development (because you would have 10 developers for each analyst), and 1 hour for testing.  Now we're talking about bazillions of dollars difference in revenue, more than enough to make up for staffing the additional developers.

This is one of the big reasons why big Web companies like Amazon.com are so excited about agile.  They have widgets that can make this much money.

And no matter what software you are building in your company, you can benefit the same way.  Even if you have to wait to release software on some regular cadence, like quarterly, each release can have that much more software in it, because you batched by feature, not by role.

Which brings me to one final point.  Often times, new agilists think that "agile is just doing waterfall over and over again, really fast."  A team new to agile may take the time they have to develop a piece of software, and divide it into 4-8 week iterations.  In each iteration, the analysts do requirements for the first week, the developers do development for the next three weeks, and the testers get everything at the last minute, and then get blamed for bad quality.  You know they do.  You've seen this before.  Only it used to take 12-18 months, and now it happens monthly.

"Rapid waterfall" is really just the worst of both worlds.  You still have people sitting idle part of the time, or else you evolve some kind of "overlapping rapid waterfall" where everyone is working on three iterations at once to "keep busy."  So don't do that!
 
http://commons.wikimedia.org/wiki/File:Stone_rapids.jpg
Do the stuff the SEAG tells you to do.  Break the work into small "stories," and work as a team to move the stories from "not started" to "done" as individual units, keeping the flow constant, and not waiting for some artificial whistle to blow somewhere to announce that "now it's time to start developing."  That's why we have a card wall.  The smaller your units of work, the more productivity you can squeeze out of your system.

You didn't want to be a lumberjack anyway!

Sunday, October 7, 2012

5 Reasons to Embrace "Cafeteria Agile"

Agile enthusiasts are quick to make fun of people who pick and choose among various agile concepts, philosophies, techniques, and tools, rather than working hard to be "pure."  We have a word for people who do that:  dilettantes. 

From http://lifeasareader.blogspot.com/2010/11/i-am-cafeteria-catholic.html
But when we use two words we call them "cafeteria agilists."
  • If a software development team has a burn-down chart, weekly releases of something to production, and no discussions with the business, ever, we are quick to chorus "THAT's not AGILE!"  
  • If they have a great working relationship with business partners and talk daily, but managers still do estimates of work durations, and assign work to the programmers and testers, we roll our eyes, and we start to abbreviate:  "TNA!"  
  • If a team deviates from any named agile technique, be it Scrum, Extreme Programming, Crystal, or WaterScrumFall, and even if they follow that last one to the letter, "TNA!"  If they use UML these days, or even Use Cases, "TNA!"  
One almost wants to design a t-shirt with "TNA" on the back in flashing letters, since it's a saying that fits almost every real-world situation you'll ever see.  It's fun to make fun.  And to some degree this is human nature--why would you choose to help a company "suck a little less" when you went into this business to change the world?  Seriously.

I have five quick defenses for "cafeteria agile:"

1.  People Have Label Fatigue:  Today's business people are tired of fads, and tired of labels.  Flying the "Agile" flag for this audience not only isn't good--it's actively going to get in your way.   Unless told otherwise, when you address a new audience, you should assume that they think you're here today to represent a management fad.  All your listeners can think of is "the guy doing Six Sigma wore a blue track suit, not a rainbow one," or "the TQM lady had a cuter English accent."
  • They do not want to lie on their backs on blue towels and listen to blurry cassette players through headphones, as they did with the PMP trainer.  
  • They do not want to do "Jeopardy" skits, like they did with the Tech Leadership trainers.  
For the label-fatigued audience, your best bet is to avoid using the word "agile" altogether, listen closely to what they have to tell you, figure out how to best help them from your treasure trove of agile philosophies and techniques, and just do those things first.  One day they may forgive you for being an agilist, and one day they may develop an interest in the Manifesto.  But in the mean time, what about giving them something they can use?
From http://www.oempromo.com/Tools-and-Hardware/Measuring-Tapes/index_25.htm
You're going to win more friends with useful piecemeal advice than you can by taking a hard party line that it's all or nothing.  Which is related to:

2.  It Takes Time to Change the World.  Think of each Agile Cafeteria choice you ladle out to your client as a "thin slice" of a bigger system.  What time frame did you have in mind, when you came in to do your "agile transformation" of this group?  A week?  A month?  18 months?  It's amazing how you can take a group of sophisticated software developers who understand about "incremental delivery," "refactoring" and "thin slicing," and have them despair when they aren't able to do a "big bang" change to the software development processes in a company of any size:  lock, stock, barrel, culture, tools, and team rooms.

Although "social epedimic theory" suggests that a "biggish" bang may occur along the way, you're likely going to have a long incubation period when you're slowly wooing your audience by feeding them measurable returns on the money they have invested in your agile advice.
From http://blogs.cornell.edu/info2040/2011/11/08/viewing-the-world-tipping-points-and-social-epidemics/
You may need to swallow your pride and just provide your audience with a few key things to try that will pay off, and then spoon feed them a little more the next time around, and the next time, and so on.  Later they will understand that they were short-changing themselves, but they can't hear that message from you now.  Which is related strongly to:

3.  Client Executives don't want a generic label.  They want something they can brag about specific to them and relevant to their own context.  There's a reason most consultants do a thing called "pain point analysis" early in their engagements.  If you know what the company's pain points are, you can design a strategy to help with those things that matter to your employer.

You may feel "TNA" if the team isn't collocated.  But if your sponsoring executives are going to live or die at the end of the year based on the ROI on some big project you're helping with, and what they're looking for is low investment and accelerated revenue, you won't make yourself popular by insisting on an expensive relocation of the entire offshore work force.  Find out what they care about and deliver it, making sure they get the credit for all of your ideas.

Executives will seek you out if they hear that you can selflessly solve their problems and make them look good.  They are less likely to feel a strong motivation from a person who comes on strong with the message "look!  you're doing this simple thing all wrong!"  Which brings us to:

4.  The Prix Fixe menu makes it hard for YOU to claim success too.  If you spend any significant time with agile evangelists, and you will quickly find that the "definition of how agile we are" quickly gets mixed up with the question of "how are we making software delivery better?"

Let's say your "definition of agile" is that software goes from idea to production in a week, every week.  You work with a pilot team to make this goal a reality.  You claim "Victory!" and then suddenly find yourself stalled.
from http://scienceblogs.com/strangerfruit/2008/05/02/national-mission-accomplished/
Let's say it turns out that your company mostly has customers who can only absorb change once per year, and then only with a LOT OF TRAINING.  The project where you were able to instantiate your idea of agile was an anomaly.  If you're measuring your "agile penetration" by the percentage of the portfolio going to production every week, and also calling that your "success," you've just boxed yourself in quite thoroughly.  Don't do that!

5.  Don't Be The Thing You're Fighting Against.  What do we agilists want to stand for?  Change!  Agility!  Flexibility!  The last thing we want to do is get locked into some rigid set of "dos" and "don'ts."  Do you seriously want the next generation of rebels to laugh at you?  No!  Have some self respect.  Be a cafeteria agilist, and be proud of it.
From http://www.huntsvillerewound.com/athens.htm