Categories
code development programming

#DunDDD Cross Country Coding slides and notes #xcc

Cross Country Coding Prezi Slides

Thanks to everyone who attended my Cross Country Coding talk at DunDDD. Hope the technology failure didn’t put you off too much. I really enjoyed the Q&A session afterwards, but according to the feedback, the talk was too short. I’ve got a few ideas following the discussion about coding across time zones. In particular, looking at non-real-time communication options such as wikis, twitter/status.net/yammer, blogs, and the use of multiple stand-ups to handover between time zones. If anyone’s got any other ideas, let me know and I’ll see what I can incorporate into the next iteration.

If you want to present this yourself, you can grab a copy of the prezi here, and you’ll find the speaker notes on Google Docs available to copy.

If you do decide to use them, or you have any other comments or suggestions, please feel free to add a comment below or give me a shout on the usual channels.

6 replies on “#DunDDD Cross Country Coding slides and notes #xcc”

Hi Craig.

Good presentation, lots of key points nailed.

A few other things I’ve noticed which may help add more to this paper.

– Tooling is key, ensure your tools lend themselves well to doing the job without ceremony. The best tools allow real time collaboration, think Google Docs real time edits feature. Function before form of course.
– Timeshifting in teams can help. Record your conversation on your phone, store it on the cloud, make it searchable by tags. This avoid the trap where people want to be there, but have other things to attend. Allow comments around the file to help others collaborate. Consider the Google Plus events feature to allow others to watch, but not affect the team.
– Consider use of online Scrum boards if you are not co-located. They lack that ‘in your face constant reminder’ aspect, but it’s a reasonable second place. http://agilescout.com/best-agile-scrum-tools/
– Use the chat window to have the usual banter you’d expect to help build team work. Offer the other person a coffee break and a chat on the phone to break up the day and share progress. Get away from the keyboard to talk properly and to help open your mind to what’s happening. Don’t lose the human element, remember there is a person on your team, not just a resource (talk about family, weekend, hobbies, plans, non-work stuff). This makes it easier to feel comfortable with each other’s language and mannerisms and helps make it easier to ask early and often.
– Always always always consider the backup of your collaboration. If the tool goes offline, will development halt?
– Share desktops to demo features, talk through documents. Nothing tells a story quicker than visually showing the issue / question in situ.

Hopefully some of this helps, most is covered in your excellent presentation.

Cheers!

Like

About tools, I didn’t explicitly mention any in the slides (and only touched on them in the speakers notes), but we use JIRA/Greenhopper for shared state and planning, and I’ve been impressed with it. Certainly fits well with how we work, although I’m sure we’re not yet using to its full potential.

Like

Just looked, pretty slick package, Craig.

We don’t use anything like that where I am. But I use similar myself to manage my own workflow.

Will keep in mind for Agile teams, it’s quite the challenge to get agile working for an offshore team used to building packages of software to a written specification. My company has hundreds of developers offshore who come in and out of workstreams often making adoption of agile very difficult. Note to self: must find ways in for them…

Like

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.