Good stories have Great titles

When you read a good book, you can quickly refer to it by its title: We, Animal Farm, The Left Hand of Darkness. Having a title saves you the time of recapping the plot in order to establish that you and someone else know what the story is about.

Every day, Scrum teams do a 15 minute standup during which they describe to their team how they've spent their development time. I've noticed that teams which have been coached to use the "as a user" format of stories (credited to Rachel Davies & Tim Mackinnon, promulgated by Mike Cohen and many others including my self), create an impediment by giving their stories ID numbers instead of titles. "I worked on client authentication" turns into "I worked on story 6933," and most of the team doesn't know what this is and often just lets the information fly overhead. Even if they were familiar with 6933, there is less information and more abstraction when assigning numbers, and it's hard to feel an emotional attachment when sharing this number to people ancillary to the team, such as stake holders or perhaps the product owner. These story serial numbers become an impediment to communication.

For a while I coached teams to save that first line for the story title. It's easy to forget though and violates the principle of "once and only once" since the portion of the "as a user" format already contains that information. As a second measure, I coach them to underline the key words on the story card. But teams still end up adding an ID number, and in the heat of giving standup, it's actually hard to parse all the words though easier to rattle off the ID prominently displayed in the upper left-hand side of the task card, so I sometimes end up wasting my breath by saying the number.
Today I was writing some new stories and struck upon something that made felt right:

WHAT I WANT
so ROLE can BUSINESS VALUE

For example:

I've been using this format on my last two projects and have been very happy so far. I like how the story title has the important element coming first: What I Want.

Give it a try, and tell me what you think. I'd love to here your comments. Let's not try to describe Animal Farm by giving it some meaningless number, unless we're talking about 1984.

NO info DUMPING

No Dumping

In the pursuit of good Karma, riches and fame, employees want to provide value to their employers and colleagues. This leads to a compulsion towards DIY (do it yourself), which results in project teams not working in pairs. Working in pairs allows for superior information sharing but due to socialization of DIY, those who avoid pairing are not even conscious of the inefficient mechanisms that they have created to allow them to work alone. One of these mechanisms is the info dump.

What is an info dump?

The other day I was working at home and needed a stapler. I knew it should be in my wife's office so I went there and looked in the drawer where it was supposed to be. It wasn't there so I guessed that my wife, being a busy woman, possibly left it somewhere else. I looked around on the desk and then on some shelves. After five minutes had passed I realized I was going to waste a lot of time unless I got more information. "Honey! . . ."

She was in the living room busy doing work on her laptop. I interrupted her and she knew right where the stapler should be. She said she had left it in a pile of magazines shoved into a different drawer. It took a while to describe the details of the information, which drawer, which desk, what corner to look in, but she eventually dumped the information on me and I went back into her office. I tried to reproduce the steps but after some time I gave up and went back to the living room. "No, not that drawer!" she said and she gave me further instructions. I tried again until I was frustrated and asked her to come take a look.

After a moment she said, "I remember using it when I was cutting out photos." She opened another cabinet and looked. It wasn't in there, but then I remember a pile of photo paper near the printer. I pointed at the purple scissor handles sticking out from beneath the printer stand. It only took a minute to find them!

Why did this work so well?

As soon as she entered the room, the context of her surroundings jogged her memory of where she had last put it. We were working with up to date information about the room. She provided additional information where I could help because I was in the moment. It took very little time when we worked together. While trying to perform DIY, I used up over twenty minutes, randomized my wife's work, and I still didn't get the job done.

Engineering

Coworkers, bosses, and employees asking a small favor, they all want to get things done with minimal disruption to others. People working on the same project often divide the work and then DIY until they are really stuck like I was. This leads to waste and each individual becomes a silo of information of how the work was performed. This also leads to conflict when the team members integrate their work and their designs don't fit together. Instead, if they immediately work together, their collaboration will result in a usable design. When they each DIY, they heavily invest resources in each of their own designs so when they integrate their code, they have to decide who wins. They both lose in the end since the project will finish only as fast as the slowest item of work.

Conclusions

Now that you know what in info dump is, watch for it in your office and you'll see it happen over and over. Two people will get together to discuss adding functionality and invest time in one of the below Info Dump Anti-Patterns. Each requires a significant amount of time and then also requires future iterations of doing it over again once new information is found. From my experience, it always takes more time to use info dumps and try to work in parallel, than to serialize the work and have two parties work side by side at one workstation. At that workstation, they execute a "doing" strategy where, in the moment of "doing", the pair can immediately discuss, make decisions, and execute; discuss, make decisions and execute; . . . Below are some anti-patterns I've observed in the wild.

