Explicit Expectations Exercise

Assumptions is the mother of all … flurps.

I would say that the majority of our failures in cooperation and  collaboration arae due to assumptions. We also fail largely due to poor or lacking communication but this is based on an assumption that we don’t need to communicate in order to succeed.

I’ve seen so many problems arising from people making assumptions about other people. We prefix a lot of our statements with “I think that … ” or “I believe that …” and yet we continue acting based on the statement that follows. What is up with that? Shouldn’t the words “I believe …” raise a warning flag so red that it would have brought a tear to Karl Marx’s eyes?
My suggestion is that whenever you hear yourself or someone else utter words to that meaning, you should challenge yourself or the other person to validate the assumption.
I use those words all the time and I want someone to challenge me since that will provide me with great opportunities for learning.

When it comes to teamwork, I find that a lot of assumptions take the form of implicit expectations. We expect people around us to behave in certain ways and we assume that they know this and that they will act accordingly. This is a breeding ground for bad feelings and even less communication because we often attribute peoples failure to live up to our expectations to spite on their part. In an attempt to lessen the frequency and impact of these hidden assumptions I’m designing an exercise to help make our expectations more explicit. I’ve only run it a couple of times so far and have updated the format every time and I welcome any and all suggestions for improvement that you might have but I will describe the exercise as I plan to run it the next time.

Part 1:
I begin the exercise by creating columns on a whiteboard, headed by the different roles in the project; project manager, product owner, ScrumMaster, developer, tester etc. I’m aware that Scrum only prescribes three roles but the goal of this exercise is to make things explicit, not wishful thinking. I also ask a representative for each role to act as secretary for the second part of the exercise. I then hand out pens and Post-It notes to everyone present (all roles from the columns need to be present for the exercise to be meaningful). Then everyone gets to write down their expectations on the different roles on the Post-It’s, and post them in the column for the role they have expectations on, as they write them. The expectations are written on a format similar to user stories;
“As a ‘role‘ I expect ‘another role‘ to ‘fulfill some expectation‘ so that ‘some benefit will occur‘.”
I might for example post the following expectaion in the Product Owner-column:
“As a ScrumMaster I expect the Product Owner to be available for the team members at all times during the sprint to answer their questions about requirements so that they don’t have to guess what the customer needs.”
I give this part about 10-15 minutes or stop it when no more notes are being produced. People usually need some time to think during this exercise and they tend to write during the time available.

Part 2:
Then I go through role by role and note by note, asking for clarifications if needed, and also asking the representative(s) for the role if they intend to live up to the expectation on the note. I will ask the secretary to take additional notes from the discussion. Usually people want to live up to the expectations but not without clarifying what is meant;
“What do you mean by ‘at all times’?” and “What do you mean by ‘available’?“.
Sometimes the expectations are off, it can be a project manager expecting team members from a Scrum team to report progress to him or a developer expecting a product owner to add every technical story they can come up with to the backlog. The discussion around these expectations is really important because it will clarify and set boundaries. It will validate or invalidate assumptions. I have found that for a group of 15-20 persons this part of the exercise will take about one hour if it is heavily moderated. Make sure that you have enough time for this discussion because this is an investment that will pay for itself.

Part 3:
After the exercise I ask the secretaries to take home and rewrite the accepted expectations as a contract, with any clarifying notes from the discussion added. The expectations should be turned around and rephrased as commitments.
For example:
“As a Product Owner I commit to be available, at least by mail and phone, five days a week for the team members, to answer their questions about requirements so they don’t have to guess what the customer needs.”.
The contracts are then to be signed or at least acknowledged by everyone representing the role.

The main goal of the exercise is not to produce contracts but to bring out as many assumptions and expectations as possible into the light. The contracts are just reminders about the exercise and a way of repeating what was agreed upon one more time after everyone has had a chance to digest the exercise.

This exercise can be done as an activity at the beginning of a project as well as later on if you experience communication issues in your project and suspect that they might stem from hidden assumptions. If you run this exercise, please share your learnings here so I can continue to improve it.

You can’t stop people or yourself entirely from making assumptions but you can tell other’s about yours and you can as them about theirs.

MoSCoW Prioritization Poker

Today it felt like I had one of my brighter moments. Sitting at my new client, faced with a backlog way too long to implement in the time available to us, I had an epiphany. We needed to prioritize the backlog and get a first shot at a release plan in a two-hour meeting.
“How about prioritization poker?” The words jumped out of my mouth before I had even considered what they meant.

Let’s jump ahead a couple of hours now. “My” idea about prioritization poker would most certainly be worthy of a blog post so I started writing it in my head on the subway back home. Then another thought hit me, almost as hard as the one earlier today; wait, this was too obvious, I might not be the first one coming up with this idea. And sure enough, some googling told me that this guy called Mike Cohn had already invented prioritization poker. C’mon Mike, you already have so many other things going for you, couldn’t you’ve let me have this one? Anyway, so what if my idea wasn’t unique? I think we had a little different twist on it and it proved to be quite useful and thus I’m still going to write this post.

