Explicit Expectations Exercise
October 28, 2011
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.
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.
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.
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.
“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.