Info Dump Anti-Patterns

Each pattern has two roles: the "implementer" (the person doing the work), and the expert (the person who has a little more history and more knowledge about how the work could be done).

Mental Gymnastics - This occurs when two (or more) people discuss a coding related problem for 20 minutes or more. It's not possible know the code base well enough to be this detailed. The discussion will contain inaccuracies but the participants continue like it's some kind of limbering of the mind, or mental gymnastics. Even more waste happens when these two gymnasts argue over their recollections on how the code operates. When the gymnastics is over, the implementer goes to her workstation and within minutes, discovers that the code works differently than either of them thought. At that point, she either redesigns a solution by herself (DIY) or goes back to the expert and updates him, and then they have another session of mental gymnastics. I've seen this process repeated up to four times in one day.

Tome of Knowledge - The expert spends half the day (or more) writing a design document. At best, it is written immediately after reviewing the code so the information is accurate on that day. The tome is given to the implementer and hopefully the implementer does the work before the information is out of date. Even with an up to date tome, the implementer's knowledge is incomplete and has to visit the expert for a session of mental gymnastics.

No Do, just Code Review - The expert and the implementer sit together at a workstation to learn how the code works. The benefit is that the information is completely up to date and the session is interactive between the implementer and expert. But since they don't actual "do" any coding, they perform mental gymnastics to predict design changes and guess at how the new functionality will hook in. Ideally, the implementer immediately develops the code after the code review. But before the hour is over, the implementer starts to find challenges in getting the code to work as expected. So the implementer performs DIY or often needs to visit the expert for more mental gymnastics, tome updates, or code reviews.

Just another Westside Story (the Wikis versus Sharepoint)

There has been a battle at my company over how to store and disseminate knowledge. We (speaking as a member of development) have used the Confluence wiki for many years and were happy with it. But less technical staff such as managers, marketing, and sales really hated it. So there was a shift at the IT management level to move everyone to Sharepoint. Their main argument was that Sharepoint was free due to our MS licensing agreements.

It turns out that it wasn't really free because it required many resources from IT to actually get the system up and running in an organized and useful fashion, and even then, development hated it because managing content using a word processor was heavy weight compared to editing a wiki page. (Using a wiki page is nearly as simple as writing things down into a text file.) The non-development types will disagree with this saying that Sharepoint is easy because it is like a word processor, a tool they are familiar with. But the type of work they do is more akin to publishing results where development uses a wiki for knowledge dissemination and creation, more akin to jotting down notes. If it isn't quick and easy to do, developers will just live without doing it at all and this will create some efficiency losses. For development tools, throughput is king, not tools for making things look pretty.

Sharepoint supporters will also say that there is a wiki in Sharepoint. But its really an abuse of the term. It comes with a rich-text editor which gets in the way of everything that makes using a wiki nearly as easy as creating plain text files. The Sharepoint wiki is a great way to persuade everyone to retreat back to the word-file/upload/download paradigm that is native to Sharepoint.
This creates problem's in development. The best team collaboration pattern is a community of cross-functional team members that change/maintain the team's knowledge sharing system with little effort. (It's like Web2.0 content communities versus Web1.0 web pages.)
IT's push to sharepoint caused some splinter groups in development: one faction moved to Sharepoint, a faction of development stayed with Confluence (though under threat from IT that they would pull the plug), and a new faction organized around media-wiki.
The later two groups formed out of frustration of using Sharepoint.

Recently, I was coaching one of the team's that kept their documentation in Sharepoint. Only one or two people bothered to put add/maintain information in Sharepoint. Many did use the site as readers. This created a culture of very little documentation which was out of date. When I moved some of their documentation to mediawiki, suddenly more people started updating any problems they saw and added more documentation. It was amazing to see how using the right tool enabled this to happen.

I've been working with wikis since 2001 and one thing that holds true is that there is a small learning curve that some members of the team may not cross, unless they are pairing with someone to get them going. I've found one simple exercise that quickly gets people using wikis is to ask them to add their contact information to the team's wiki. (Put it on the backlog if they aren't taking it seriously.) To perform this milk run, they are exposed to a few tools which gets them immediately productive, and with that critical mass knowledge, they know how to find more advanced features or how to use existing pages as pedagogical devices. Learning from existing pages is a property that Sharepoint lacks. Sharepoint relies on the usual hunting through menus and buttons because there isn't any "markup source" that can be used to learn from other people's postings.

Remember that wiki means quick. If a wiki doesn't fit this term, then find one that does. Otherwise, no one will use it and that free Sharepoint tool is going to cost you.