Tobias Fors

I love to use the user story format when I help teams plan their work. It can sometimes be hard to break user stories down into useable chunks, but their format is very easy to use: As a <type of user>, I want to <do what with the product>, so that <this value will come about>. There are different ways to format stories, but the essence remains the same. Use a simple format to quickly shake out some key information about a given requirement.

Maybe you’ve noticed that it’s not just during planning that we have hard time putting our thoughts and desires into words. Teams that do retrospectives frequently find that it can be very hard to get valuable output from these meetings. One cause of this, which is easy to remedy, is the use of inexact language.

If you’ve brainstormed improvement suggestions with your team, you might have seen a suggestion like this (written on a post-it note): “Better test”. Or maybe even terser: “Cooperation”.

These notes are a good start, because there’s an interesting story behind them. The problem is that we might have to spend considerable time pulling that story out. There is a simpler way to get there.

Nowadays, I use the story format not only in planning meetings, but also in retrospectives. Whenever I ask a team to brainstorm improvement suggestions, I ask them to do it using a template I supply. I ask them to write Improvement Stories.

An improvement story is quite easy to write, and looks like this:

Because <description of problem or situation>

we should <description of suggestion>

so that <description of desired result>.

I find that asking teams to supply their suggestions in this format results in contributions that are well considered, easy to understand and quick to process.

Have you tried using improvement stories? Drop me a note in the comments section!

I’m currently cleaning up my trusty old Mac Mini G4. I’ve been cleaning out old stuff I don’t need to save, and a few days ago I installed a cheap 1 gig of memory. That upgrade did not make the machine notably faster. Today, however, I ran a bunch of maintenance tools, which seemed to do the trick. There’s a noticeable improvement in the speed of the little things, like how long it takes to fold out a menu. There was a delay before, and now it seems to be gone. Hope it lasts.

Energized by my success in speeding up the old can, I started another round of file cleaning. I found an old NeoOffice file called “Russ Ackoff - 95 Percent”. Because NeoOffice has always been extremely slow on this old machine, I wanted to see how fast I could open it. That, and the fact that I’m always interested in Ackoff’s teachings.

NeoOffice turned out to be as slow as before, but the file contained pure gold. Not new gold, but pure gold. In it was a little piece of knowledge that I’ve been using in my scrum master classes for a few years, ever since I came across it on the web.

Here are the contents of the file, which I remember transcribing from a sound file as I listened to it:

“http://www.open2.net/systems/practice/rus12.html

1900 – 95% of the people in the US could not do the job as well as their bosses could.

If the foreman retires from a group, you pick the best man to become the new foreman.

He can thus do the job better than any of his subordinates.

He will continue to rise as long as he is the best in the group.

All managers thus rise to the level of their own incompetence.

Today, 95% of the people can do their job better than their bosses.

You cannot manage them the same way.

Don’t manage what they do – manage the way they interact.

Requires different organization, and a different type of management.”

Reading a blog post by Tripp Babbitt reminded me of Ackoffs discussion on internal market economies in Re-Creating the Corporation.

Babbitt’s blog post talks about how focusing on cost reductions often increases costs. One reason is that cost reductions are often approached by centralizing services in organizations. When this happens, a feedback loop is broken. Those who produce the services are no longer those who consume them. This means that they loose their understanding of how well the services work. When the consumer of the service sees the service degrade, they cannot easily improve the service, because they don’t control the production of it. Instead, the consumers work with what they can control, which sometimes means reproducing the service locally, thus increasing total costs.

How can we use this insight to improve software development?

In software development, we sometimes see this phenomenon with centralized platform teams. A platform team is formed to develop shared functionality, to be used by teams that develop actual product features. In reality however, platform teams often have a hard time living up to the expectations of the feature teams. Because of this, feature teams sometimes choose to locally develop functionality that was supposed to go in the shared platform.

