anthony galvin

I’d started drafting these tips for the R/GA tech blog when Bobby Schultz beat me to it with his post “The 5 pillars of remote collaboration”. Despite this I thought I’d post my thoughts here anyway.

It is certainly not a recent trend for organisations to be looking to work with remote software teams. Whilst previously this was primarily motivated by a move to reduce costs and offshore development, increasingly there’s also a desire to harness technical talent irrespective of location. The growing R/GA network means that we are often reaching across offices to staff projects teams and leverage talented technologists. 

Here are a few tips that help those projects along.

1. Daily stand-up has to run like clockwork
Even if you’re not running an agile or adaptive planning process it’s important that everyone is committed to making ‘the daily’ a success. This is your most important meeting of the day. It needs to be professional, effective and run to time. Time is important, on projects with a wide geographical span as someone is going to be getting up early or staying late to contribute to the daily, so everyone needs to respect that.

2. Keep an open line of communication for all developers
Informal communication is essential between the development team, what my colleague @philhawksworth calls a ‘back channel’ for open discussion, questions and banter. This is where ‘the culture’ of your team is going to be fostered.

3. Use video
Make all calls video calls, even though we can get by over the phone the psychology of video calls helps to re-enforce relationships. Where there are a group of people in a single location use a dedicated meeting room computer and gather round a single large screen so that remote workers take up a disproportionate amount of space in the meeting room.

4. Have a robust, repeatable build and deploy process
Whilst continuous integration and continuous deployment may not be appropriate for all projects, when working with remote and distributed teams a bullet proof build and deploy process is essential. If you’re running a semi-automated build system everyone should be able to run a build regardless of location - without this you’re going to start having bottle necks and some users are going to be more equal than others. With an automated build process all developers are have equal ability to break and fix the build. 

5. Be location agnostic
If at any point the team start thinking about people who are ‘offshore’ or ‘in New York’ then that’s the start of a problem. Everyone on the project may not be equal, but the source of the inequality should not be location. 

This doesn’t mean that you shouldn’t  be sensitive to different locations and cultures - if it’s a public holiday in London, then it’s a public holiday in London. These things tend to equal themselves out and there are no surprises - you don’t often get short notice public holidays. The key thing is that you’re being equally sensitive to location and culture regardless of location.

6. Let remote people lead parts of the project
This sounds slightly counter intuitive when working with a group of remote developers or a distributed team, but if you want to embed a location agnostic culture don’t be precious about having all parts of the project led from the largest or main location. If you’ve got a fantastically talented front end tech lead on the project who is based in South America and you’re in Chicago, then there’s few reasons not to let that person lead the front end development.

7. Make time for a 1:1 
If you’re leading a project and you have remote developers, make some extra time to have a one-to-one session with each individual. You won’t be to recreate that hallway conversation you might have if you were on the same corridor, but once you get a cadence to these conversations, it’s amazing how productive they can be.

8. Face to face buys you time
There’s an internal saying @RGA “that face time buys you 6 weeks”. Whatever the number for your team take advantage of any face time you can get, both from a work perspective but also from a social “let’s go to the pub point” of view. It’s worth it’s weight in something heavy and valuable.

Last week R/GA London had it’s first Make Day - two days of creative and technical exploration, in some ways done just for the joy of being able to make things. I was astonished by the diversity and quality of the work that people produced. Russell, has posted a round up of the different projects, which ranged from a (working) face recognition system running on Windows 8 (which isn’t even publicly available) to some marmalade. For my part I worked as part of team building a “tea and coffee roulette web app / game”.

The concept itself was pretty simple - make a webapp that would allow you to join a tea round, the twist being that the last person to set a preference and complete a simple task would have to make the drinks for everyone else. A quick 10 minute brainstorm and one whiteboard diagram later and we were underway, with @sanderkuypers doing the visual design and the rest of us (@benoitgrelard, @loopdream and myself) quickly began hacking together some working software.

From a tech perspective we decided on a web app (ie, a mobile application that isn’t device specific and can run in the browser) as the best way to get something working with our dev skills. From a front end perspective you can get quite a lot of motion data from some devices (such as an iPhone) via JavaScript, which meant we could build a ‘shake the sugar’ task for the race element of the game. Last one to a hundred shakes makes the tea.

To speed up getting to this device data and creating the UI we used the jQuery JavaScript framework. In the background the game engine was built using PHP and CodeIgniter to handle user registration and keeping everything in sync. We had thought about using node.js to handle socket connections to the devices, but with time limited we settled on using Pusher (a hosted socket service), which had us up and running in about 20 minutes. Behind all this sat a simple mySQL database for keeping everything together.

By the end of the two days we had a working game, that looked great and actually worked - user and device registration, automated email (warning users that the game was about to start), a countdown, simple game (track and field style) and notification to the winners and users - all in real time (via web sockets).

Apart from being a break from our usual client projects and lots of fun it was good to build something a little different - although we didn’t stray too far from our core competency, we did try a few new things. Russell and the management team set some pretty loose (open?) goals for make day, but as the project progressed it was clear that one of the main motivating factors of our team was to deliver working software - which is a pretty healthy team ethic.

I’ll post a link to the source code and a working example once it’s online.

— Follow Up —

Dave suggested that one of the factors for the (relative) success of the project was that the team comprised a variety of skill sets. Whilst this is true, it did come about pretty much by accident. 

