Productivity and team size
What is the ideal team size? Many suggest seven people – give or take one. Small teams in my experience are more efficient and need less management oversight. Recently our Business Planning Systems (BPS) team reached 10 people. We started to experience a declining trend in productivity, so we had to rethink how we were structured.
But it was not just team size
Our productivity decline was not just limited to team size. We were also struggling with having applied an emerging design model, new requirement process, and a lot of new team starters.
What could we do?
I did not want to reduce the number of team members, we have so much work to do! I also didn’t believe the solution was to switch to a new Agile framework and I didn‘t want to split our product backlog. This left a few options to experiment with:
- One product backlog with two sprint backlogs and two teams
- One product backlog with one sprint backlog and two teams
- One product backlog with one sprint backlog and two or more self forming teams.
The BPS team lead had pondered on this for a while and together the decision was made to go with Option 3: one product backlog with one sprint backlog and two or more self forming teams. We ran the experiment for four months at the start our winter roadmap.
The difference with Option 3 was the team could form as many teams as they felt necessary to work off the one sprint backlog. For example, two teams equally split, two teams formed of six and four people, or three teams formed of two, four and four people. This also meant a change for the BPS team lead; he remains team lead but delegates more accountability to the team.
- Team is empowered to take action, without team lead and PO involvement.
- Cross skilling of team members increased. One sprint you might be working with Fred and Steve and the next with Larry and Barry.
- It was far easier to get new starters up to speed in smaller groups.
- We retained one weekly entire-team ‘grooming’, so everyone was familiar with the business requirements and backlog.
What we monitored
- Would teams always form into the same group to work on the same type of issue, thus impacting team dynamics and cross skilling?
- Velocity of work coming out of the team.
- Number and type of issues identified in retrospectives.
- Team happiness.
- Delivery to business and their satisfaction with outputs.
How did the model work?
- Velocity of work continued as normal.
- Commit-to-sprint backlog stayed as normal.
- At sprint planning Phase 2 the team discussed stories and how to structure itself to best service those stories. For example, three stories involve UI so group those, three other stories focus on refactoring, security and support so group those.
Now the team could decide who wanted to work in which group. It is the team’s responsibility to make sure there’s a) enough work for the number of people in that group b) enough people to work on the stories in that group.
What else to address declining productivity?
I mentioned it was not just team size affecting productivity, but also applying an emerging design model. By not focusing on future architecture for complex features, we were spending considerable time refactoring and make compromises. We decided to trial an opt-out-of-sprint option.
- A team member could choose to opt out for a sprint or some of the sprint, to focus on an issue.
- We would reduce our expected sprint velocity for the upcoming sprint, based on the amount of time the person would need.
- At the end of the time allocated the team member would present their findings to the entire team, and we would then make a number of decisions i.e. work on the issue now; work on it later; the solution didn’t work so look into an alternative next time etc.
- There is no restriction on how often a team member can take the opt-out-of-sprint option. In the last four months only two people have chosen to do this and both times it was very valuable.
What was the end result?
Success! This is now how we work. The team loved the new approach and productivity improved. Disclaimer, to my knowledge the team did not break out into dance moves like the below image, but I like to think they did…
To wrap up, we gained the benefits of working in small teams but also of moving as a collective towards the one overarching product vision. Job well done team!
Ali Major, Product Owner
Ali Major May 6th, 2016
Posted In: Blog
Agile, backlog, management, product owner, productivity, sprint, team size, teamwork
Is there more to a PO’s work-life than meetings? Meetings are critical to my role: gathering requirements, progress updates, scrum meetings, department future and town hall sessions, validation sessions, one-to-ones, post mortems, Q&A sessions, regular catch-up sessions, and the list goes on…
This blog will shed some light on different approaches to give those of us whose life is consumed by meetings some time to breathe. Wait – I’m not going to list all the reasons why I have so many meetings – don’t click away!
I can’t get through the day without my calendar. My life all day, every day, is meetings. I colour co-ordinate meetings based on products/context, hence the reference to a rainbow. Having time to do and think innovatively is compromised by meetings. People started walking with me to my next meeting just to get face time. This was the tipping point!
What to do?
I ran through a list of questions focusing on number of meetings, usefulness and output to create a number of experiments.
I blocked out recurring 2-3 hour time slots in my calendar for over a year. I labelled these Work In Progress (WIP). The purpose was to have time at my desk to ‘do’. I only told a select number of individuals what WIP meant and that they could book me in this time if required.
- Partial success
- Most people ignored the blocked time and booked meetings over the top anyway.
- I treated the blocked time as a nice to have. If someone needed a meeting I ‘had time’ and removed or reduced the WIP time slot. My bad…
- I was still context switching between my different products and projects within the day, which reduced efficiency and my ability to focus.
Automatic decline of meetings if they clash.
- Low success rate.
- I simply got a lot of emails asking me when they could have a meeting as there’s never time in my calendar. This meant I had to spend time working out when I could squeeze something in.
- Some meetings are more important than others. I prefer to be able to prioritise which myself.
Say no and complain a little.
- Low success rate.
- Same reasons as the outcome in Experiment 2.
- I felt better complaining a little as many others had similar situations. A common bond.
Experiment 4 – Trialling now
Combine Experiment 1 with additional blocking of other slots in calendar as specific context meetings.
These context meeting slots permit people to book me for meetings, but only about the specific topic in that window. For example on Wednesday I have four hours set aside where people can book meetings with me about external integration only.
- Trialling now. I need to make sure I don’t fall into the same trap as Experiment 1 where I treat this as a nice-to-have.
Is it the end to meetings?
No, meetings are critical for my role. I expect Experiment 4 will be the best solution for me. Not only will I have time at my desk, but I am not constantly context switching, and I’m sure this will make a massive difference to my wellbeing and productivity.
Other good tips:
- Only accept meetings with an agenda.
- Try to block meetings in chunks so devs and others have a good solid 2-3 hours at their desk, rather than one hour at desk, one hour in meeting, one hour at desk again etc.
- At my desk I am trialling focusing on a specific task by using a timer set for 25 minutes. When the timer goes off, I take a five minute breather. Then I repeat the process. I am also selecting every second 25 minutes to turn off my WiFi, so I get no incoming distractions from new emails.
Let’s see how it goes!
Any meeting-busting, time-saving tips? Let us know on Twitter please.
Ali Major, Product Owner
Ali Major April 12th, 2016
Posted In: Blog
effective organisation, planning, product owner, time management
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
In this blog I’ll show you how to create simple, easy-to-follow roadmaps for the whole team to buy into (and stick to!).
My roadmap philosophy is ‘plan to achieve specified deliverables over a defined time period. This plan is dynamic, and goal and data driven (measurable)’.
A few key points:
- My roadmap is NOT completed in isolation but involves other Data Department Product Owners (POs), the Business and my development teams.
- The Data Department roadmaps span a three month period (we call them seasonal roadmaps).
- My roadmaps must take into account: legacy, new development, and support across multiple stakeholders.
- It’s dynamic, kept up to date, and not hidden away.
Step 1: Time to think
In the month prior to the start of the new roadmap, I ponder what is it we should be working on to meet our Data Department, clients and Ocado Technology requirements. I create a draft and run it by my development team lead and the Business representative/s. This is all high level and, importantly, not the specifics of how we will do the work.
Step 2: Stop pondering, draw circles
After we, the Data Department POs, finish pondering, we schedule a circle session (I love this exercise). We each explain what we think we should be working on and jot this on a board in one or two words.
Where we have the same theme – for example, monitoring – we circle this with a coloured marker. Each colour represents one of our teams. We also discuss dependencies and mark these accordingly. At the end of the exercise we can gauge:
- Range of work proposed and if we are trying to cover too much
- Common themes e.g. we have lots of circles around monitoring
- How many of these themes are dependent on other teams
Step 3: Finalise and socialise
Next is to tweak and socialise the draft roadmaps with the development teams and relevant stakeholders.
During the finalisation process I do four more very important things:
- A retrospective on how we performed against our previous roadmap, and what lessons-learned we should concentrate on during this new roadmap.
- Story Mapping to break into epic and stories, the ‘how’ of achieving the goals and features (the Post-it note company must love the take up of Agile…).
Once I have prioritised the themes, the team then rank the epics and stories into order for working on. Then we estimate time based on a comparison to other epics.
I disagree that this is a non agile approach. They are very rough estimations, done quickly. We will in the future groom the epics and stories to a Ready state when we get closer to needing to work on them. The estimation provides us with an idea of what we reasonably think we can commit to on this roadmap, for example we are asking the question can we do story C within the three months taking into account story A and B?
Lastly we jot down story acceptance criterias AND we play some games throughout the process. I suggest Pictionary as it lets you know who not to work on your UI!
Sometimes I am in the difficult position where I know one of our key features is lacking detail to adequately break into epics and stories. And if it’s not clearly defined, we shouldn’t work on it, right?
In reality, sometimes you just need to get on with it, so below are approaches I’ve taken in the past to mitigate the issue. Remember to always keep the stakeholders in the loop, and the team must agree.
- Add feature to roadmap and allocate a percentage of time during the three months. We postpone breaking the requirement into epics and stories until I have the missing information. Then we storymap, estimate what we think we can fit in, and update the roadmap because (repeat after me) the roadmap is dynamic.
- Add to roadmap with target metrics but agree between all stakeholders that this may not be achieved. As more information comes to light we update the roadmap.
- Leave it off the roadmap, with stakeholder agreement to add it to the next roadmap instead.
A dynamic roadmap should not mean mission-creep
By ‘dynamic’ I mean it stays relevant. It is a living document and kept up to date. I use the roadmap as a tool to push back, but I don’t become inflexible. The highest priority tasks can always be done.
My roadmap means I can identify the opportunity cost (e.g. feature X won’t be completed), and I can measure what changed and what was impacted during and at the end of the three months. It is a balancing act.
What’s crucial is communication, communication and, one more time, communication. I make a call based on discussions with senior managers, the business and the development team. It is also imperative that once the roadmap is updated it is socialised again.
Only three months? What about the long term vision?
Focusing on longer terms goals, but delivery in small chunks with metrics to measure against, works best for us. It allows flexibility where technology or goals are shifting.
I know many disagree that a roadmap should be less than six or even twelve months. It’s important that my roadmap goals are linked to the Data Department’s long term roadmap or the long term Business requirements. Both my products and the Data Department have far reaching vision statements, so we know if we are heading down the wrong path.
What my roadmap looks like
I use Roman Pichler’s Go Template. It is simple and doesn’t come with preconceptions like a Gantt chart does.
I was so proud when, for the first time, I could cut and paste directly from the Data Department long term goals roadmap into my seasonal roadmap! It seems for many POs their roadmaps don’t have a direct correlation with the next level above, or the level above that etc.
Roman Pichler source on roadmaps: http://www.romanpichler.com/blog/working-go-product-roadmap/
To wrap up
A roadmap is a great tool, but you need to find what style and process works for your team. Keep it dynamic and refer back to it each sprint planning.
Measure your success and enjoy crossing out deliverables as they are done.
Ali Major, Product Owner
Read more Product Owner advice from Ali
Ali Major January 5th, 2016
Posted In: Blog
data, organisation, planning, product owner, strategy, teamwork
I find that people put an overwhelming focus on product innovation, but not necessarily on innovative approaches to capturing those novel ideas. With this in mind I decided to focus my efforts on finding a new way to stimulate idea creation for our team.
I knew I wanted to actively pursue a 10x product, and that my stakeholders would be significant contributors. The challenge, as a product owner, is to find time to work on 10x ideas whilst delivering vital business functionality which will translate to considerable cost savings. Achieving both is tricky!
The aim of this blog is to touch on the approach and the balancing act.
I involved 10 people: key business users, the development team, our department development manager and, of course, myself.
I positioned us in a circle and explained the aim of the game using a whiteboard, plus the process:
- Write down your game changing idea for our product on a piece of paper – this is an “Idea Stimulation” card.
- Pass this Idea Stimulation card to the person to your right.
- That person adds to your idea or, if it sparked other brilliant ideas, they can write those down.
- Keep passing to the right until everyone has contributed to each idea.
- One by one present a summary of what the ideas were.
- Group the ideas, discuss.
It was a wise move to secure buy-in and present the findings to our business department head. This session gave him the the opportunity to add his ideas and become emotionally invested in the product.
The challenge to balance immediate needs whilst working towards a 10x product meant it was critical to step him through the roadmaps. The roadmaps were for the next three months and the planned feature list for the next twelve months. The aim for us was to think about when we’ll be able to work on 10x.
Although I posted a BPS 10x presentation on our Google Site, I know it will become out of sight and out of mind over time. To keep the inspiration alive I am visualising the information in a physical space in the team area. The beauty of this is that the team and other people in the office can continue to add ideas.
This is my wall design, nothing beats a napkin drawing…
At the start of next roadmap I plan on running a dot voting session to decide what we can implement now, medium and longer term.
I also socialised the process and ideas generated with other teams and managers. I hope this will produce some more product changing ideas or inspire other teams to run similar sessions.
Lessons learnt and feedback
- Introduce your product vision statement at the start of the exercise. If you don’t have one, create one!
- Use a timer (start with one minute and increase mid way to two minutes to allow time to read the growing list of contributions). It’s best to use a fun sound when the clock ticks down to 0. I like animal noises, but perhaps movie one-liners might be your preference.
- Don’t worry if Jack and Jill have the same or similar originating idea; remind people you can add a new bright idea during the process.
- Draw pictures to illustrate your ideas…
- A few people added jokes from time to time. This was amusing to watch as people one by one laughed out loud when they received the Idea Stimulation card.
- Thinking of an idea to begin with can be challenging. It’s best to allow additional contemplation time at the start.
- Participants tended to add to the original idea, and not add a completely new one. A participant may have had more than one great originating idea but this may not have been captured. So, think about a way in which people can add ideas later on for example the wall I’m using in my team area.
Switch up your approaches to gathering information, for inspiration read the Gamestorming book or check out their website.
Look for queues to see if the session is going OK and adjust where necessary. Add to your next retrospective to check if people found value in the session.
Managing stakeholder expectations is vital. If you are like me and have challenging deadlines make sure key stakeholders know of the tradeoffs and work together to create an approach to build in innovative design.
Inspire stakeholders, and potentially others who did not have the opportunity to participate, by socialising and providing a mechanism to capture feedback.
Ali Major November 13th, 2015
Posted In: Blog
gamestorming, ideas, innovate, planning, process, product owner, product ownership, teamwork
In my first blog post I illustrated the many factors to take into consideration when building a cohesive team. This time I want to explore the technology available.
Can you make do without technology in building an effective non-collocated team? For me the answer is yes. But would that team be as effective and could the quality of relationships be formed as quickly? I’m not convinced so.
What technologies I use and when
Working in the age of technology affords us the luxury of numerous online communication tools, both paid-for and free. So which to choose?
The ease of interaction and responsiveness is the ultimate measure. It shouldn’t feel like a hassle to keep in constant contact with the teams during the day, and this is crucial to being able to build that successful team.
In fact, online communication tools have become such an ingrained and easy way of working that I feel more put-out having to leave the comfort of my desk to walk to meetings in our other two adjacent buildings.
So here are the online tools I use and why.
Smile, you’re on camera
Don’t be shy, don’t be a voice from afar, and don’t try to hide in the back of the room.
I highly recommend conducting all meetings with an offshore team via video conference. People receive information better when they have more than one way in which the information is conveyed. Being able to see and hear is a vast improvement to staring out the window whilst on a phone call.
It may seem a little awkward to begin with, but you get the chance to pick up on visual queues: a smile, a frown, a blank stare. Remember to move once in a while – a nod will do – as on more than one occasion I’ve thought the connection was hanging when the team was sitting extremely still!
There are numerous free options such as Google Hangouts and Skype, and paid-for services such as GoToMeeting and Avaya Scopia®. I would recommend investing in any tool that permits screen share and the ability to have multiple parties on a call.
So far so obvious but, despite some arguments against relying on email, it remains wonderful for a record of conversation, lengthy discussions and non time-sensitive communications. (Of course, if an email chain is going back and forth, back and forth, consider whether a video call would be better to discuss the topic.)
What I will mention though is, when setting up folders, apply the ‘can I answer this in under one minute?’ rule to use your time most effectively.
Quick chat versus fluid conversation
Chat rooms or message services like the Google Hangout chat feature, which sync across devices, have worked well between stakeholders, my teams and myself.
My teams know that if you need a quick response to a question then Hangouts or Slack are best. Chat rooms address many of the shortfalls of online message services, especially where you can subscribe to groups. Until we started using Slack we tended to have many one-to-one chats using Hangouts. The downside was that the individual had to relay everything to the other team members.
Team chat rooms have provided a mechanism for fluid conversations, and I love that we can subscribe to specific topics of interest from within other areas of the business.
If you can find a chat service that allows you to search previous conversations I would highly recommend it, as it’s very useful in the age of information bombardment.
Keeping up to date
Our teams needs to know about changes, latest tools and processes, business objectives and so on. We rely on Google+ and recently Slack, in which users can subscribe to specific communities or channels.
Google Sites tends to be where we maintain product and/or team specific pages. Flipping this around, my teams and our Product Owner community can also leverage Google+ to create our own communities as a way to reach stakeholders within our business.
I am a massive Atlassian fan (yes, I even have the t-shirt) and use Jira for backlog management and visualisation of our workflow.
There are many other great reasons to use Jira, for example tracking stories levied on other collocated or non-collocated teams, versioning, filtering, metrics and keeping stakeholders up to date at anytime during the day. We also use Jira as a tool to facilitate scrum ceremonies.
I would strongly suggest you display the team board on an additional monitor where the team sits. This way you still get the benefits (though likely on a smaller scale) of a physical board.
There are of course other online tools for managing backlogs such as Trello and Scrumwise. Still, personally, I like Jira more.
Last but crucial point
Technology is vital, but only as a means to achieve this goal: to become an effective team.
It does not remove the need for physical interaction and, as previously blogged, your intentions and resulting actions are more important.
And, dear reader, don’t forget the fallback position when that internet connection is slow or your company doesn’t support certain communication tools… pick up the telephone!
Ali Major June 19th, 2015
Posted In: Blog
communication, office life, product owner, product ownership, 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