In my team we conduct a retrospective every two weeks. On each occasion, we try to keep things fresh and stop the same format from killing our ability to spot and discuss a growing problem.
We were inspired by a paper on rotational cleaning and how regularly changing your cleaning process avoids bacteria strains resistant to your standard approach becoming common place. Although our usage is very different, the same theory can apply.
We begin each retrospective with a game to help mix things up, keep us energised, and make sure we’re alert and learning. Here are some you can try yourself.
Dan wants a new car. Dan wants you to draw him his new car. All that he knows is he is looking forward to it and it’s going to satisfy all his dreams.
Take a whiteboard marker and design Dan’s new car for him.
Watch as the team make assumptions, draw incorrect conclusions, and only infrequently think to involve the original requester in the process. Maybe fast feedback and awesomeness come intuitively to you; I’ve a feeling for a lot of us this is something we have to remember to work at, hence this game!
How did the car end up? Was it exactly what the requester wanted? I suspect not, so highlight where assumptions were made and why they were incorrect. Ask the team what policies they could try out to make the next project a success.
For example, vague questions get vague answers. Try out a policy of deciding in the team exactly what is important to understand about the project, then be sure you get the answers you need to continue. A vague answer shouldn’t lead a team to decide (or assume) for themselves.
Did anyone ask if the requester liked the design before it was finished? Involve the requester in the design process.
Repeat the process. Now Dan wants a new house. Go!
We can all get a bit comfortable and complacent in our given domains, but it is important to remember that making assumptions about what a business user might want leads to a risk: the risk that the thing we build isn’t the right thing.
In my team, we found it did not come naturally to have an approach that restricted room for failure, so we decided it was a good idea for us to make feedback opportunities part of our standard process.
Definitely not the car of my dreams, despite the heart logo on the door which my team was sure I would love
Not far off the modernist home I would love to have – but what is with that fountain I didn’t ask for?
Whiteboard markers out again. The task is to draw up to five cogs such that the cogs’ spokes multiply together to make X.
There should be a phase for planning and estimating how long the task will take, and then someone has to complete the exercise while you time them.
These cogs would make 8 * 6 * 6 = 288
We played for various values of X: 128, 34, 71, 260, 437
So how did your team do at estimating the time it would take? Try to discuss how people did in each instance. For example:
We found it interesting to time how long was spent in the deliberation + estimation part of the task as well. Surprisingly, for a 37 second implementation task, it could take three minutes of deliberation before anyone even picked up a pen.
Estimation is tough! And estimates via triangulation aren’t always sensible. For instance, if people consider X=71 to be in the same class of problem as X=437 then they will scale up the time estimate and fail with disastrous effects. When we drew 437 spokes on a cog it became hard to keep track of how many we’d got up to, and the drawing had to start afresh at one point. Eventually fatigue set in and this cost further vital time that had not been factored in or considered.
As our team continued we found that, for numbers which were simple to factor, the team got more and more accurate at estimating. For more complex numbers we seemed to get worse. Often, this was because a big chunk of the work for more complex numbers was drawing a cog with many spokes (a cog with 437 spokes, for instance, because we couldn’t think of any way to factor that into smaller numbers). Yet even realising this we continued flip-flopping between vastly under and overestimating this type of task.
We have built up a good portfolio of fun games to play, to fill everything from 30 seconds to 30 minutes, but we would love to improve this collection. Share your ideas with us on Facebook, Google+ or Twitter.
Daniel Stoner, Senior Software Engineer
Daniel Stoner May 2nd, 2017
Posted In: Blog
We all know that what developers want to do with their time is write code, but in Logistics Planning we took a whole week away from that. So why? And was it really worth it?
I began working for Ocado Technology in October. In this short time we have moved from basic principles to build a big-picture overview of our product that the team understands and buys into, and which adequately meets the complex business needs. This is how we went about it.
Our journey started with a set of a challenges which included missing domain knowledge, new starters to the company, and the fact that the Logistics Planning was performed in a very large set of a complex Excel document.
We had to overcome these challenges in order to build a high level overview of our product and proceed with development effectively.
Additionally we did not want to replicate the existing Excel documents but rather provide a software product allowing users to perform the end to end actions. And just to make things more complicated, the development team is located in Krakow, potentially a real practical barrier when the business has its head office in Hatfield.
In order to build a mutual understanding of the challenges and to bring the development closer to the business, we organised a set of workshops with key users and the development team. Our goal was to create an environment where our combined brain power could be used to drive the product development, instead of relying on a single point of contact.
To start the workshop, we had to define the relevant group of people responsible for planning deliveries. During the workshop, Operations and Resource Planners explained how customer goods are delivered and planned. The business team highlighted the most important challenges and the frustrations during their day to day activities. Additionally the development team was able to ask questions to gain a better understanding of the problem domain.
Each workshop was finalised with a summary session, where the development team and I built a picture of the challenges. This included the processes that they are currently experiencing while using our systems, and the boundaries of what the system can do. When the set of workshop sessions were finalised, each development team member went for a half day visit at a CFC (our massive warehouses) to spend time with the planners, observe the way they work and experience their challenges.
The cycle of workshops took us a week, after which the whole team had enough confidence and domain knowledge to proceed with defining the Product Scope and Roadmap. The approach we took was to define a scope of work and concentrate on the end to end user actions and behaviour.
We kicked off our work on the scope with an aim to define and list all features and actions we thought our product should cover. We had a cycle of a sessions where the whole team thought of the functionality and reasons why we should (or should not) implement certain behaviours. The Product Scope brainstorm sessions focused on providing a product which would solve end users problems in line with defined product vision.
The whole activity took us three days. The outcome was: a set of updated mockups, a list of the features we want to provide, and a list of additional discussions and workshops we would like to have with the end users.
At this point the list (product scope) looked quite scary, so the next step for us was to define the strategy for our journey from the place we were, to the place we wanted to be. In other words we wanted to build a roadmap with backlogs which would allow us to build a great product.
To drive the evolution of our product, we needed to look at the prioritisation of features according to their value to end users. The key outcome of this workshop was to align our priorities and meet the needs of our end users. This process enabled us to divide the entire product journey for Logistics Planning into multiple phases.
Each phase would be finalised with feedback sessions with our stakeholders, therefore planning required us to define the goal of each phase, and the user experience we want to bring.
The whole set of roadmaps activities allowed us to build a clear vision for every phase, and proceed with the first.
We believe that the time was well spent. By fully emerging the entire development team in the problem domain, we have not only accelerated everyone’s understanding but have also evolved and matured the product vision.
Similarly, the scoping session allowed us to look at feature development with a focus on the product as a whole, bringing consistency and coherency to our product from a logical perspective.
Is this anti-agile? We believe the opposite: by having a strong vision and structure to our work, we believe that we will receive more structured and constructive feedback. Having goals and a clear strategy on how to achieve them will allow us to react to change and unforeseen challenges in a more meaningful way.
The reality is that we have software engineers, not simply ‘coders’; what we really love doing is writing valuable code. Sometimes the best way to do that is to take a significant break from the keyboard!
Lukasz Kucharski December 16th, 2015
Posted In: Blog
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:
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.
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
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.
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
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