RESOURCES

Distributed Team Technology For Co-Located Teams

About this Publication

As a coach in the field I'm starting to see a new trend: the use of tools made for distributed teams in co-located teams. In this paper I’ll discuss the unexpected benefits many distributed tools can give to co-located teams. I'll show how to use Hangouts to have better Sprint Demos, Trello for more responsive physical storyboards, a Google Docs for collaborative editing, Lucid Charts for diagramming, and G+ communities as shared team areas.

Not all of these efforts are successful, though, and I'll tell you how other teams did not gain the improvements they expected and what to look for if you try these in your own teams.

 1. INTRODUCTION

Over the past few years, I’ve had the privilege to work in several environments where we used web-­‐based project tools in unusual ways. Here are some stories of co-­‐located teams using tools made for distributed teams.

 2. HANGOUTS FOR BETTER DEMOS

Our first team is a small startup located in Southern Virginia working on a web application in a niche vertical. They’re in stealth mode, with funding and customers, but there were a lot of stakeholders not present that needed insight into how things were progressing. In addition, as another source of income they had some folks working on a traditional commercial technology project for a client in another state.

We found one of the coolest chat tools in the past couple of years where we least expected it: Google+. Google+ allows us to do a bunch of useful stuff whether we're in the same room or not.

We found a lot of unexpected value with the Google social networking tools, specifically Google Hangouts.

For the first couple of sprints, we did our demos the regular way. We had a physical storyboard and a team of 6/7. Usually there were another 4 or 5 folks attending the demo and a couple that couldn’t make it. We were working in a large room with several other teams. Since we did our demos in our team area, we just walked from PC to PC looking at the work that was completed. There was a large monitor we used at times as well. During the demo, the developer came up, pulled the story card, then showed how the functionality worked. This was fine and worked according to the rules of Scrum, but in a noisy room with other teams, it wasn't always the smoothest process. Developers lost track of details, demo attendees were distracted by other things happening, and not everybody could attend, requiring the Product Owner to "re-­‐demo" functionality offline, sometimes doubling the amount of time and work.

So we tried hangouts. We found that Hangouts led to several improvements, even keeping the rest of the work environment the same.

Hangouts have several key features which took our demo to the next level of awesome. First, they are multi-­‐ point video conferencing with screen sharing. This means that each participant controls whatever video they want to send to the rest of the group. They can show a running app, a video they recorded, or step the audience through a regular demo from their browser. Second, the hangout creator acts as Master-­‐of-­‐Ceremonies, switching from participant to participant to control what is being shown. They are able to mute mics, cut in for some live commentary while something is getting set up, or moderate online chat. Google will even make a YouTube video of the hangout as it is occurring.

YouTube videos allow people to join who are not present (of course), but they also allow re-­‐showing the demo to those who couldn't make it. Product Owners inside a client organization can share how things are going with their managers at the manager's convenience. While nobody has time for meetings, everybody likes to browse videos at their leisure. As teams deliver things of value in a professional manner and these accomplishments are shared with others, this could be a way for external shops to market further work inside an organization automatically for little to no extra work. As I was ending my engagement with this group, they were talking about keeping these demo videos in a library for each of their clients alongside some stock footage of the development team working. When contract renewal time rolled around, the idea was that they could create a mash-­‐up of the team working alongside the finished product being demoed to a happy audience and use this as a sales tool. This was a very interesting idea, although I am not sure if they pursued it.

At the last demo I attended, we even started using a couple of the notebooks as "camcorders" -­‐-­‐ pulling back to get wide shots, zooming up on phones and tablets to show demos happening on devices and getting audience reaction that wasn't part of the hangout. They were getting ready to install an IP cam at a couple locations around the room. Not only was this fun, it was also free.

Interesting side note here: we didn’t get any pushback from management about using YouTube, but quite frankly we kept one of the implementation details hidden: by default all YouTube videos are public! So we would do the demo, then quickly go into Video Manager and lock it down before sharing the link with anybody.

