Monthly Archives: October 2016

Working effectively in a distributed team across Australia, China and New Zealand

Modern IT team environments are not what they used to be. Often work is outsourced to various locations both onshore and offshore, or a mixture of both. Recently I’ve been working in an Agile environment, in a team which has people dispersed throughout Brisbane, Sydney and  China, plus stakeholders in Brisbane, Melbourne and New Zealand. There have been a number of challenges that come with working in this kind of distributed team.

Firstly, we’re not all together. We’re not able to have hallway conversations or go out for drinks after a tough day. We can’t set up a physical wall that we can all see, or gather around a whiteboard to sort out a complex design logic. We can’t celebrate our successes with a shared cake, or bond over chit-chat about our lives.

Next, the time zone differences. Between New Zealand and China, there is 5 hours difference. New Zealand operates 2 hours ahead of Brisbane, Brisbane is an hour behind Sydney and Melbourne because of daylight savings (don’t get me started on whether I think South-East Queensland should also have daylight savings), and China is 3 hours behind Brisbane. This makes for almost impossible meeting planning, given there is only 3 hours crossover between the extremes, and everyone has to have lunch at some point.

Then there is the fact that it’s impossible to keep track of who is talking to who, since everything is online and hidden. Side-discussions happen all the time. My product owner is going to talk to my dev, and my tester is going to get a call from my project manager. It can be a good thing, as it shows a strong network across the team. However I’ve found it’s important to come together regularly and record decisions publicly so that people aren’t repeating the same discussions, and the “but mum said” situation doesn’t happen.

Another challenge was learning to communicate with my Chinese team mates. I’ll be honest, the first few weeks I was gripping the edge of my table with frustration, wishing I could hang up the phone and run away to a tropical escape where I didn’t have to try to communicate with anyone. But over time, I learnt how Chinese people speak English, and I started to understand their accent. This just took time.

These are just a few challenges that I’ve faced – there are many others too.

So what can we do to improve the efficiency of the team given all of these challenges? Here are my…


Come together regularly

Daily stand-ups can be set up for 10-30 minutes at the same time every day, and they are best conducted over a video conference where you can share your screen with everyone. This allows everyone to view the team’s backlog together. I’ve taken to leading the discussion using my facilitation skills, as my team seems to appreciate someone taking the lead. I’ve adopted a “round the table” approach where I nominate one person at a time to give their updates and comment on the progress of their JIRA cards. You may like to share the facilitation – it all depends on what works best for your team.

Most days we use the full 30 minutes for the 8 of us to give our updates as well as discussing some work in-depth. Other days we only use 15 minutes for the 8 of us to give updates. Sometimes we finish our updates early and a couple of people stay on at the end to discuss a subject in-depth which doesn’t need everyone to stay on the call. Either way, having a window for open chatting time has been invaluable for our team.

Book in daily time for Business Stakeholder sign-offs and UAT

When we started out, our JIRA cards were taking a long time to get from dev to complete. Like an iteration long. Often simple cards would be finished in a day or two, but they never made it to the “complete” column until the day before the iteration ended. This was largely due to the business stakeholders not being available for demos and sign off. We decided that we needed to adopt another regular meeting – the daily scheduled shoulder-check. This was a scheduled time for devs, testers and the business stakeholders to review a built piece of functionality together. We keep these to 15 minutes, at a time when the time zones of all stakeholders align. And the proof was in the pudding – our team went from completing 60 points per iteration to 100 points, which resulted in a much less frustrated team and some very happy stakeholders.

Use an online tool for estimation

One of the problems the team faced during estimation was that people tended to follow the estimates of whoever estimated first. This meant we generally had one person setting the estimates for the majority of the cards, and we had very little discussion about why that estimate was chosen. This was great in that estimates were done very quickly. But it was bad in that they were often revised mid-iteration because the devs didn’t fully understand the card prior to starting work on it. There was also no debate or discussion happening between people with differing opinions, which is needed to bring out a deeper understanding of the requirements.

I knew that a common tool to combat these problems was planning poker – a deck of cards with Fibonacci numbers that team members could use to “reveal” their estimate all at the same time, to ensure no one copied each other. But how could we do that when hardly anyone was in the same room? Bring on It’s fun, easy, and it works. Problem solved. Sure our estimating time doubled, but our re-estimating reduced considerably and the extra discussions we have during the estimating session reveal some very useful information.

Use an online whiteboard for quick drawings and group discussions

I’ve also learnt to use an online whiteboard, which is included with our corporate instant messaging app. This is great when you need to do a quick sketch of some system logic or a UI component. Drawing a quick picture can save many minutes of explaining in words, and often it results in a much better understanding. Quick sketches are so useful that they also often end up being added to a JIRA card or other documentation!

Use at least two forms of communication to get a message across

When team members speak different native languages and come from different cultures, as well as being connected to a meeting via a crackling Skype connection, messages and meanings often get lost. It’s important to not only rely on talking as the only means to ensuring people understand. Even repeating what someone said to ensure you understand the meaning isn’t foolproof. The best way I’ve found to ensure the meaning is understood is to use two communication methods together, such as visual and discussion, or a drawing plus text.  For example, use an online whiteboard to write meeting minutes or action items during a discussion. Or draw a picture and note down some key words next to it. Give people as many different avenues to understanding as your creativity can muster.

