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.

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…

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 …