Location. Location. Location.

Over the next few weeks, I am lucky enough to be on location on the beautiful Island of Tasmania – better yet, I am here on vacation. ūüôā

Since I don’t particularly want to spend my time writing about work while relaxing with my family, instead I will share some thoughts from others in the agile community.

Today:  Distributed Collocation.. an Oxymoron? by AccuRev

I hope you like it Рsee you in a few weeks!

Remote Possibility.

These days, more and more people are engaged in conversations about distributed agile. Is it really necessary to have the entire team be co-located in an office all of the time?

I have a strong opinion that agile can work just as well with distributed teams, as long as the basic principles are followed. Starting first and foremost with trust. I am a product owner who works remote. My situation is perhaps not very common, in that I am one of several product owners in our organization working on the same end product. The other product owners all work in the same office along with the majority of our development and QA teams and of course our scrum masters. I on the other hand work in a different location and even a different time zone than the rest of the team and have done for several years.

Initially, our company was working in waterfall, which means that this arrangement, albeit unusual in our organization, didn’t raise that many eyebrows. After all, working remote is becoming more and more popular these days, although admittedly it is still relatively new to the hospitality industry. Developing in waterfall, my working remote meant that I was able to spend many focused hours writing detailed requirements, without interruptions or distractions that naturally occur working in an office. I was able to produce a lot of quality work, delivered on time and with no adverse effects on any other member of the team.

Then came agile… all of a sudden working remote became somewhat of an enemy. Agile says teams should be co-located. Period. Or so people thought. In my situation, re-locating to be with my team at all times simply wasn’t an option. Luckily for me, my managers and team members were open to exploring slightly more unconventional setup of remote scrum. So for the past few releases I have been the remote PO of a scrum team, sometimes with all other team members located together, sometimes with some of them also remote. And I can honestly say: it works.

I wouldn’t go as far as to say it’s just as easy as doing scrum when you are co-located, although I can’t say that with complete certainty, as I never have done scrum without being remote. I can say however that being remote makes me far more organized and forward thinking than I believe I would have to be otherwise. Because my team is working for a portion of the day without being able to reach me, I need to be extra clear in our daily meetings, always make sure I prioritize making myself available to them when I can and ensure that the teams’ priorities are crystal clear, so we don’t run into any bottlenecks.

For me, the key to being a great scrum team is trust. To be successful as a team, I have to be able to trust the developers, the developers will need to trust the QA, everybody needs to trust the scrum master and trust the product owner. Without trust, there simply is no team, without trust, we are just a bunch of people giving and following orders.

While it might seem that working remote scrum makes trusting each other harder, in my experience, it is actually the opposite. Allowing the arrangement where some of the team are remote, is an immediate sign to them and the outside world, that they are members of the organization that can be trusted to¬†work unsupervised. In remote scrum, there is no space for micromanaging or looking over people’s shoulder, we just trust that we each get on with our work. And when we do get together each day, we make sure our time together is focused and used effectively, because we know it is limited.

I can’t say whether working remote has made me a better product owner, but I can say that our team has been able to deliver just as much value as any other co-located scrum teams. So for me, distributed scrum is more than a remote possibility.

Remote control.

The agile manifesto states that;

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

I can honestly say: I wholeheartedly agree!

Many studies show that up to 80% of communication is actually non-verbal, relying on body-language, tone, facial expressions and eye-contact, none of which can truly be conveyed by an email or an instant message, even a phone call only barely touches the surface. The most effective communication always was and still is a face-to-face conversation. Makes sense, right? So to be successful communicators, we just need to make sure all important conversations, meetings and handovers happen in person. Every time. Plain and simple.

This is where it gets complicated. I look around and what I see is that I work in an increasingly global and mobile world, with more locations, more technology and more cultures working together. While all of these contribute to the quality of the work, the diversity of solutions developed and ultimately may improve the cost-effectiveness of an organisation, working this way also brings its own problems: How do I communicate effectively having to rely on technology? How do I bring together a team across multiple time zones? And how do I promote teamwork and engagement in multi-cultural team?

There are many articles that provide suggestions on how to deal with this scenario, I’ve whittled mine down to 3:

1- start with a¬†face-to-face meeting – being able to see who I am working with is incredibly important to me, in my experience, it promotes team bonding, commitment and communication. I find meeting someone face-to-face gives me more of an insight into their personality. Someone’s body language and facial expressions show their personal and social style in a way a phone call simply cannot. Naturally, it can be too expensive to fly people in just for a quick meeting but even using skype or facetime or other video call tools can make a big difference, I found it is worth exploring the options and using the tools available to your advantage.

2-¬†set crystal clear goals – when working away from your team, it can be difficult to stay motivated, I am no exception. To keep myself productive, busy and engaged I write lists of items to achieve for each day. That way I have a clear goal, I know when I have been successful and when I had a productive day. When working with a distributed team, setting clear goals and targets is even more important, especially so, when you work in different time zones where an unclear goal can lead to hours and hours of idle time until the other party “wakes up”. So I make sure that when me and my team talk about our goals, we do so in real-time. For me, it is important ¬†that we collectively assess if we covered the right tasks and check that we have the right amount of work to get done until our next meeting and of course that everyone has understood and is aligned on our team goal. Only if each of us know where we need to be, are we able to assess whether we are on the right track to get there in time.

3- use every communication tool available – when I first started in this role, I really only used our daily standup calls and the occasional email to communicate with my team. This worked well enough in the beginning, however as soon as things got going and got a little more complicated, I quickly missed the advantage of a co-located environment, where I could simply walk over to a person’s desk. Since we didn’t have that option, we just needed to be a little more creative. Technology became our best friend: we added instant messaging, a dedicated webinar room and conference bridge, setup an online sharepoint and added online tools to track our progress. ¬†We continue to use emails and our daily standup calls and team sessions, but using more communication tools has given us more flexibility, improve our communication speed and quality and ultimately made us more agile.

I realize none of this is rocket science, it’s actually pretty obvious once you stop and take a the time to look at it. As a new product owner however, there wasn’t much time to stop and look. Especially in the first weeks of working with a remote team it was challenging enough just to figure out how to get from one sprint to the next.

Now, I follow my 1-2-3 and I feel back in control, remote control.