I needed to fail with modern methods for requirement gathering in order to understand old methods for requirements gathering. Many software projects write requirements in what is refered to as “user stories”. But a use story is not a story at all. There’s no drama, no action and no resolution. Instead, user stories are often just a bunch of interactions between the user and the system laying in a big heap in a shoe box. Or even worse: In an issue tracking system. Using the form of use cases, a requirement form that had failed me in the past, I have reinserted the drama into my projects.

Humans have used stories to communicate and to think about the world for as long as we’ve had language. Some elements are common to all stories: A conflict upsets the order of the world. A hero enters the scene. Through the actions of the hero, the world is set back into order and the all is well in the world.

Here is a for a project that makes a webshop, the story of desire:

1. Some person craves stuff (the conflict)
2. The webshop(the hero) welcomes the craving user to its front page
3. The webshop lets the user picks stuff
4. The webshop lets the user pay
5. Some more stuff happens through the webshop so that the stuff is delivered
6. Even more stuff happens
7. The craving person gets his desire fullfilled and the world is set back to the way it was supposed to be

Not the most exciting story, you say? Well, you asked for software system requirements, not for literary masterpieces! The use case illustrates my point: A narrative lets us understand the purpose of the system (the hero) in the world and the operations the system needs to perform in order to fulfill its purpose. The first and the last step of this narrative happen without reference to the hero, setting the stage and providing the coda (look it up!), respectively. Each of the action steps between clearly states what sort of capability needs to be built for the system.

The story of desire is a made-up story to illustrate the point. Here is a simplified version of a real story in my current project – the story of disturbance:

1. There is a disturbance in the balance of production and consumption of electricity (the conflict)
2. Already, the system (the hero) has received from power plants information about their reserve capacity (this is a story of its own, but for another day)
3. The system shows the Operator (the real hero!) power plants with reserve capacity
   • Variation: The operator filters the list of power plants using some criteria
4. The system lets the Operator activate the reserve capacity at a power plant
5. The system sends an activation request to the power plant in question so they can be activated
6. The system shows the operator what reserves are currently activated
7. The system lets the user deactivate reserves
8. The system sends all activation requests to the accounting system, so the power plant can get paid
9. The balance is restored

If you wonder why this disturbance in the force is a bad thing, take a look at my blog post about xxx. You’ll quickly see that the balance of electricity may impact whether or not my beer stays cool. Clearly an important concern.

This story is a bit messier, since it deals with more real-world problems. Together with all the details I let out, it also has the disadvantage that it will take one team about a year to develop. Our customer is a bit too eager to get some software out the door to wait for all that.

So, we present: The impatient story of disturbance

1. There is a disturbance in the balance of production and consumption of electricity
2. Already, the system has received from the old system we’re replacing information about power plant reserve capacities
3. The system shows the operator power plants with reserve capacity
   • Variation: The operator filters the list of power plants using some criteria
   • Variation: The system updates the view it receives new reserves
4. The system lets the operator activate the reserve capacity at a power plant
5. The system sends the information about the activation to the old system we’re replacing for further distribution
6. The system shows the operator what reserves are currently activated
• Variation: The system shows the operator what reserves have been activated at a given power plant
• Variation: The system displays a chart of what reserves have been activated at a given power plant
7. The balance is restored

During the start of our project we wrote about 10 stories like the original story of disturbance. The stories were written by small gangs each consisting of developers and users or other domain experts. The gangs would swap stories and improve each others work. Meanwhile, the product owner and the project architect would try and pry apart a story so it could be delivered by a single programming team in the order of about 4 months.

For a single delivery, we would write an impatient story. Each action step or variation of the “impatient story of disturbance” became an item on the backlog of the programming team. I’ve left out about a thirds of the stories to keep the text of the blog post down. In addition, the team had about 5 technical tasks, such as performance testing. Each week, the team would deliver on average two such items.

After a few months, we have delivered the first increment in a system that tells a new story to the users, but a story they recognize. We have taken the task that they use their existing system for the most and made it easier and faster to use. The result: Happy users. And cold beer. We hope.

Notes