3. TRELLO FOR TASK TRACKING

Our second team is large commercial interest in the Southeast United States. As part of a new product initiative, they were bringing together several teams they had acquired into one larger team-­‐of-­‐teams that would be in one location. Because the teams were still in flux and not everybody could attend in person, there was a need for a task tracking tool that could serve as a backup to the physical storyboards.

Tasking tools are common online, and if anything, the challenge many of the teams I coach face is to avoid prefabricated tools and concentrate on conversations and collaboration. Still, with the development of touch screens on both iOS and droid devices, we can now track tasks both remotely and directly on a large screen. In this scenario, a large touchscreen is placed where the storyboard would normally go. Instead of team members coming up and physically moving the cards, they can use their phones, computers, tablets, or direct touch to update story and task cards.

As long as the screen is left on all the time, this allows the team a big, public, visible display of work ownership and status while simultaneously allowing remote updating and communication to interested parties unable to visit the team room.

There was some talk about using using json to pull down statistics from Trello, but as a coach I had to stop this. Technical teams are simply way too tempted to immerse themselves in the details of technology instead of the social interaction required to solve problems. However, it was interesting that because of Trello's open nature, some data amalgamation could happen with just a little bit of programming. We had to be careful that we stayed focused on solving the problem the team was being paid for. It is too easy to slip into “meta mode”, and start to think of our task workflow as just another flow of data to be manipulated programmatically. We had to mind our knitting.

Even though Trello was chosen because of its simplicity, we found that some teams want to add information to story cards that doesn't appear on the face of the card in the app. It seems that the physical pencil and paper will never be replaced by an online app -­‐-­‐ the minute you start automating something you begin to place implied constraints on how it can be used or configured. Trello and online task management was our worst experience because of this. Automation as a tool to communicate the status of abstract work tasks was fine. Once we added more detail, the assumptions made by the tool creators began to shape our work effort, instead of the other way around.

This is a pattern I have seen many times as a coach. It’s not limited to just online collaboration tools. When the very first desktop modeling tools came out, many users would seek to “fill in all the boxes” for each element, whether the information provided was useful or not. When Use Cases became popular, many IT shops would create long, involved forms that users would religiously fill out, creating much paperwork around sometimes very simple problems. Even in an Agile context, on more than one occasion I’ve seen Product Owners come to greenfield projects with huge lists of structured information for a backlog. Practitioners share these templates. This is done supposedly as a way to make the work easier, but it never does that. Similarly, any sort of structure in an online tool is easily confused in the user’s mind with a template that must be completed.

Even when we managed to minimize the amount of data we tracked, we found that we started running out of large monitors very quickly. This led to a team discussion around collaboration. Every collaborative application we used needed to be displayed in such a way that people without the application could observe and participate. This was a full-­‐time requirement. In addition, we needed several simultaneously. This meant having generic team accounts on many apps, but it also meant we needed more display space. We decided to purchase another five monitors. This wasn't an easy decision as large touchscreen monitors can get very expensive.

When I left the team, they had a full-­‐time large monitor dedicated to keeping their tasks up, but the prospects of it staying that way were dubious at best because of other organizational priorities.

4. GOOGLE+ AS A DOCUMENT STORE

Our fourth team is a small web development group running from central North Carolina. Their customers include major players in healthcare, and entertainment. They had a need for quick and easy-­‐to-­‐use repository for conversations and random pieces of team information.

Google+ (G+) was very useful for this purpose. Private groups allowed the team a place to put anything they wanted apart from the rest of the site. While physical conversations were still the way the team solved problems, they also started using G+ posts as a way to gather questions and answers together, like a FAQ. Discussion categories facilitated adding a lot of stuff, and whenever somebody found something interesting, instead of emailing everybody, they could just drop it in G+ in the right category.

G+ was so flexible, in fact, that it presented the same problem we ran into with all the other tools: it did too much. After using it for a while as a repository for FAQ and internet articles, one team member started creating posts for each of the user stories. This was problematic, as we had other areas where we were including story data -­‐-­‐ mostly all the other tools -­‐-­‐ and it had to stop.

 5. LUCIDCHART FOR DIAGRAMMING

