A thought on task management

A thought: The goal of task management is to understand what you should be doing right now. (Apply to appropriate values of “you” and “now”.) Task management that doesn’t help you reach this goal is waste.

So backlog items only bring value when they help you (or someone else) decide what to do now. Those 50 items at the end of your product backlog? Probably not very valuable.

Different project management activities handle special cases of “understand what you should be doing now”. Their value depends on the situation.

For example, a detailed schedule might help you decide when to start marketing efforts before release. Or it might help you decide which features to include in the release. But if your marketing efforts have a short lead-time, if the most valuable feature is obvious, and if you do continuous releases anyway, then perhaps the schedule doesn’t bring that much value.

I hope this thought will help me decide what level of planning to do in different situations and find alternative solutions to the problems planning is trying to solve.

Know why

One of my two favorite go proverbs is this:

If your opponent has all four corners, you should resign.

On the go board, it is easiest to cover territory in the corners. If you have given all four corners to your opponent, you are probably losing. The advice is clear, concrete and to the point.

My other favorite is this:

If you have all four corners, you should resign.

Again: clear, concrete, to the point. And seemingly the exact opposite of the first proverb. How can they both apply?

Suppose you play against a better player. When you take the corners, your opponent takes something else, otherwise she wouldn’t give the corners to you. Even if you are leading in territory now, she will use the influence she gained elsewhere to surpass you.

The same deed has a different result when the doer is a master. The master knows why.

Peter Thiel’s Zero to One

I finished Peter Thiel’s Zero to One some weeks ago and found it fascinating. Thiel co-founded PayPal and Palantir, and made early investments in Facebook, SpaceX and LinkedIn. In the book he shows us what successful startups are made of.

Thiel compares doing new things (startups) with copying things that work (established companies). In the global scale, these correspond to technology versus globalization. With the recent decades’ focus on globalization, technology has been playing a second violin. Perhaps this is the reason why growth has slowed in developed economies.

What is missing? Ambitious plans. The world needs new Apollo programmes: ambitious goals with definite plans. For some reason, people in general have lost their their belief in planning. In startup world, you can see this in the lionization of lean startups.

Successful startups plan big. Thiel mentions seven things that lead to success. For example, Tesla has them all:

  1. Technology: So good that even its competitors rely on it.
  2. Timing: It extracted $465 million loan from government during the clean tech boom in 2010.
  3. Monopoly: It built a small but total monopoly with its roadster and only then expanded down market.
  4. Team: Strong in both technology and sales.
  5. Distribution: Tesla has its own network of retail stores.
  6. Durability: Strong brand and continuing innovation.
  7. Secrets: Tesla had the insight that fashion drove sales in clean tech. So they built a car that made their owners look both eco-friendly and cool.

I found the book really fascinating. For me the main takeaway was that to build something ambitious, you have to believe you have control over it. In agile software development circles, have we become trapped in our mindset of indeterminism and iteration?

Back to blogging

I am going to start blogging again. It’s been two and a half years.

I never really stopped blogging, I just didn’t post anything. Maybe I adjusted my quality threshold higher than what produces sustainable pace of blog posts. And then, when I didn’t post for a while, it raised the threshold even higher.

I have many thoughts that are unproven. Instead of waiting for the day when I am absolutely certain that what I say is true, I just post what I think. After all, when am I absolutely certain of anything?

How to build rapport

relation; connection, especially harmonious or sympathetic [dictionary.com]

First a confession: ten seconds ago, when I wrote the title of this article, was the first time I ever typed the word rapport. You see, I wrote a blog post about the essence of trust yesterday, and while giving it the last finishing touches, happened to look up the synonyms of “unity”. And there it was: rapport, the word I had heard many times but which somehow hadn’t found its way into my active vocabulary. With the new expressive power I could now compress the post into a single sentence: “Rapport is good.” I considered publishing it but decided to write this instead.

Now that I have established my expertise, let’s move on to the subject matter.

If you read the short Wikipedia article on rapport you will see that it is all about tricks: mirroring, reciprocity, commonality. You may get a feeling that rapport is sleazy or not important. Nothing could be further from the truth.

Rapport is the fundamental building block of trust, and thus the basis of teamwork. In my mind, trust has three aspects:

  1. Trusting that others do as promised.
  2. Trusting others in such a way that you can be yourself without a fear of ridicule.
  3. Rapport.

If you have the first two and not the third, you have a team that functions, but does not function well. You recognize such a team because they don’t talk much to each other. They don’t hang out. It is just eight hours of TODO list and then go home.