This approach has very much the same vision as Jeff Patton’s user story mapping and Effect maps. The approach of linear textual stories is one that works well for me. I urge you to find an approach that works even better for you. My stories use Alistair Cockburn’s style of use cases from “Writing effective use cases”, but with one changes: I simplify the writing of variations to better support the linear flow and avoid detail. They are roughly at what Cockburn describes as “kite level”.

What is the goal of your current project? I currently work on a project for the transmission system operator for the Norwegian electrical grid. The value of the system we’re building is that my beer stays cool.

Skill

If you’re not skilled at what you’re doing, you may put in a lot of hours and end up having nothing to show for it. Maybe you ended up writing code that didn’t compile and you had to throw it away. Maybe you ended up staring at an empty screen for hours waiting for inspiration to strike. Maybe you ended up writing a long document, only to forget to save it and then your computer crashed.

The first trick to making sure that your work is worthwhile is to make sure that the effort you put in actually transforms to some effect. In order to achieve this, you need experience and practice with your craft.

Purpose

If you don’t know why you’re doing what you’re doing, you may produce a lot, but it ends up not being valuable to anyone. Maybe the code you write solved the wrong problem. Maybe your long document didn’t answer the questions of you readers.

The second trick to making sure that your work is worthwhile is to make sure that the effect you have actually produces value. In order to achieve this, you need to move in the right direction.

This is the model of all human industry, whether you’re making cars, books, food, presentations or software.

In software development, effort is the time you put in, skill is your skill as a developer, effect is the working software, purpose is the architecture and value is the business goal.

The fast track to success is to understand the last step: Value.

“The other me”

Here’s an example. Find the value:

My current project creates a system which presents in user interface electricity reserves and planned electricity production that it has received from a message gateway, as well as measurements that it has received from an electricity management system.

This is gobbledygook. If this is how I see the system, I will fail.

In order to see the value, we have to take a step back. The system receives planned production and available reserve capacity from power producers. It presents this, along with measurements of the current balance between consumption and production on the electricity grid to an operator. The operator uses the reserves to regulate production to match consumption.

Hopefully, this is much more understandable. You’re probably aware that there are companies that produce electrical power, and you probably understand that electricity consumption should match production.

But why?

The ultimate value of the system is to the consumer who want to plug his appliances into the grid and have them work. They should neither blow up (too much production) or lose power (too little production).

Who is this mysterious “consumer”, then. Why, it’s me! It’s not Johannes-the-software-developer, it’s the other me. The “me” who has his fridge connected to the power grid so I can keep my beer cool.

The purpose of my project is to keep my beer cool.

The other you

To understand the purpose of your system, you should try and see how it contributes to your own life. Not the life of the “you” who develops software, but the “you” who uses electricity, the “you” who drives a car, the “you” who breathes fresh air, the “you” who wants to retire at some point in the future.

If you can’t see “the other you” in your system – take a step back and look again. If you still can’t see “the other you”, maybe you should be working on a different project.

The workshop was very well attended, and so I’ve posted a Norwegian language summary on the company blog for Steria Norway. Go check it out if you understand Norwegian!

• I often make decisions that turns out to be quite crappy.
• Even when I think I’ve written or drawn something that’s smart, it often turns out that it’s incomprehensible to everyone else

Luckily, I’ve noticed that most developers have characteristics that almost always counter these weaknesses:

• Most developers are pretty smart, especially when they’re trying to solve a specific problem.
• Most developers don’t read architecture documentation

So instead of trying to force the developers to read my crappy, poorly documented decisions, I decided to try to see what happened if I instead made use of the opportunities that the situation presented to me. Enter: The Great Wall of Architecture.

There are two rules for the Great Wall of Architecture:

1. Only the pictures on the Great Wall of Architecture are officially part of the system documentation.
2. The architect (me) cannot draw pictures to be included on the Great Wall of Architecture

As a playful addition, some of the developers have signed their work, just like we used to do in kindergarten. You can’t actually see it on the photo, but the hand writing on this diagram reads “made by Christin, 32 years old”.