Our fifth team is a small part of a multi-­‐national telecommunications company. They were working on a radical new version of an existing product line. The development involved hardware, software, and embedded software. Being used to detailed planning, and working with complex problems, they needed some lightweight way to have team and customer conversations that was somewhere between a spec and a chat.

Many teams that begin using Agile techniques toss out (or never try) diagramming, and that's a big loss. As long as the formality is scaled based on need, group sketching is the most powerful collaborative tool a team has. Paired with a very small amount of standardization around what various symbols mean; communication, agreement, and discussion can happen even faster. Most mature teams working in tough problem domains will either learn some lightweight version of UML, develop their own, or only hire people who already know it, so having sketching ability in your toolbelt is a good thing.

Until recently, for diagramming teams were left with either heavy, client-­‐side PC applications or just drawing things on the whiteboard and taking pictures, then sharing the pictures. There was no middle ground. Lately though, a lot more tooling is being created on the web. The last startup I worked with decided on LucidChart for diagramming, and we found it offered many advantages for the team, even if we were all in the same room.

The way we used it was like this: anybody was free to make or update any diagram in the team's file storage area. When the team was working together on something that might require remembering something that was diagrammed, somebody would bring up the appropriate file on a nearby large monitor. Then either they would edit while others chatted and pointed to the monitor (acting as a scribe), or everybody could log in at the same time and anybody could change the diagram, although in practice one person would change while the others navigated. This had the benefits of a live, in-­‐person conversation, of using a tool and language, while still not having formal structure around who did what or in what order.

One of the nice features of LucidChart and many of the other tools is that you can work from an URL. That is, if you can click a link on a browser somewhere, you can get to the doc and start participating. That's a tremendous improvement over past toolsets where it might be hours or days of configuration and training from wanting to try a tool to being productive with one. In addition, web apps are designed for mass appeal and easy adoption, further reducing the barrier to collaboration.

One of the drawbacks of using any diagramming tool is the tendency to overuse it, that is, start focusing on the tool instead of the conversation and collaboration the tool is supposed to provide. Early-­‐stage teams like the one I'm referring to will many times have a simple task card for the tool, something like "gain agreement with the Product Owner on the server structure required and document" This allows the tool to be used in a one-­‐ shot manner: have the conversation(s), reach the goal, then put aside the work unless more conversation and collaboration is required. A better way I've used these tools is to set aside a certain amount of effort constantly and keep a running "doodle" as you go along. This is easy enough to do in the team room as long as a monitor is signed in showing the workspace.

Another drawback we found was that as we added tools, as few as just one more, there was overlap to where things would go. So we had to have a short conversation around where to put things. We'll talk about that at the end when we talk about it all coming together.

Another tool we looked at was GenMyModel. We were about to sign on to it, but it was missing a couple of items we had to have -­‐-­‐ although that's fixed now. There are at least four good collaborative diagramming tools, and the features are all changing rapidly, so be sure to do a quick review of features before you chose one.

 6. GOOGLE DOCS AND BETTER COLLABORATION

Our final team is the same Virginia team that tried using Google Hangout. Over the few years they have been in business, they tried several products for project documentation. They found that most tools had too many features for what they needed and there was a revolt against the existing toolset. When I showed up we needed a new approach. Google Docs seemed like the easiest thing to try.

You'd think that Google docs would be great for collaboratively editing documents, such as a calculation model or letter. That's correct, but we've found that you have to be pretty clear about what you mean by the word "collaboration" It's not creation. If you've got 8 people in a room coming up what the next sentence should be, you're wasting everybody's time. Instead, we separate note-­‐taking, outlining, and draft-­‐revision. Each has its own rules.

