Category Archives: General

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.

Recording decisions

In my experience, something that is commonly overlooked, or undervalued, is the trusty Decisions Register. This is a simple artifact, which can be stored by your project manager or yourself, perhaps in the same spreadsheet as the risk register, or on a page in your team wiki.

It’s interesting to consider why a decisions register is not commonly used. Many people don’t want to take responsibility for decisions, or are too shy to document that someone else made the decision, because it seems like we’ll blame them if the decision wasn’t right in the long term. However, it’s really not about that.

It’s value comes into play in a few situations:

1. In the long-term, or throughout the life of the project, people will come and go

To prevent the same questions being discussed at length by different people, the decision can be recorded when it is made, with an explanation of why it was made and who was involved in making the decision.

This isn’t about blaming the person who made the decision, or locking in a requirement, should it need to be discussed and reviewed in the future. Stuff changes, and that’s OK. However when people move on that were key to that decision, new people can often spend hours, days or weeks debating why a decision was made, wasting incredible amounts of time.

2. Your project is showing signs of an underlying issue through constant requirement or design changes

If one of your stakeholders is making continuous changes to the requirements or design, chances are you’re coming up against a deeper issue. A decision register can be useful in this situation, because it can show a history of the changes.

Perhaps the architect is constantly re-architecting a solution because they are being pushed to implement “quick fixes”, leading to a lot of re-work and changes to the design decisions. Or perhaps your business stakeholder is constantly flipping on his/her decision because they really just don’t know what they want. Having this recorded can enable you to call out and address the real issue – in the above cases the pushing to implement quick workarounds which are ending up costing more than a well architected solution, and a poorly defined requirement with little basis for a solid decision which needs a deeper investigation into the reasons behind the requirement.

3. Your project has a lot of stakeholders that aren’t co-located

When staff aren’t located right near each other, people start to talk to those closest to them and start making decisions between themselves. It takes a special effort to get people in different locations to collaborate to make a decision, and sometimes decisions can’t wait for everyone to call in to a group meeting or workshop.

Having a decision register on a wiki that everyone is subscribed to enables people to be automatically notified whenever a decision is recorded. When used properly, the team can record all decisions that affect the larger project, and everyone gets notified automatically.

It’s not about finger-pointing

Now I could say that a decision register also helps in the situation where a client or stakeholder change their mind about a requirement. And it can. However it’s important to understand why that stakeholder wants to change the requirement. Is it because the requirement has genuinely changed? If so, you’ll need to revisit your requirements. That’s what being agile is all about – change is inevitable. Or is it because the person has forgotten why the requirement was there, or the team can’t remember who made the decision? Well that’s a set case to refer to the decision register and explain the reasons why the requirement was set. This can save loads of re-work and time and help to keep your project on track.




Getting the most out of that “one meeting”

As much as BAs love a lengthy discussion, involved workshops and interviews with many chances for clarifications and follow ups, sometimes all we get is that one meeting. Perhaps we’ve been asked to elicit requirements from a key Executive who claims to “have limited time” for us, or perhaps they say that they are “really busy” (we know that this implies a lack of commitment to the project but that’s another topic I’ll talk about another day!). Or perhaps we’ve been asked to conduct a series of interviews with multiple stakeholders in a limited timeframe. Either way, we’ve got a single chance to elicit requirements face-to-face with .

So how can we make the most of our time with these people? How can we build trust, get them talking and get the information we need? It can be daunting meeting someone for the first time, especially if they’re a “C” level executive. The key is preparation.

First, do a quick Stakeholder Analysis. Identify who you are interviewing and determine what level of interest they have in your project (i.e. will they be impacted by the project outcomes?), then identify their level of power/influence over the direction of the project (i.e. are they a signatory for sign-offs? Do they control project funding or resources?).

What you need to look for is whether the stakeholder has a high influence on the project direction. If they do, you need to ask them strategic-level questions. If the stakeholder is going to be greatly impacted by the project (e.g. operational staff), you’ll need to focus on how they currently perform their tasks, what issues they have, and what opportunities for improvements they know of.

Next, determine the aim of the interview(s). Is it to develop a business case? Or elicit system requirements? Get your aim very clear. For example:

  • “The information collected during this interview will need to be collated into a business case”;
  • “This person needs to explain all non-functional aspects of the system to me”; or
  • “I need to find out exactly how these processes are performed using the current system and how long they take”.

So now that you’ve identified who you are interviewing and what your aim is, you need to prepare a set of questions which will get you the information you need in the most efficient way. For example, if your aim is to collate the information into a business case, your questions may be:


  • “What/who is driving this project?”
  • “What outcomes do you hope to see from this project?”
  • “What benefits may be realised through the implementation of this change?”


  • “What do you like about the current process/system?”
  • “What issues do you have with the current process/system?”
  • “Do you have access to all information you need to perform your work effectively?”
  • “What opportunities for improvement might there be?”
  • “How would fixing the issues/implementing the opportunities benefit your team?”

You might see some aspects of SWOT analysis coming in here. SWOT is a very versatile technique which can be applied in various ways.

Whatever your questions are, they need to be structured to get the correct information you need to achieve your aim.

