For the past six months I’ve been contracted to a company whose entire dev team work from home. Having done it for this length of time I can say it really works and I’m a little surprised that more dev teams don’t work this way as I think it offers many advantages over conventional office-based working.
Peanut Butter Sales Not Up
For many people, the idea of working from home has become synonymous with sitting around in your underpants in the middle of the day watching Diagnosis Murder, with a hand caked in peanut butter in said pants.
Even the local mayor, Boris Johnson recently accused home workers of being skivers
We all know that is basically sitting wondering whether to go down to the fridge to hack off that bit of cheese before checking your emails again
I would argue I’m more productive now – working from home – than I was in offices of old. My working day starts on average anytime between 8 and 9 and finishes sometime between 5 and 6 – this element is very similar to my office-based working time.
My current project is being delivered using agile methodologies (scrum) – for us that means we have daily scrums, sprint planning, pre-planning, retrospectives and frequent collaborations with the customer. Meetings are done primarily over skype; this works much better than some of my previous experiences of being in a meeting room with a ‘spider’ phone the remote worker communicating over the phone. The reality was often that person often didn’t hear everything and equally it was often hard to make out what they were saying. With a Skype meeting everyone (assuming their internet connection is ok) can hear everyone else and urls can be shared very easily.
Scrum WhiteBoards, Peer Programming, meeting ‘boards’
One advantage the office-based environment has is its physical properties – like whiteboards. Quite a few dev teams love their scrum boards – be it a whiteboard depicting burndown/stories in progress, or a board filled with post-it notes representing stories/tasks for the team with that near golden star feeling for moving said items forwards during a scrum update. Personally I think such dev teams are missing the point of being a dev team; I’ve spent my life as a developer writing software – whose main agenda is to make peoples’ lives easier. Moving people away from pen and paper based systems to windows apps and web-based apps. I have a problem being a developer doing such a task, but then using an antediluvian system to facilitate this. There are many web-based scrum whiteboards out there – we’re using epiServer’s Scrum Dashboard (sitting on top of TFS to manage our backlog), it’s free and does a good job.
Meeting Boards – by this I mean being in a meeting room and either enduring a laptop hooked up to a projector, projecting a slightly out of focus, crooked image of the user’s desktop to form the focus of a presentation or what not. On top of this I’ve often witnessed the painful hilarity of them failing to get their laptop connected to the network, or just running out of power. In the distributed office you don’t have to suffer this throw back from the 90s. We simply use Join.Me – a fantastic tiny bit of software that lets you share your desktop over the internet. Truly awesome.
Pair programming – Again, we use the fantastic join.me, so the developer doing the typing can share their screen and the other person can sit back, see the other dev’s screen and tell them what to type. Have done this a few times in the current contract and it really works well – esp. if you are the one telling the other what/how to type the code as you can’t just ‘jump in’ as you might when pairing around one desktop, forcing you to articulate what you want the code to do.
This is one of the weaker elements of having an entire team that’s home based. Communicating to the person(s) you want is fine, Skype handles this need perfectly. What you can miss is what you overhear in an office environment, esp. when the scrum team sits together. The downside is you don’t hear all the conversations, so not all knowledge is shared as easily as it can be. The solution is to share any gems/big decisions that are made without the whole collection of devs being present with the team afterwards. The flaw to this is of course knowing when to share.
However, the reason this works is not due to great tools. Success in any project is down to the people and their enthusiasm to achieve the same goal, together. We all work on the same code base and all want to see it’s functionality grow whilst maintaining its high coding standards. We have just increased to 10 developers, in order to develop the product and create a good code base there has to be constant communication both within the sprint teams and across all the devs. A lot of this chat is over Skype’s IM – I don’t think that’s relevant. What is important, is all the developers being passionate about the code base, devoted to producing the product that the customer’s paid for and having that constant communication to help feel we are not remote workers, working on isolated pieces of code but part of a bigger team delivering software.