For note-­‐taking, like when interviewing users or clients, somebody volunteers and sets up one of the team screen's google account to the doc to be edited. As the conversation naturally progresses, the note-­‐taker updates his doc. Since the note-­‐taking is happening in a big, public, visible way, people are free to interrupt and change something if needed, but most of the time the information is just there for information purposes only. Sometimes, like in initial client meetings, you'll review what was captured at the end.

When the team has to create a more complex document, it helps to separate the work into parts: goal-­‐audience, outline, and draft-­‐revision. Each developer, on his own time, reviews the current status of the work and brainstorms edits/additions in preparation for the group work.

Everybody comes to the table with as many changes as they want, and the group goes through the doc making changes as needed. This is time-­‐boxed, no more than an hour, and it's up to each participant to make sure their most important changes get made before the time is up. Note that it's unusual to have a large number of complex documents that would all require team creation. More than a few is an indication that something is wrong. (Customer-­‐required specs and user stories are definitely not one of these instances.)

The benefits of using Google Docs and a shared large account on a large screen in the team room is that the work product is always available for inspection without any team member needing to be online. It's an open format that encourages collaboration.

The drawbacks to this method is that it's easy to confuse output with quality. The job isn't transcriptionist, and whoever is using the tool is expected to self-­‐edit and help arrange ideas and concepts as they go along. This kind of split-­‐attention is very difficult for some to do. This makes it all the more important to understand that language and editing is owned by the document driver. Changes and consensus is owned by the team. It can also be very easy for some in the team to get "hung up" on aspects of a document as it is being edited. This can happen in cases where there's low trust between team members or between team members and outsiders. In this case, don't use the tool in an attempt to drive consensus. Instead, gain consensus through conversation and then have the "driver" send out a synopsis to all participants afterward. Then continue the draft-­‐revision cycle as needed.

 7. ATTRIBUTES OF A GOOD TOOL FOR CO-­‐LOCATED USE

After observing several teams use free tools, here's the things I think are required for successful distributed team use in a co-­‐located environment:

Has to be accessible. People have to be able to walk into the team room and start working with the tool with a minimum of fuss. That means no trials, no credit cards, no lengthy sign-­‐up pages. It just has to work.

Has to be web-­‐based. For the same reason, downloaded clients are a bad idea. Not only are they highly-­‐client O/S specific, downloaded apps are updated less often than online versions. The web is a universal functionality delivery platform, it works everywhere, on most every device and O/S.

Has to allow for url deep-­‐linking. The real power of these tools comes from being able to share what you are working on with others. Tools that allow you to link directly to a diagram, document, or paragraph segment are vastly superior to tools where you have to sign in, join a project, navigate to the doc, etc.

Have to pick a driver for each discussion. Just like in pair-­‐programming while coding, for group conversations to happen around an electronic tool, there needs to be a driver. Everybody else is a navigator.

Brainstorm offline; communicate, collaborate, and decide in-­‐person. Studies and experience has shown that team brainstorming is not as effective as expecting each team member to be caught up and show up with input to present to the others.

Has to work with multiple simultaneous editors. One of the neatest things to do as a team is switch the driver in the middle of a discussion. If everybody has simultaneous editing capabilities, this is no big deal. But if there is a lot of clicking around, it disrupts flow.

Native Apps are a big plus. The really good tools both have HTML and native app support. Native apps run a lot faster than straight HTML, and usually have device-­‐specific features, like multi-­‐touch operation.

Comments/Notes have to allow hyperlinks. Where everything really starts coming together is when you can quickly move from one tool to another. While comment fields turned out to be problematic for us in general -­‐-­‐ there were simply too many places to put information -­‐-­‐ links in comments were a different story. They were most useful.

Have an information strategy. It's not difficult, but take a few minutes and put up a piece of paper with what information goes where. It saves a lot of pain later on.

In general, in the last couple of years online collaborative tools have reached the maturity level required by co-­‐ located Agile teams. They're free, easy-­‐to-­‐use, and everywhere -­‐-­‐ an easy way to boost your productivity.

 8. RECAP

Table 1 Summary of experiences using tools for distributed development in a co-­‐located environment

.

About the Author

No bio currently available.