Once you have your aim and questions ready, it’s time for the interview. The first step is to build their trust. When they arrive, stand up, shake their hand pretty firmly, and introduce yourself – name and title. Be confident in your preparation and smile 🙂 If you don’t hear their name clearly, ask them to say it again. If possible, don’t sit opposite them. Sit beside or perpendicular to them. Get your notepad out, and unless you have a perfect memory, get ready to take lots of notes!

Then explain why you’re there. State how you came to be there and what your aim for the interview is. Ask them what briefing they’ve had about the project and whether they have any concerns. Let them talk for a bit and be interested in what their saying.

Then start asking your questions. With any luck, you will have shown some good faith in understanding their point of view, so they’ll provide the information to you. As always, practice Active Listening by confirming your understanding as you go. Write down all points that relate to your questions. Don’t be concerned if they go off on a tangent – it will likely give you some good information. Just try to steer the conversation so it’s answering your questions as much as possible. Keep an eye on time and if you’re likely to go over – just confirm with the interviewee that it’s OK to continue.

One tip I stick by – if you’re yawning, you’ve probably got enough information, or the information they are telling you is irrelevant or not new to you. If you find yourself stifling a yawn, consider moving on to the next question.

When you feel you have enough information and understand what they’ve said, close the interview with a general question like “is there anything else you wanted to cover?”, then thank them and always promise a follow-up, like saying you’ll provide meeting notes for them to review. Get their commitment that they will review them by stating that you’ll need some of their time in a few days to review your meeting notes.

After the interview, type up the notes into a neat format. Use a meeting minutes template or something similar. Send them to the interviewee and ensure you get their feedback. Always ensure the minutes are an accurate representation of the discussion. Even if you’re a bit late getting the minutes to the interviewee, always do this! It shows integrity on your part, and begins to build a deeper trust – doing what you say you’ll do is the first step in showing someone that they can trust you.

Once you’re happy you’ve got accurate accounts of the discussions, start your analysis on the information collected. With a bit of additional research, hopefully you’ll have enough information to get a good draft of your resulting document!

Tips for the “Generalist BA”

In my previous post, I mentioned the IIBA Professional Series day that I recently attended. As mentioned, the day was wound up with a panel discussion from Roxanne, Kevin and Tim Conventry (President of the IIBA Australia Chapter). The discussion topic was “How to promote the value of a Business Analyst”. From the discussion, it was clear that business analysts often face the challenge of coworkers, managers and clients misunderstanding the skillset held by business analysts, which results in BA’s becoming the “fill in” resource – capable of completing work such as testing, project management, development and so on.

What this says about business analysts is that many of us do come from various technical and non-technical backgrounds. We have various skills that complement our core competencies. This can be useful in small teams which rely on each other to ‘get the job done’. A generalist is often more useful than a specialist. However it can result in our core business analysis skills being watered down in the work environment.

The important thing is that we business analysts stay true to our aim of eliciting and understanding the true needs of stakeholders, and ensuring the solutions developed meet those needs. No matter what tasks we’re completing at the time. Below are some suggestions of how you can do this whilst performing a couple of other common “generalist BA” tasks:

Testing: Make sure the requirements your tests trace to exist and are complete, and represent the aims of the client. Have an informal chat to the stakeholders to truly understand where they are coming from and what they are hoping to achieve. Then question whether the requirements align to that vision. If your project has limited time or the solution is hard-set, talk to your techies to find out if there are minor adjustments that could be made to improve the alignment to the client’s vision.

Project Management: If you’re setting up a new project, why not start early with your requirements elicitation. In addition to the resources, timeframes and deliverables, start understanding the scope of the project. Maybe produce a high level business process flow, or high level use case model if your client’s major concerns are around business processes. Or perhaps a domain chart if you are working on a very technical project. If you’re managing the schedule, make sure you add adequate time in for requirements analysis!

Development: Similar to testing, have a chat with the stakeholders to try to understand their vision and what they are trying to achieve. Design the system to allow it to support their long-term goals, such as scalability. Keep in mind what is important to them when making all design decisions. They’ll appreciate it when you demo to them, when you show how you listened to what they were aiming for and designed it to align with that!

Do you have any other suggestions? Leave a comment below!

The beauty of networking

Recently I attended the International Institute of Business Analyst‘s Professional Series Day. What an amazing and inspiring day. There’s nothing like being surrounded with like-minded professionals to get you thinking about your own skills and what you have to offer the world. I’ve often wondered how I might give something back to the business analyst community, and after speaking with a very interesting person at the function who said “just dive in!”, here I am, diving in.

The speakers of the day were fantastic – Roxanne Miller of Requirements Quest®, and Kevin Brennan, the Chief Business Analyst and Executive Vice President for the IIBA®. They spoke on some pertinent topics – asking the right questions to obtain requirements, the upcoming BABOK® Version 3, and business analysis in the Agile environment. You can see the website for the details of the sessions.

In addition, the day was wound up with a panel discussion from Roxanne, Kevin and Tim Conventry (President of the IIBA Australia Chapter). The discussion topic was “How to promote the value of a Business Analyst”. From the discussion, it was clear that business analysts often face the challenge of coworkers, managers and clients misunderstanding the skillset held by business analysts, which results in BA’s becoming the “fill in” resource – capable of completing work such as testing, project management, development and so on. This prompted be to write my first “real” post – Tips for the “Generalist BA”. Select the link to get reading!