My hope is that the Great Wall of Architecture will make the whole team feel they can use their strengths on the project. As more drawings come up every day, I’m optimistic with the result.

• Organize my thoughts quickly
• Prioritize the wheat before the chaff
• Maintain a coherent train of thought

I find a very useful structure for archiving this to be what I call “three-by-three”: Three main points with three subpoints each.

• Forcing myself to keep to a structure will make my thoughts flow more quickly. Coming up with three ideas isn’t hard, so I quickly get something down on paper. Limiting myself to three points forces me to cut out less important ideas, and when I can’t think of a third point at any one level, I can leave it blank, knowing that I will revisit it later
• Using a simple cookie cutter approach allows me to spend more time with the important preparations for the talk, or the important work with the article: iterating over the points I want to make. Nothing improves a talk faster than practice. Nothing improves an article faster than reading it out loud. Deliver early and deliver often.
• Finally, using a simple structure like three-by-thee allows me to clearly get my point across. If I’m writing an article, I can use bullet points or headlines for the points. If I give a talk, I can count down “the number of things I want to talk about” on my fingers. And with only three things to remember, the audience has an easier time following what I’m saying.

Of course, any form can be limiting, especially when you’ve worked with the material for a while. So I have some variations of the three-by-three structure that I often use:

• Three-plus-three-by-three-plus-three: The middle part of an argument needs to be the most substantial one, so I can fractally subdivide this further into three-by-three arguments.
• Three-times-three-plus-one: It’s often good to end on something different, a counterpoint of some sort. I often add a “zinger” to the end of a three-by-three talk
• Let it go: As I iterate over something that started out as a simple three-by-three structure, I often find that it no longer no longer lets me express what I want. Then, as with any rule that get in the way, I break it.

I use the three-by-three structure in my workshops on how to present, as an assignment for the workshop attendants. This greatly reduces the time before they can start practicing their talks and get to that really great, quick presentation.

Har du fått med deg at Smidig 2010 arrangeres 16.-17. November på Radisson BLU, Holberg plass i Oslo? Konferansen har åpnet for foredrag. Early bird prisen på billetter varer KUN TIL TORSDAG, så det gjelder å bestemme seg fort!

Opplev vårt unike format, med over 70 lyntaler og 100 diskusjonsgrupper! Smidigkonferansen er den årlige nasjonale hendelsen som samler mennesker fra alle typer roller i IT-bransjen; prosjektledere, produkteiere, utviklere, bedriftsledere og testere og flere.

• Meld deg på som deltager eller foredragsholder
• Meld deg på LinkedIn-gruppa vår
• Meld deg på mailingslista for de som er interessert i Smidig 2010

I’ve not yet decided what posts to publish here and what posts to publish on Sterk Blanding. My present idea is that I’ll publish most of my English articles here at Thinking inside a Bigger Box and Norwegian language articles at Sterk Blanding. But I can be persuaded to change my mind.

For my Norwegian readers, enjoy my articles on Sterk Blanding:

• Hvordan komme i gang med blogging: Some tips for people who’re considering to write on a blog
• Hemmligheten bak gode spesifikasjoner: How to change your tests from specifying behavior to specify intentions
• “Det var dyrt”-øyeblikket: The sobering moment in my project when both I and my customer realized that the transparency of Scrum meant that we could see how much the project was really costing.
• Hvordan endre en statisk klasse til en dynamisk singleton: A step by step guide to an important strategic level refactoring in legacy systems: Changing static calls to use a singleton that can be mocked.
• Med Ram Yoga: Smidig brukervennlighet: Some practical tips on how to use agile software development and user centric design to complement each other

The first years I was working in this business, I didn’t see any distinction between “the user” and “the customer”. Once I started seeing the distinction, I started to understand that the person who is going to use the system we’re developing is not the person who defines what the system should do and neither of these is usually the person that pays me to develop the system. So I starting distinguishing between the product owner, that is, the customer and the end user. But the product owner often calls the person I call “end user” his “customer”. What’s going on here? Let’s check the dictionary:

CUSTOMER
Main Entry: cus·tom·er
Pronunciation: \ˈkəs-tə-mər\
Function: noun
1: one that purchases a commodity or service
2: an individual usually having some specified distinctive trait