Rapport brings joy to our lives. Without rapport, we are just individuals, competing for getting whatever it is that we are after. With rapport comes joint purpose (or it may be the other way around; nevertheless one tends to come with the other) and we are no longer separate.

Rapport comes from honestly trying to understand the other person. By the word honestly I mean that if you don’t really understand, you should say so. Which can build rapport on another level — agreeing that we don’t agree may sometimes be enough.

Rapport exists in interaction, in discussions. I touched this already in an earlier article. While conversing, you are continuously building a framework for that same conversation — an imaginary world if you will. You are allowed to build on top of it, add details to it, and you are allowed to add boundaries around it, but you are not allowed to tear it down, lest you lose the rapport. Every conversation has some framework it exists in. The willingness of participants to accept the framework (even if it is only for the sake of the conversation) largely determines its degree of rapport.

Let’s say you are an atheist and you go to a bible study group and the topic is the meaning of miracles of Jesus. If you say that there is no meaning because there is no god, you destroy the rapport. Why? Because there is an unarticulated but obvious hypothesis in that setting, and the hypothesis is that god exists. By saying that there is no god, you have destroyed the framework that the conversation relies on.

(Out of interest, I did go to a bible study group once, accepted the hypothesis for that evening and it was wonderful. Such warm people.)

The skill of rapport is the skill of imagination. When you talk to someone who thinks differently, what you need to do is to imagine the world where his or her viewpoint is true. You may not agree with it entirely, but you can use your imagination to accept it for the sake of the conversation.

Another skill you need is reading the situation. What is the framework of this conversation, what hypotheses does it rely on? If you cannot read the hypotheses, you don’t know what is allowed in the conversation and what is out of bounds, and you will not build rapport unless you are lucky.

But what if you actually need to say something that is not supported by the current framework of the conversation? What if you feel that the hypotheses of the conversation are wrong? If you are not in a hurry, the easiest thing may be to wait for another opportunity, then carefully craft a conversation with a framework that is right for what you need to say. Intelligent people can imagine a lot of hypotheses, so this should not be a problem.

Continuing from the example above, if you want to talk about the existence of god, the bible study group actually may be a perfect place for that. You just cannot bring that up directly in a discussion about the miracles of Jesus. What you can do instead, is to tell the group beforehand that you don’t believe in god, that you would like to talk about it, but that you would like everyone to discuss it objectively without anyone trying to convert anyone to their side. This is a setting that works, assuming that everyone is sufficiently open-minded for the duration of this conversation.

If you are in a middle of conversation and want to bring up a framework-disputing fact right then, you need considerably more skill. You have to be very clear that you are dismantling some hypothesis of the conversation, and you are only doing that because you feel that the conversation with a new set of hypotheses would be more relevant than the conversation with the current hypotheses. And because on some level your new hypotheses are still competing with the old ones, you have to introduce them in a very engaging way.

So the people with the greatest ability for rapport tend to be those that are good at reading the situation, attempt to honestly understand, have a great imagination, and can rebuild the framework in an engaging way. Here’s an example of all those powers in action. Answering a non-scientist’s question about magnets, Richard Feynman sees the unarticulated and unhelfpful hypothesis that fundamental physics can be meaningfully explained in lay terms. He uses a lot of imagination to engagingly build a framework where that hypothesis is not true, and then goes on to give the best possible answer to the original question, an answer that would have been totally unsatisfactory without the dismantling and rebuilding of the framework. Result: rapport and understanding.

So, Antti’s guide to building and maintaining rapport:

  1. Honestly attempt to understand
  2. Read the situation to see the framework
  3. Use your imagination to work within that framework
  4. Don’t break the framework
  5. Carefully dismantle and rebuild the framework if you need to

Speed by removal

If the goal is to get software out fast, a way to get there is to remove unnecessary work. Like this:

Contracts over the project scope. Plans change. Contracts either slow work down by necessiating negotiation before change, or speed it up by making change as easy as possible.

Deadlines. They seem like a good idea: by promising we will be ready by some day we commit ourselves to stripping away the unnecessary work. The problem is that committing to a deadline requires us to make guesses about the scope and implementation of the project before we have the required information. If our guess turns out optimistic, we miss the deadline. If it turns out pessimistic, we have unnecessarily postponed the delivery.

Coding. Many problems can be solved with a pen and a paper, or using existing software. Developing code is slow and expensive.

How we measure progress defines how we work

We want to be fast and reliable in our work, so we want to measure our progress. The question is what is the right scope for the measurement? When do we start the clock and when do we stop it? This is a fundamental question that in practice defines the way we work.