It’s October. Unseasonably hot. The ‘rec’ busy with the usual early morning Sunday traffic. Tired looking fathers push energetic toddlers on the swings and dog walkers hurl mauled tennis balls vast distances with the aid of semi-prosthetic tools. The sound of the Sunday  morning footballers can be heard from over the hedge that separates the cricketers ‘oval’ - though in reality the cricket ground is far from a shape that can be easily described by conventional geometry -  from the more rugged footy pitches on the far side of the rec.

But on this bright, late  summer early autumn morning there’s a another sound; a mower is working one end of the tired looking square. On the other side a scarifier is churning away - scarring the wickets with it’s metallic teeth, and tearing at the turf that is seen, by some villagers (if not the local foxes) as semi-sacred ground. 

For Stewkley 1st XI the season is over, a slightly misleading name, as there’s only one team on a Saturday these days. By most measures the season has been one of mainly downs, with a second successive relegation only avoided by a rare win on the final day of the season. Next year another assault on the four counties div 3 title awaits. But that’s along way off. For now there’s some work to be done, putting the wicket to bed. 

A group of men are trying to coax the ancient petrol mower back to life. It’s shed some critical bolt into the grass box, a grass box which has already been emptied into a huge pile of cuttings on the far side of the boundary. There’s much cursing and encouragement as the ‘old girl’ is primed and the hand start is repeatedly ripped with huge effort and little success. A quirk of the device is that each ‘start’, false or otherwise, requires the entire starting mechanism to be rebuilt by hand. A process that seems to take an eternity. Eventually there’s a rumbling cough and the green goddess sparks into life and trundles off down the wicket. Despite her age and infirmity, the cut of the whirling blades is neat and efficient.

The square hasn’t seen many big score this year. Often a little ‘green’ and far from flat (the ordinance survey could run a training course identifying all the ridges that run over the 12 or so strips)), visiting teams know that anything over 150 is going to be a potentially winning score. Teams who reach 3 figures batting first always fancy their chances. Especially if there’s been some overnight rain (there are no covers) or it’s a cloudy atmospheric day. This isn’t a ground for the batting purist, but for the ‘grafting’ batsmen who plays the ball as late as possible.

Yet it isn’t the worst wicket in the league and the ‘rec’ certainly isn’t a bad place to play your cricket. On a good Saturday the benches and chairs by the squat brick pavilion are filled with spectators, never short of encouragement and, sometimes direct advice. Surrounded by trees - with a couple encroaching within the boundary at the far end (only 4 runs should you clip one of those with a lofted drive) and sitting  on the edge of the village, it’s a sometime bucolic scene. The (inattentive) fielder can watch buzzards and red kites hunt in the adjacent fields and tractors buzz along the Soulbury Road, a short hit over the boundary. 

Today though there are no spectators or men in white. Instead on the edge of the ‘artificial’ there’s a large pile of top soil and a bag of grass seed being mixed up, ready to top dress the square. Perhaps as an offering to the cricketing deities for more runs next year - and certainly for more consistent bounce. Though perhaps some of the bowlers are less sincere in their devotions. Wickets seem easier to come by when you don’t know if the batsmen is unsure if a length ball will shoot onto his the toe or rear up to under his nose.

The mower falls silent again, and whilst a committee of elders try and formulate a plan for one more start the younger members of the work party begin an impromptu game on the edge of the cut strips. A old tennis ball is found and a broken shovel commandeered for a bat. There’s some edgy drives, the weight of the blade and the post season rustiness combining to give catching practice to the close circle of fielders. The old machine is back in action and the game breaks up to scatter the soil, seed and odd stone over the freshly manicured ground.

And then it’s done. The rope is up around the table, suspended strangely at head height from metal poles - a test for for those wending their way home across the ‘rec’ from a  late night session in The Swan. There’s time for a quick beer in the pavilion bar, the last one of the cricketing year and then it’s done. The wicket has been put to bed. The season is over. Until the next one. 

This post originally appeared on the R/GA tech blog 3 August 2011

This week has seen the news that in the UK, Google Chrome has overtaken Mozilla FireFox to become the second most popular browser. According to data aggregated by StatCounter (a provider of website tracking software), Chrome now has 22.1% of the UK browser market, pushing it past FireFox’s 22.0% market share. Internet Explorer continues to dominate with 46% of UK users still using some version of IE.

Measuring UK browser percentages is not an exact science. Whilst StatCounter usage is widespread, it is by no means the only web tracking software available. This combined with the difficulty in identifying the geographic location of all site visitors means that despite the impression of precision, this data should be regarded as indicative. What is interesting here is the trend and also the reasons ascribed to the growth of Chrome usage in the UK.

Google clearly see speed as a key element in the rapid growth in Chrome usage. Google engineer Lars Bak has been quoted as saying “Speed is a fundamental part of it, but it’s also about the minimal design and the way it handles security”. But the success isn’t only about technical excellence and improving developer tools. A growing suite of cloud based business applications is driving adoption of Chrome by UK businesses. Unusually for a Google product, in the UK Chrome has also been supported by an extensive outdoor advertising campaign.

Whilst Chrome isn’t universally popular, it’s speed and innovative use of caching, has given it, and Google a place on many people’s desktop. With Google alsogrowing rapidly in the mobile market with it’s phone operating system, Android, and making a play at the hardware market with it’s new Chromebook, it would be difficult to see the rapid growth of Chrome slowing any time soon.