CLIENT
Main Entry: cli·ent
Pronunciation: \ˈklī-ənt\
Function: noun
1: one that is under the protection of another : dependent
2a: a person who engages the professional advice or services of another
2b: customer
2c: a person served by or utilizing the services of a social agency
2d: a computer in a network that uses the services (as access to files or shared peripherals) provided by a server

I’ve seen suppliers approach their work by asking for a specification of a product to deliver and then trying to deliver something to that specification for payment. The mental model is that of a customer going to the grocery story asking for “eight pounds of CRM software”. My experience with organizations with this sort of mindset has always been unsatisfactory.

On the other hand, I’ve seen suppliers approach their work as an agent of the organization that pays them. “Our job is to enable someone else do their job better.” This totally changes the way an organization deals with this relationship. The word “customer” may not be conductive to this sort of thinking. Instead, we should think of ourselves as agents acting on behalf of a client. As an agent, your responsibility is to enable your client. This includes helping your client to find better means of reaching their goal.

By the way, wikipedia defines the word “agent” as “a person who is authorized to act on behalf of another (called the Principal or client) to create a legal relationship with a Third Party”. If the “third party” is the computer, then a good developer is an agent acting on their clients behalf in dealings with the computer software.

Why doesn’t the software industry use the word “client” instead of “customer”?

This Norwegian language article introduces a short two-page guide I’ve written to explain Scrum to people who’ve only just heard of it.

I samarbeid med våre dyktige redaksjonelle medarbeidere på Steria, har jeg forfattet en “3 minutters guide” til Scrum. Denne tar for seg spørsmålene som “hva er egentlig Scrum”.

Dette er Scrum

3-minutterguidene kan lastes ned fra Sterias hjemmesider.

Jeg planlegger å følge opp denne guiden med en guide som beskriver hva som skal til for å faktisk lykkes med Scrum. Har du noen ideer?

Colored ink, paper and makers support team process

When I started my current project I went to pick up sticky notes and marker pens for the taskboard. I grabbed, more or less at random three colors of notes (red, green, yellow), four colors of pens (black, red, blue, green) and five color sticky bookmarks (yellow, green, blue, orange, red). Over the first weeks of the project, we evolved a system that uses combinations of all the colors:

• For tasks that we plan at the start of an iteration, we use the black pen. Tasks that contribute directly to the project goals go on green notes, meetings go on yellow notes and administrative tasks go on red notes. (I’m still tweaking this)
• For tasks that we discover during the iteration, we use the red pen. The color codes for the tasks are the same.
• We don’t write names on tasks. Instead, each of the three team members have three sticky bookmarks of a color (green, blue, orange) that they can place on stuff they work on. We limit the number of bookmarks per person to limit multitasking.
• We don’t have a column for tasks that are to be verified. Instead, we use the yellow sticky bookmarks to mark things that should be verified. The yellow sticky is addressed at latest at the next stand-up meeting. Like with concurrent work, we’ve limited the number of tasks to be verified to three. (So far we’ve never needed more than one.)
• We use the red sticky bookmarks for tasks that are blocked. That is, tasks where the team needs outside help. We’ve limited ourselves to three red bookmarks. When we’d like to place the fourth, we’d rather spend our time following up the current blockers.
• Since we had some spare area on our taskboard, we decided to use this to look for improvements to our process. We believe that improvements shouldn’t wait until the retrospectives. Instead, we want to think of how to get better all the time. We use the green pen for improvements. Impediments that cause extra work or defects go on red notes, things that would make us work better go on green, and neat ideas that would be fun to try go on yellow notes.
• Finally, we have an area for impediments. We haven’t come up with a system for this yet, so we just use arbitrary color notes and pens.

Markers support pair programming

We’re always looking for ways to improve the taskboard further. In particular, I’d like to use the blue pen for something. I’m also not totally happy with the division into different sort of tasks. Finally, I’d like to have a special sort of sticky for things that don’t really take time, but that we need to remember to do, like sending out meeting invitations.

How do you customize your taskboard to our team’s process?