Distributed Team Technology For Co-Located Teams. Daniel B. Markham Orlando, Florida Agile 2014

Transcription

1

2 Distributed Team Technology For Co-Located Teams Daniel B. Markham Orlando, Florida Agile 2014

3 Who Am I? Agile coach Programmer Architect Writer Speaker 30 years of experience Dozens of companies. Hundreds of teams.

4 Why am I here? Starting to notice something interesting It s powerful and free It s something you can start using today There s no need to repeat the mistakes other people have made

5 Google Hangouts for Better Demos

6 Who were these folks?

7 How Our Demos Used To Look

8 Problems Schedule was never right for everybody Missing people Wanted to share things with potential customers, not present People coming in and out

9 What We Tried

10 The Good Multi-point video conferencing FTW Participants control what they show from their PC, lists, code, UI, etc. Each participant is a mini-presenter SM/Hangout Creator acts as Master Of Ceremonies and movie director, both controlling action and audio/video feed to the rest of the group Google will even make a YouTube video of the demo that can then be kept as a record

11 The Bad Background noise Turns out there s a bit of skill in using hangouts There s a separate skill in controlling an audio/video feed Nobody had the bandwidth to do any post-production work Privacy issues

12

13 Trello for Fast Tracking

14 Who are these folks?

15 How task tracking used to look

16 Problems Teams were still in flux so everybody couldn t always attend We were still working out where all the teams and people were location wasn t fixed Managers who may or may not be part of the value chain were still concerned/interested in how things were going and were not onsite

17 What we Tried

18 The Good Big, Public, Visible tokens of work Yay! No more having to walk all the way to the story board! Lots of room to add stuff on each card We could pull down data and slice and dice it no more having to actually write things down or add and subtract None of that dual entry by the SM stuff

19 The Bad No more being publicly responsible for touching, identifying, and updating the status of any task. Now you can hide! Lots of room to add stuff on any card! No longer were the cards just tokens of work. They became a formal record of the work itself. We were confusing two different topics We needed to add some things that wouldn t fit because there was no place for it. The UI, even a minimalist UI, started shaping how we thought about our work We split apart. The SM became focused on managing the meta part of the work downloading data, creating charts and graphics instead of the problem-solving part of our work. Others just did their thing.

20 Google as Document Store

21 Who are these folks?

22 How we used to do project notes MS Word and other random apps Dropbox Every document had an owner Always had to instructions on how to find things Some documents fell through the cracks and ended up on local HD or sketched out on paper and then lost

23 The new way Google Docs Google Plus

24 The Result Good Flexible Private Groups Persistent conversation repository Many features Bad Flexible Scattershot topics Required an informal data management plan

25 LucidChart For Diagramming

26 Who are these folks?

27 How we used to do diagramming

28 The new way

29 Good and Bad Good Bad

30 Google Docs for Better Collaboration

31 Who are these folks?

32 How we used to do document management Desktop-based apps Haphazard use of Dropbox as a repository

33 What we did Google Docs all the way

34 Good, Bad Easy to use Web-based Multi-user Needed a plan Needed a driver Sometimes had to plan for the plan

35 Summary

36 Tl;DR Has to be accessible Has to be web-based Has to allow for url deep-linking Have to pick a driver for each discussion Brainstorm offline; communicate, collaborate, and decide in-person Has to work with multiple simultaneous editors Native Apps are a big plus Comments/Notes have to allow hyperlinks Have an information strategy

37 Q&A