Communication is important. Not just for a Product Owner, but the whole team. Especially if it’s not a collocated one.
Here is an excellent test for your team: a fun exercise that will uncover communication issues that nobody was aware of.
- Time needed: 45 – 60 minutes (30 minutes for the exercise + time for discussion).
- Number of people needed: 4-6.
- Divide the team to 3 groups.
- Groups A and C go to different rooms.
- Group A gets a picture only they are allowed to see (a childlike drawing works well).
- Group C gets a pen and a sheet of paper.
- Group B, called ‘Runners’, stays with group A for now. Their task is to communicate between Group A and Group C.
- Communication exercise-01
How it works:
- Group A and Runners discuss what’s on the picture. Runners can ask any questions they want, but they can’t see the picture and they can’t take notes. Group A can see the picture at all times.
- Runners move to Group C and convey the information.
- Group C draws a picture based on what they are told. They can ask additional questions about anything.
- Runners come back to Group A to ask for more details.
- Steps 2,3,4 are repeated as many times as needed until the time is up.
- The person facilitating the exercise should spend some time with each of the groups, silently observing.
- At the end, ask the teams how well they think they performed.
- Show both pictures to everyone and discuss. What went well? What could be improved? Any actions?
Some things to pay attention to:
- Does the team start with the big picture or the small details?
- Does the team optimise the way they work during the exercise?
- Is the team aware of time and how fast they are progressing?
- Is the team focussing on the most important elements?
- What assumptions are made?
How my team performed:
Drawn by the team
What we observed:
- The team jumped straight into details. Only 10 minutes into the exercise did they discuss the proportions of some key elements.
- Runners split after the first exchange to save time. They didn’t, however, communicate between themselves, which meant they asked the same questions twice. Surprisingly, they sometimes got different answers to the same questions, which required extra communication.
- Group A also split, so they could deal with Runners separately, which resulted in one member not knowing if the horse was going to be present on the team picture at all at the end of the exercise.
- The team didn’t plan the execution for the time given. This caused rushing at the end and asking for extra time to complete.
- Some key elements were described in detail, while others were very basic.
- An assumption was made that characters on the picture sit at a table. It was quite quickly rectified though.
- The overall result was good, but the team didn’t think so.
- The team enjoyed working together and want to repeat the exercise in a few months to see if they can perform better.
- The team is proud of their work.
It was definitely great fun and a good learning experience for the team. Try it yourself.
For more ideas about communications in non-collocated teams, see Ali’s posts, and check out my own blog for more product ownership ideas.
Thanks to my colleague, Lukasz Kucharski, who introduced me to this exercise!
Anna Miedzianowska, Product Owner
Anna Miedzianowska January 26th, 2016
Posted In: Blog
case study, communication, effective organisation, management, product owner, team building, teamwork
My team designs tools for our delivery drivers. We were pretty confident we knew the challenges they faced and the solutions they needed. But what if we were wrong?
Here’s how we made sure our products actually make their lives better!
We started our research by shadowing users. All team members spent a whole day working with the people who are using our product – internal users – our delivery drivers. It wasn’t training; we were actually helping the drivers deliver shopping to real customers.
We learnt a lot that day: about the users themselves; about the delivery process and how it is really handled by the system we provide; and a bit about the customers. We felt like experts for a while, even though it was very limited qualitative research.
We decided to put our expertise to the test and invited an experienced user to a workshop with us…
Our first task was to reverse our roles (kind of).
So, this is your job:
We asked Mike-the-user to pretend it was his first day on the job, even though he’s really spent the last 10 years doing it. All he was supposed to know was that the role involves delivering goods to customers.
Next, we asked the dev team to pretend to be his line managers and explain the job to him, step by step. Mike was a curious student, so he was allowed as many detailed questions as possible.
It started well, but very soon we got corrected: nope, that’s not how it works…
We were missing details, got some procedures mixed up and couldn’t answer some of the questions, even about our own system! We also discovered how our system can be misleading if things go wrong.
We are not on the same page
We now know that even by shadowing users, we can still misunderstand things. Especially if things go well during the day, we can’t see the whole range of issues our users face. Also, we are more likely to believe that any problems that occurred during our experience are happening more often, when in fact, they might be statistically rare.
So we are not on the same page. And we will never be. But that’s ok, we are very different people and have different skill sets – that’s why we have different jobs.
What we should do is work towards minimising this gap by educating ourselves about the users, and also educating our users about our job when possible.
- The meeting is more engaging for everyone
- We actively think about the process (as opposed to passively listening about their job)
- Misunderstandings are spotted quickly
- We build a relationship with users
Try it yourself – explain to your users what their job is. You will discover a lot of surprises.
Anna Miedzianowska, Product Owner
Read more about product ownership on my blog https://productownerblog.wordpress.com/
Anna Miedzianowska January 8th, 2016
Posted In: Blog
product owner, team building, teamwork, testing, user research, workshop
One of our largest areas recently undertook a revolutionary self-selecting restructuring exercise, the goal being a complete split between teams working on two different propositions. The overall aim of this split is to achieve greater alignment, autonomy and purpose.
Following the principle that a collaborative and distributed approach is often the best way to solve a complex optimisation problem, we negotiated moves amongst the five new teams subject to a set of constraints around team size and experience levels.
The plan going into the event was shared well ahead of time to allow people to get their questions in (and added to the FAQ section) and the concepts clear going into the day. Alongside this, we ran multiple townhall sessions where people could air their concerns and ask their questions openly. There was a certain amount of ad-libbing and practical adjustments on the day, but on a whole it unfolded according to the plan.
Fuelled by 18 pizzas, we completed three exhausting rounds of moves and peer voting. At the end of each round, we (everyone, including POs) voted on the viability of each team. From this we measured two scores: an intra-team score, and an inter-team score. This lead to a few interesting dynamics, for example one of the teams gave themselves a high intra-team score, but scored low on the inter-team vote. They then gave a pitch justifying their viability as a team, and were able to dramatically increase their inter-team score in the next round.
The first round was deliberately suboptimal, hence dramatically lower scores. This was to encourage a large amount of movement in the following rounds.
Essential to finding a viable solution was an appreciation from all of the ‘greater good’ of Ocado Technology. On the day, some people made some really big compromises in order to serve the greater good and allow us to form balanced teams that are all capable of smashing out quality software.
After the final round of voting we then took a quick anonymous happiness reading by each dropping a green, yellow or red lego piece into a box. Although they were not perfect, we were extremely pleased the results, considering that our original goals was “at least 50% happy”.
We will be keeping a close eye on the impact of the shuffle-up by measuring the things that matter most to us: throughput and team happiness.
In terms of the solution itself: I am delighted. Every team has a reasonable level of experience whilst a healthy number of people have chosen to change domain. It is a vastly better result than I could have hoped for had we chosen a top-down approach.
The very next morning we did a big-bang desk move:
James Lohr, IT Head
James Lohr November 26th, 2015
Posted In: Blog
collaboration, culture, office life, team building, teamwork
As a Product Owner working with a team across two different countries, there are lots of problems to tackle to make sure projects run smoothly. In this series of blog posts, I will explore how my team and I have overcome issues.
For a bit of background info, I’m based in Hatfield and my colleagues in Krakow. We use Agile. In this first blog, I’ll explain how we work cohesively even though we’re miles apart.
Is the structure You + Team, or are you part of the team?
Let’s not beat around the bush, you should be part of the team, so don’t treat your team as anything less. And to be frank, you cannot be part of the team when trust has not been established and you have not invested in building relationships! You’ll just be the PO who is nominally part of the team because Scrum says you are…
Building a solid relationship takes time and I have tried many different ways with varying success. What works for one team does not always work for the other so re-evaluating this continually is very important.
So what were some of the things that have worked?
Communication is a potential hazard, so I made a deliberate effort to ensure that we communicate regularly i.e. every 1-2 days either on a work or social level.
To begin with I focused heavily on communication with the team’s leads. As time passed I began to find ways to engage more and more with the team as a whole. It is easier to just keep going back to the one person, but this approach hinders your effectiveness in the long run.
Why? Well you end up relying on that one person and at some point they go on leave; also information is double-handled as they relay everything back to the team. Finally it reduces overall interaction with the team, which you need to build a solid working relationship.
Show positive attitude and willingness to build a cohesive team
Don’t underestimate how much your mood and choice of words are perceived via email and hangout. If you are strictly business every time you talk to your team and seemed rushed or disinterested, then it is only fair the team reciprocates.
Regular visits to Krakow
After numerous visits of varying length, we came to the conclusion that it is best to not nick off as soon as your agenda is done. Spread your agenda over an extra 1-2 days and mix your time there with meeting your agenda and with normal day-to-day business.
Just being there to be asked a simple question, to go for lunch with the team, to contribute to Agile ceremonies… ahh nothing beats the luxury of walking over to a teammate to ask a question once in a while! Also it challenges the perception that you are just flying in and out for your needs, and shows that you value time with the team.
I love games and I play them when I am in meetings in Krakow as well as from Hatfield on hangouts. Taboo, Pictionary, Charades, trivia, true & false, riddles…
Why? Games remove the perception ‘we only communicate about work content’. It can help a team to learn more about each other i.e. ‘I come from Australia so – true or false, dear reader – I have been bitten by a brown snake?’ Games makes meetings more fun and they can relieve tensions during heated and/or vigorous discussions.
I attend all the prescribed scrum ceremonies with the team bar the daily stand-up. The reason for not attending the daily stand-up is that, with daily interaction and the ability to track progress of tasks moving on the JIRA board, I have enough information on what is going on and any impediments. Also it’s easier for the teams to do their stand-up in Polish and this is meant to be a quick meeting.
Should I learn Polish?
English is the first language of our organisation. For my Polish to be at the same standard as the team’s English I would need many years of study. If you know me and have heard my attempt at Polish (or any language) you would probably come to the conclusion that I shouldn’t push it!…
I firmly believe making an attempt is appreciated, but in my situation investing time in developing my technical knowledge is time better spent.
Sometimes in our meetings it is easier for the team to discuss technical details in Polish. I would encourage this as being acceptable, but that this is not the norm and they need to re-summarise in English what the discussion was about.
Ali Major April 17th, 2015
Posted In: Blog
Agile, communication, office life, product owner, product ownership, team building, teamwork