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.

Comments

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

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. From:  http://www.highestfive.com/mind/how-to-perform-a-successful-interrogation/ 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 actu...

Beware the Dark Triad: Your Worst Change Management Nightmare

What do you think is your biggest blocker, in terms of introducing agile software development to an organization which hasn't used it before?  Ignorance?  Lack of the proper tools?  Cube farms?  These perils are grave indeed, but they are nothing compared to something for which I have just learned the name:  the " Dark Triad ."  Machiavelli tells it like it is--or does he? The Dark Triad consists of three personality constructs: Machiavellianism, narcissism, and psychopathy.  As that source of all knowledge, wikipedia says, The narcissistic personality (in the clinical sense) is characterized by a grandiose self-view, a sense of entitlement, lack of empathy, and egotism. The Machiavellian personality is characterized by manipulation and exploitation of others, with a cynical disregard for morality and a focus on self-interest and deception. The psychopathic personality, is characterized by impulsive thrill-seeking, and in its "primary...