Let’s say the phases of our value chain — be they implicit or explicit — are like the picture on the right. To start with a narrow example, if we choose to measure our progress from the start of coding to the end of coding, that drives us towards very careful up-front planning and design of the system. We will want to be sure that when we start the coding, we will have as thorough understanding of the system as possible. We will be using something akin to waterfall as our development method.

On the other hand, if we measure from the start of the idea to the end of coding, we will end up with something like cowboy coding. We want to do as little design as possible, because that takes time from coding, which is the crucial part. We don’t need to care about testing, because that is out of our measurement. (Cowboy coders, almost by definition, don’t measure anything explicitly. But the argument goes in the other direction: if we measure things this way, we end up with something akin to cowboy coding.)

What measure leads you to Scrum? The methodology itself does not mandate where the boundaries are, but the way I have seen most Scrum teams implement it, is from the start of UI design or technical design to the end of testing or deployment. In theory, these kinds of Scrum teams strive to deliver working software but don’t care if it actually produces value or not. Product owner should take care of that part, although it is a bit more complicated than that in practice.

The things we measure set in practice the boundaries of our business. Even though we may focus on a certain part of the process—e.g. from IX design to deployment—if we choose to measure our success more broadly—e.g. from end to end—we will become invested in the result of the broad interpretation. This entails that we will in one way or another want to help our customers and suppliers in doing their part of the work.

So what is the right measure? There are two conflicting forces pushing us to different directions. What the business ultimately wants is quick creation of business value. But on the other hand, work is easier to organize and buy when it is modularized with clean interfaces. For example, if a company modularizes interaction design well enough, so that its input and output are clearly defined and of good quality, then it is easy to buy IX design from that company, and the measure of progress from the start of interaction design to the end of interaction design makes sense.

In my experience, success is often measured too narrowly, leading to many of the problems in our industry. The earlier in the process you start the clock the more adaptative the process will be. Likewise the later in the process you stop the clock the more relevant the feedback. Development of complicated software is not good enough yet to use modularized approach in its value chain. We need a more integrated approach.

Looking in the eyes

When I was in the seventh grade, I used to walk past this dog every day on my way to school. It was a small dog – some kind of a poodle, I suppose – but it guarded a big house and took its job seriously. Every morning and every afternoon when I walked past the house, it barked furiously. I was annoyed so I planned all kinds of schemes how to get rid of the wretched creature. In the end I chose to execute the simplest one of them, which was to stare it to death.

So every day, I would stare at the dog right in the eyes until I had passed the house. At first the dog barked at me like it had before. But in the matter of weeks its barks turned softer and then muted completely. My staring didn’t result in the dog’s death but it did the next best thing: the dog recognized me and didn’t bark at me anymore.

It was autumn then, and for the winter the owner kept the dog inside. At the start of the spring the dog came back to its guarding routine, but it didn’t bark at me anymore. I walked past that house to school for the next two years. Only once I talked to the owner of the dog. She said: “I wonder why the dog barks at everyone else and not you?”

That’s actually a good question. Obviously it was because of my looking the dog in the eyes, but what was the ultimate reason? Had I established that I was the master and it the servant? Or did it consider me someone familiar and of equal status, its pal?

I’ve come to believe the latter. When we look someone in the eyes, we acknowledge that they exist, are worthy looking at, and that we are not afraid. It is a good start.

Answer the Right Questions with Prototypes

Prototypes validate ideas. Rather than basing plans on guesses, you create something concrete and put it to the test. But what kind of a test? That depends on whether you are aiming for a sustaining or a disruptive innovation. The distinction helps us ask the right questions and build the right prototype. As a consequence we eliminate waste and create an effective innovation process.

I posted to Leonidas blog today: Answer the Right Questions with Prototypes.

Camelot is only a model

Sir Lancelot: Look, my liege!
[trumpets play a fanfare as the camera cuts briefly to the sight of a majestic castle]
King Arthur: [in awe] Camelot!
Sir Galahad: [in awe] Camelot!
Sir Lancelot: [in awe] Camelot!
Patsy: [derisively] It’s only a model!
King Arthur: Shh! [imdb]

Forbes has an article of Clayton Christensen’s recent keynote. It’s easy to read as a crititicism of profit maximization and business schools.

But they are not the real problem. The real problem is taking a model and thinking it is a precise description of reality. Every model has its limits.

The last thing we need now is blind following of a new model. As much as customer centricism and net promoter score are good things, profit maximization and ROI are still as useful as before. All of them are tools that help us understand the reality better, not replacements of reality. They are not more than that, but not less than that either.

Let’s not go to Camelot. It is a silly place.