Another example that comes to mind is when organizations set up project management offices, and these offices proceed by pushing out standardized methods of work, instead of listening to the needs of the different areas of the corporation. Again, the idea here is to save money by standardizing, but the result is often frustration, because there is no such thing as a one-size-fits-all way to manage projects.

One final example: the central database administration group. Created to gain control over database services, it soon becomes the bottleneck more than anything else, stopping projects dead in their tracks.

In Ackoff’s solution, departments within organizations should be free to procure the services they need from internal services and from anyone on the open market. If top management wants to override a department’s decision to procure externally they can do so, but will have to use their own budget to compensate for the losses the buying department suffers through this decision.

In other words, if a sales department is forced to procure their new IT support system from the internal IT department, even though they could have gotten the same solution for a cheaper price from an external provider, the overriding manager will have to compensate the sales department for the difference in cost.

Well, this is really a bit outside of my area of expertise, but interesting nonetheless. My learning goes on.

What are your experiences of centralized services? Good? Bad? Why?

Forget everything you know about agile, about any methods, about any kind of tool you’ve mastered. If there’s only one thing you should do, it has to be this: ask for feedback.

It doesn’t matter what you do or how you do it. If you don’t stop and ask the people you work with for feedback, you’ll never know exactly how bad you did until its too late.

It’s not complicated to get feedback, but it can be hard on you. Here is one way to do it.

First of all, you find a person who can provide you with some feedback. It helps if this is a person you trust. To this person, you present your desire for learning about how you’re doing, and ask if that person is willing to give you some feedback. If the answer is yes, you make sure you sit down in a comfortable environment where you both feel safe and relaxed. Then you ask for feedback on how you’re doing with something.

You could word it like this: “How do you think I’m doing when it comes to the TPS reports?” Then you sit silent and wait. And wait. You will always get feedback, even if the person you’re asking says nothing at all.

When you get the feedback, you might be tempted to think that you’re both done. You’re not. You might be tempted to blurt out a defense, because what you’ve just been told seems so offensive. Don’t. Instead, when you’ve heard what the other person thinks, stay silent. Think. Think about what that feedback might mean. Quietly formulate your interpretation of what that feedback really means, then tell it to the other person and ask if your interpretation is correct. Then go quiet again.

Either the person will say that your interpretation is correct, in which case you can say you’ve received the feedback. Or the other person will correct your interpretation. If this happens, you listen and think some more. Then you present your interpretation of the feedback again, this time incorporating the corrections you just received. Then you listen again, and repeat the process until your feedback giver tells you that you’ve understood things correctly.

Note that even complete silence can be treated this way. Silence as a response to a direct question is a kind of feedback, which you can try to interpret. If you do, it becomes doubly important to check your interpretation with the other person, because it now comes solely from within your own head.

If this procedure seems cumbersome, that’s only because it is. It’s not as slow as it seems when its broken down like this, however. Communicating clearly is hard work. We almost always go wrong in some way when we try to communicate with someone else, and it’s often due to the fact that we think we’ve understood the other person, when in reality we haven’t.

Do I always do it like this? No, and neither will you. In fact, if you’re like me, you’ll do like this far too seldom. Sometimes, we simply lack the energy to go through all the work that’s needed to communicate well. For me, that means I’m least likely to get good feedback when I most need it. It’s at times like those that I get into trouble, and that’s why I have to keep reminding myself that feedback can be scary, but that’s just because I don’t ask for it often enough.

To summarize:

1. Find a potential feedback giver
2. Ask for help
3. Find a suitable environment
4. Ask: How am I doing [with regard to something specific]?
5. Listen.
6. Think.
7. Present your interpretation of the feedback.
8. Repeat 5-7 until you get to hear you’ve understood correctly.

Whenever something unexpected happens - such as when we make a mistake -  there’s a possibility for learning to happen. For example, I just tried to add an extra branch in my mind mapping tool, but I pressed the wrong key combination. Instead of a new branch, a nice little yellow callout appeared. I immediately liked it, because it seemed like a useful thing.

What mistakes have you done recently, and what did you learn from them?