Confirm key decisions on a formal, public media

With everyone being in different locations, and chit-chat being mostly via our online Instant Messaging app, it’s hard to keep track of what people have discussed and agreed on. I’ve found the easiest way to deal with this is to record decisions publicly. It can be as simple as recording an agreement on your JIRA card, or it can be as formal as keeping a project decision register. Or you can use another form of specification, like your company wiki. As I mentioned in one of my previous posts, recording decisions is not about blaming people or holding people accountable when things go wrong. People make the best decisions they can with the information they have at hand at the time, and sometimes that information changes in the future. It’s more about keeping decisions transparent, providing clarity to all team members and stopping the wasting of time spent going over a topic which has already been discussed and decided on.

One thing I’ll mention about recording decisions – it’s important to provide some context. Make at least a quick note about who was involved in the discussion and any key points that led to the decision. This will further reduce wasted time in the future as people won’t need to go searching for why a decision was made.

Make time for building personal relationships

Sometimes when a deadline is looming, it’s easy to get bogged down in work and forget about the people behind the colleague exterior. When this happens, people can start to close off, and the working relationship can take a hit. This can result in all sorts of problems, such as people being excluded from discussions, or people becoming what I like to call “cowboys” – implementing things on their own without any group discussion at all.

I take every opportunity possible to bring some “personalisation” into my team. If someone logs in early to a meeting and it’s only the two of us on the call, I’ll ask what they’re up to on the weekend. Or if someone has told me something about their personal life and I don’t think they’ll mind, then I’ll hint at it at the end of a call to probe the person into telling the larger group and kicking off a nice team chat.

Other ways you can build relationships include:

  • Offering information about your own personal life, to encourage others to open up about theirs
  • Congratulating people on their achievements
  • Prompting people to share information, e.g. by asking what they’re doing on the weekend
  • Asking people to talk about their culture or language
  • Formally booking in monthly team meetings where people share their achievements, both personal and work-related
  • Any other way that encourages sharing in a supportive, friendly way

Travel if you can to meet the people, or make use of time when they’re travelling to your area

I was lucky enough to spend 2 weeks living with one of my developers who was travelling to Australia from China. We spent many a late-night conversation over the latest survivor episode getting to know each other. This set us up for an excellent working relationship, and having that connection has made a huge difference to our team dynamic. We are more open in meetings and joke around a lot, and this allows other team members to open up as well. Of course not everyone can travel, but if there is an opportunity, grab it.

Use video conferencing at least once a week

If you or your team mates can’t physically travel, the next best thing is video conferencing. Even if you can travel, regular video conferencing is a great way to reconnect with people on that personal level. In my workplace we have a video TV in the work area which is permanently displaying the China work area, and vice versa. It’s not so detailed that you can see what people are working on, but it does make for funny moments where people can walk up to the TV and do a funny dance or wave! It keeps us connected, and makes me feel closer to my team mates, which is worth its weight in gold.

Got any more suggestions? Leave a comment below!

Prioritising requirements based on the value they bring to your client


Business Analysts are often known as the people that elicit and manage requirements for business or software solutions. That’s certainly true. Requirements are our focus. Yet, if we looked a bit deeper, what aspects of those requirements do we focus on?

Functional impacts, dependencies, assumptions, architectural impacts, acceptance criteria, data structures, business impacts…. there are so many aspects to analyse for each requirement. Yet what is the most important thing to understand, before we start analysing the detail and working out how to fit the requirement into the design?

I would argue the most important aspect is Priority.

The Priority of a requirement can be described or allocated in various ways. Often product owners or business reps will be asked to give them a High/Medium/Low, or Must/Should/Could/Wont (see MoSCoW). But how about looking at it another way – prioritising based on the value the requirement brings to your client’s organisation or customers?

Value can be defined in different ways. It depends on what is important to your client. What are their goals or strategies? What do they want to increase or decrease? Do they want to increase customer satisfaction, product sales, market share or credibility? Or decrease waste, environmental impact or revenue losses? There are all sorts of drivers out there. The first thing a business analyst should do when starting on a project is to fully understand those drivers.

There are a few ways to go about understanding project drivers:

  • Talk to customers that use your client’s products or service offerings. This will give you an understanding of how the organisation is viewed externally and what levels of confidence exist amongst consumers. This can be as simple as finding a friend, colleague or family member that has some experience with your client’s products.
  • Talk to people who have worked with or for your client, that aren’t directly working on the project. This will give you an understanding of how people who consider themselves “insiders” view the project, which may give you an idea of how the organisation views the project and the level of support you can expect.
  • Talk to the project sponsor. They will be able to tell you the “official” drivers for the project, which will control the way resources and funding are applied throughout the project. Consider running a workshop with your project sponsor to determine what is most important in the project through the use of sliders – remembering that no 2 sliders should be the same!
  • Find out whose idea the project was, or where it stemmed from. This will give you context which can be useful when the drivers themselves may not be clear.
  • Look for past evidence of failed attempts at your project by searching your client’s Sharepoint, JIRA or Confluence systems, or other document repository.
  • Other ways? Comment below!

By looking at your project drivers and understanding various people’s view on the project, the true value can be understood. This can help you to provide useful feedback to your project stakeholders and allow you to work with them collaboratively to prioritise your requirements.