Skip to main content

Roles with Teeth

As a coach and trainer, I have noticed that when I start the "Roles, Personas and Goals" discussions, attendees in the room are 40% more likely to start surreptitiously checking e-mail their smartphones than they when we talk about comparatively exciting topics such as "stand up meetings," "story boards," the "burn up versus burn down chart" debate, or "evolutionary design."   I had to lure you to this blog post, in fact, by riding on the coat-tails of the Breaking Dawn, Part 1, premier tonight at midnight.  You aren't interested!   You have heard it all before!  "To write good software, you need to know who will be using it and what they want to accomplish."  Blah blah blah--sounds like something your mom would say.   "Give the roles names, and think of them as people.  If multiple types of people play the same roles, give them different names, and call those things 'personas'"  Now you sound trendy and slightly unhinged.  Let's go back to the burn-ups.

From http://www.fantasybooksandmovies.com/edward-cullen.html
Let's not!  I'm going to simulate a "requirements" conversation with your business users twice, for purposes of comparison.  "Before" will represent what you may be doing now.  "After" will represent the same conversation, except that all players focus in a disciplined manner on roles and goals--who is doing the action and why?  Could it be that such a slight change of focus will give you measurable improvements to your software?  I say yes!

Before ("the system shall"):

Analyst:  "So to complete requirement A-445, after the screen prompts for the three criteria, if the first check box is activated and the fine amount is under $50, the save button is disabled and an error message is displayed."

Business user:  "Right"

Analyst:  "So we're done then?"

Business user:  "Yes."

After (someone in particular is doing something for some reason):

Analyst:  "So who has access to the screen where you can enter the fine amount?"

Business user:  "The receptionists in the front office."

Analyst:  "Let's call our sample receptionist 'Gayatri,' okay?

Business user:  "Um, okay, if you say so."

Analyst:  "All right, so a person who lost their library card walks up to Gayatri, and Gayatri brings up the a screen where she can enter the fine amount.  She asks whether the person has lost a card before, and if the answer is yes, the fine needs to be $50 or more, depending on her mood.  If not, they can get a new card for some amount less than $50, based on a sliding scale that Gayatri maintains.  Is that right?'

Business user:  "Um, no, actually not.  We have a triage person who handles the library card issues.  If the person has lost their library card more than ten times, the triage person calls an armed escort to take the person out of the library forever.  If it's less than ten, the triage person updates a flag on the person's record to show that it's either the first card lost, or some number larger than that.  They're the ones who update the 'repeat offender' flag."

Analyst:  "Okay, let's call the triage person Jens."

Business user:  "Uh huh."

Analyst:  "Does Jens use the same screen that Gayatri uses?"

Business user:  "No, Jens gets a screen with a panic button and no fine amount.  That's why I didn't bring it up.  We're changing the rules around fine amount, not the repeat offender flag.  Do you agile guys get partially lobotomized before they let you loose?"

Analyst:  "Would you expect Gayatri to need to update the repeat offender flag, or should it be locked down?"

Business user:  "Hm.  Interesting point.  We're instituting this new rule to ensure that the library can protect its fine revenue.  We set up Jens's job in the first place to separate enforcement from the clerical function of just putting in the fine amount."

Analyst:  "So the 'repeat offender' flag should be disabled on the fine entry screen?"

Business user:  "Yes it definitely should.  We don't want Gayatri gaming the system.  We've had a history of soft-hearted admins resetting patrons to non-offenders just to take a little bit of money off of the fine.  They're just enablers.  Those people are monsters--they go through ten, fifteen library cards a year!"

Analyst:  "Yikes!  Okay, so we're making two changes to the fine entry screen:  first, lock down the repeat offender flag and only allow it to be edited on the panic screen by Jens.  Second, enforce that when Gayatri hits 'save,'  if the repeat offender flag is set to 'yes,' she must collect $50 or more."

Business user:  "Yes, that's right."

Analyst:  "So we're done then?"

Business user:  "Yes."

This may seem like a fanciful and trivial example, but I hope it illustrates the point.  In this case, actual library revenue could have been affected if one field had been left editable rather than changed to read-only.  Moreover, by describing actual people doing actual tasks, this analyst was able to find out about a whole additional screen she didn't know about before.  I've been on projects where analysts focused on "the system" didn't find out until months into actual software development that "the system" was only one of TWO systems that Jens, Gayatri, and the other imaginary personas were using to keep data up to date.  The work load for the project doubled in a day, once someone shadowed an actual data entry person to see what they did.

People-focused requirements gathering is the only type of requirements gathering trustworthy enough upon which to base your company's cash flows, or anything else important to your operations.  Even if you are an analyst who is a subject matter expert in her own right, take the time to mentally walk through the process as performed by your actual end users, and don't focus too quickly on the details of "the system" and "the screen."  The focus on people itself is important, and it will bring you and your company significant return on investment.

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…

Requirements Traceability in Agile Software Development

One of the grim proving grounds for the would-be agile business analyst (henceforth "WBABA")  is the "traceability conversation."  Eventually, you will have to have one.  You may have seen one already.  If you haven't, you may want to half-avert your eyes as you read further.  It gets a little brutal.  But if you close them all the way, you can't read.
Dialogue:
WBABA:   ...so in summary, we complete analysis on each story card, and then we support the developers as they build it that same iteration!Corporate Standards Guy:  but how do you do traceability in agile?  You have to have traceability.  It's broadly recognized as an important factor in building rigorous software systems. These software systems permeate our society and we must entrust them with lives of everyday people on a daily basis. [The last two sentences are an actual quotation from the Center of Excellence for Software Traceability website!] WBABA: [cowed silence]Corporate Standards …

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…