Back up a couple of hours again.
“Prioritization poker? What is that?” My colleagues gave me weird looks.
The words kept pouring out of my mouth faster than my brain worked; “I guess it’s like planning poker but you do it with MoSCoW instead of numbers or t-shirt sizes. Do you want to try it?”
“Sure. I have a planning poker deck in my bag.” One of my colleagues replied.

So we picked out the 0, 1, 2 and 3’s from the deck.
“0 is Won’t, 1 is Could, 2 is Should and 3 is Must. Kay-O?”

Our product owner read the first story out loud and we began asking for clarifications. After a couple of minutes it was time to play our cards. We had 1 and 2 and 3. Certainly a difference of opinion. After a short discussion where the extremes put their views forward we played another round. All 3’s! On to the next story.

After one and a half hours we had gone through the entire backlog and managed to divide it into almost equal chunks of Musts, Shoulds, Coulds and Won’ts. The remaining half hour of the meeting was spent putting all Musts into the first version of a release plan.

Wow! I’m very familiar with the power of planning poker but this was a new experience for me. Using the poker format brought our assumptions out to be examined and corrected when necessary. We managed to align our views on what needs to be done and to get a common understanding of the requirements. Whenever I felt safe about understanding a requirement someone challenged my view by questioning the meaning of a certain phrase or a specific word. This kept happening until we narrowed the description down to something everyone could agree upon.

Using MoSCoW for the prioritization also proved to be a good idea. At first I thought I had made a mistake by not including the “?”-card in the game. Some of the requirements didn’t make any sense to me and I had no idea what prio to give them. Then I realized the power of the values in MoSCoW. When we got to the first story that I was clueless on, I thought about digging out a question mark from the poker deck on the table. But then my wheels started spinning again and I gave it a 0 … a big “Shazbot! We’re not doing this.”
The others who considered the requirement a Should or a Must looked at me like I was crazy again.
“No, we’re not doing this requirement until someone can sell it to me.” I said.
And they began explaining the importance of the requirement until I understood it and could agree on its’ importance.

This exercise also showed me how important it is to force people to take a stand. There’s a huge difference between prioritizing in a continuous range from 1 to four, or from low to high and if you’re using a scale that includes “Won’t”. If you give something “low” priority or a 1 on an importance scale, people are still left with some hope that the requirement might be implemented and they will with great certainty be disappointed when they realize that it’s not happening. If, on the other hand, you tell them that the requirement is a “Won’t”, you’re effectively telling them that this is not going to happen unless they manage to get it reprioritized. People are forced to come to terms with reality a lot sooner or to take responsibility for making an alternative reality happen.

This was my first experience with prioritization poker and it was a good one. It proved to be a great tool for our context today and I’m pretty sure that I will use it, or some modified version of it again.

Na-Nu Na-Nu!

Making Decisions Tentative

Decisions, sometimes hard to make, but we do need to make them and we do need to live the consequences of them. Some decisions can be changed along the way and some are irreversible but almost all of them are made without full knowledge about the problem. Waiting for full knowledge would leave us stuck in limbo though, because we will never gain it.

When we make a decision, no matter if it’s irreversible or not, we should not make it final. We need to leave a backdoor open for learning to enter. Making a decision final is when we invest so much prestige into it that we’ll stick by it even when we know better, or when we refuse to accept better knowledge even to ourselves.

We need to keep making our decisions and to keep standing by them as the best we could do at the moment, but we should make them tentative in the sense that we’re willing to learn and admit that we’d do it differently the next time around when we’ve gained new insights.

Throw Out Quality – And Tell Me What You Really Want

In an open space session a couple of days ago, a colleague of mine said that we’re using the word quality a bit carelessly. I’d like to go one step further and say that it is a careless word. It is a careless, sloppy, non-specific word that leads to careless decisions and sloppy measurements, and I want to take it out back and put it to sleep.

We have pondered the question of what quality is for years and years. A number of smart people have come up with several good definitions of quality such as:

• Fitness for use
• Meeting and exceeding customer expectations
• Satisfied stakeholders
• etc …

These are all fine but they’re not very precise. Quality seems to be almost synonymous with “good”.
“Yes, I’m with the good assurance department. We make sure that the level of good in the product is at an acceptable level.”

Of course we want to make sure that our product is fit for use and satisfies our stakeholders but that won’t happen unless we become more explicit. What happens though when we use such a sloppy word is that management gets a non- or at least ill-defined parameter to negotiate with and to measure.
“At this point we must let costs take priority over good.”
“How is the good coming along in our product?”
“What KPIs do we have for measuring good in our product?”

I’m sorry, but I won’t answer one more question regarding quality from now on. You will have to be a lot more specific if you want to know how good the product is. If you want to know about usability, you will have to ask me about usability. If you want to know about maintainability, you will have to ask me about maintainability. If you want to know about errors in programming, you will have to ask me about errors in programming. I will probably keep probing even more about what you want to know and why you want to know it, but if you ask me about quality again, my answer will be … 42.

“So tell me what you want, what you really really want” – Spice Girls