Distributed Collaboration

Distributed Scrum: Agile Project Management with Outsourced Development Teams

2008-01-31T10:08:00.000-08:00

I just ran across a paper from 2006 that talks about using the Scrum methodology with distributed software development teams:

http://jeffsutherland.com/scrum/2006/06/distributed-scrum-agile-project.html

There's also some background on the origins of Scrum in general:

The idea of building a self-empowered team in which a daily global view of the product cause the team to self-organize seemed like the right idea.

The emergent behavior of self-organizing system is fascinating to me, even apart from software development. There's definitely a parallel to high-performing agile software development teams.

One of the interesting complexity phenomena of the first Scrum with an observed "punctuated equilibrium" effect. This occurs in biological evolution when a species in stable for long periods of time and then undergoes a sudden jump in capability.

The recommended practices for distributed teams all seem involve keeping the traditional daily 15-minute scrum meetings with the whole team. People ended up emailing their status and plans before the meeting, to mitigate language issues and keep the phone calls short. I suspect that the main benefit of actually holding the calls, instead of relying solely on emails, is to provide accountability. Otherwise it's just too easy to publish a daily report late, or skip the reporting completely.

An Experiment

I'm the "product owner" on a team with members from two locations in the Philippines, and me in the US. We're experimenting with an approach where the project manager acts as "scrum master" for a morning scrum, held in a chat room instead of over the phone. The log gets emailed to everyone. I review the log, respond to issues via email, and follow up via instant message for anything that requires further discussion. As a result, there's a searchable electronic record of all those conversations, which I'm very fond of. So far it's working out pretty well!

Case Studies: Three Nonprofit Intranets

2007-11-01T00:12:00.000-07:00

Laura Quinn has written the stories of three different non-profit organizations (NPOs) applying different technology to improve their collaboration.

It's good to be reminded that technology adoption and culture change don't happen overnight:

While there has been consistent growth in usage since the redesign, it’s only within the last couple of months (almost four years later) that ALA feels that they’ve reached a “tipping point” where it’s now simply an expected part of the job to consult and contribute to information on LungNet

To balance that, there are often benefits that can be realized immediately:

Don’t underestimate the allure of simple things, however. The lowly staff phone directory is often one of the most popular features on an intranet.

Read the whole article:

http://idealware.org/articles/nonprofit_intranets.php

Mingle: Supercharged Index Cards

2007-08-15T15:21:00.000-07:00

Thoughtworks describes its recently released Mingle products as a "new Agile project management application". That's "Agile" with a capital "A", which is immediately apparent when you tour the product and see index cards arranged on the web page.

I would describe Mingle as "index cards on steroids". Or maybe "index cards with superpowers". This will delight the Agile faithful and quite possibly scare anyone who has never managed a serious project by sticking index cards to the wall. The data can be displayed in tables and summarized in charts, and you can create wiki pages with some effort, but the card metaphor is central and inescapable.

Model

Each project has its own set of attributes for cards. You can define transitions that are basically shortcuts for making frequently used changes to card properties. For example, the "Development Complete" transition might change the status value to "Ready for Testing", and the transition might apply only to cards with a status of "Ready for Development". This gives you the primitives to codify your team's workflow.

View

The display is built with tabs, each of which holds a page with a different view of the cards. The cards can be viewed on a grid, sorted into different lanes by some attribute. Dragging a card into another lane changes the attribute, which is nice for activities like release planning. Or, the data can be displayed in a table with configurable columns. A tab can also hold a wiki page, which is probably most interesting when using the chart widgets to show summaries and charts of card data taken from database queries. This is nice for things like burndown charts.

Templates

If you have a project with card attributes, transitions, and views that are useful, you can create a template for creating new projects. Mingle has interesting potential for use outside of project management. For example, I'm pretty sure you could build some kind of strategy board game with the right grid view and transitions. Ok, that's not the greatest example, but my point is that Mingle is really a generic system for collaboratively updating data.

Downsides

It seems to me that the card metaphor would become unwieldy when applied to large data sets, though that could be mitigated with a clever set of views. Certainly more scalable than physical index cards.

Links to cards can be made on wiki pages or card descriptions, but not from card attributes. This makes it a hassle to trace from task cards back to their corresponding story cards, unless the number of cards is small.

Mingle has an Excel import feature, but you need to need to paste into a text field from the clipboard. This reinforces my suspicion that Mingle is not for large data sets. Also, any newlines are lost in the import.

The wiki has no WYSIWYG editor, which will put some people off. At least in the initial release, it looks like wiki pages are only there to hold some charts maybe the team roster.

Technology

Mingle is built with Ruby on Rails, and deployed into a Jetty servlet container with JRuby. That's cool. Response time is somewhat slow, even when running locally. Hopefully this can be improved in future versions of JRuby, because I'd like to see more integration between Rails applications and Java.

Recommendation

If your team can run with the index card metaphor, but you're not in a position to use physical index cards, take a look at Mingle. If you're looking for a more comprehensive or traditional project management application that works in an agile context, you might be better off looking at Rally Software or some other tool.

In any case, I hope that Mingle's simplicity and slick user interface inspire other vendors to keep innovating in this space.

Sharing Presentation Slides

2007-06-26T16:24:00.000-07:00

After giving a presentation last night, I told a bunch of folks that I would post the slides... somewhere... and distribute the URL on a mailing list. Our Java User's Group is just getting started, so we don't have a way to post files yet. And I don't currently have any hosting space that would be appropriate. What a great excuse to look at some free presentation hosting services!

There are two that I really like: SlideShare and Scribd.

Both are easy to use, and of course you can tag and search. They both have great resolution in the online viewers. Some other services get jaggy letters and diagrams, probably from less sophisticated processing or just being more aggressive about compression.

I highly recommend SlideShare for situations where most people will be viewing the slides online. The default size is just right for embedding, and the "related slideshows" it recommended for me really were relevant. If it could import notes from presentations and export to PDF, it would be perfect.

Scribd is excellent when you expect most people to download or print a copy after they've browsed it online. It can export to multiple formats (including MP3!) and there's a convenient "Print" button. The embedded viewer (Macromedia Flash Paper) has some cool advanced features: zooming, search, copy to clipboard. It also does a nice job with word processing documents, which fall right into its sweet spot.

If you're curious, you can see how my presentation came out:

On SlideShare: Testing in Java
On Scribd: Testing in Java

It's not an "apples to apples" comparison, since I uploaded the original ODP file (ODF Presentation, used by OpenOffice) to SlideShare and a PDF including the notes to Scribd.

This is a pretty useful way to share "traditional" documents. Are there systems out there that provide similar functionality within an intranet?

Videos Introducing Wiki and RSS

2007-05-31T23:47:00.000-07:00

Common Craft explains wikis and RSS quickly and clearly, with panache.

Wikis in Plain English:

Click To Play

RSS in Plain English:

Click To Play

Configuring Pidgin for Google Apps

2007-05-17T13:42:00.000-07:00

Google's instructions for configuring Pidgin with Google Talk have a broken link to instructions for using Google Apps with a corporate domain.

So here's how I configured Pidgin to work with a corporate Google Apps account:

1. Select "Add/Edit" from the Accounts menu, then press the "Add" button.

2. Fill in fields on the basic tab.

Protocol: XMPP
Screen name: johndoe
Server: example.com
Resource: Home
Password: ********
Local alias: John

3. Fill in fields on the advanced tab.

[x] Force old (port 5223) SSL
[ ] Allow plaintext over unencrypted streams
Connect port: 5223
Connect server: talk.google.com
Proxy type: Use GNOME Proxy Settings

4. Press "Save". Don't "Register", because your username should already be assigned.

Pidgin on Ubuntu 6.10 (Edgy Eft)

2007-05-17T12:37:00.000-07:00

Pidgin 2.0 (formerly known as Gaim) has been out for a couple weeks now, and I wanted to try it out. I haven't upgraded to the latest Ubuntu yet, so the normal convenient installation procedures do not apply. There's probably an apt repository or deb file somewhere, but I couldn't find it. So it was time to compile from source. This was made a little more complicated because I wanted to use Pidgin with Google Talk (aka GTalk), which requires SSL support.

Here are the steps that I took to build and install Pidgin on Ubuntu 6.10 (aka Edgy Eft). Maybe it will save time for somebody else in a similar situation.

Disclaimers: Your mileage may vary, since I might have some prerequisites already installed that you do not. There might be an easier way to do this, and I stopped optimizing as soon as I got something that worked for me.

1. Get the source bundle from the Pidgin download site

http://pidgin.im/pidgin/download/source/

2. Extract the contents

tar jxf pidgin-2.0.0.tar.bz2
cd pidgin-2.0.0

3. Install some prerequisites

sudo apt-get install \
    libglib1.2-dev \
    libglib2.0-dev \
    libgtk2.0-dev

sudo apt-get install \
    libnspr-dev \
    libnspr4 \
    libnspr4-0d \
    libnss3 \
    libnss3-0d \
    libnss-db \
    libnss-dev \
    libssl0.9.8 \
    libssl-dev \
    openssl \
    ssl-cert

(Thanks to the Ubuntu forums for tips on the SSL library packages)

4. Configure the build

Override defaults pointing to older versions of GLib and GTK, then generate the makefiles and other build configuration.

export GLIB_LFLAGS=-lglib-2.0
export GLIB_CFLAGS="-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include"

export GTK_LFLAGS="-lgtk-x11-2.0 -lcairo -latk-1.0"
export GTK_CFLAGS="-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include \
       -I/usr/include/cairo -I/usr/include/atk-1.0"

export pango_LIBS=-lpango-1.0
export pango_CFLAGS=-I/usr/include/pango-1.0

export CFLAGS="$GLIB_CFLAGS $GTK_CFLAGS $pango_CFLAGS"

./configure

Add a "--prefix=DIR" option to the configure command if you prefer to specify a custom installation directory.

5. Build the software

make

If that doesn't work, redirect the output of "make" to a file and search for the string "errors:" to see what went wrong:

make > OUTPUT 2>&1

6. Install the software

sudo make install

If you ran the configure script with a custom prefix option pointing to a directory that you can write to without root privileges, then you can run "make install" without the "sudo".

7. Done

So that's it. If you are upgrading from Gaim 1.5, all of your configuration will be copied from the .gaim directory to .purple in your home directory. Your log files will also be moved, but a symbolic link will point from the .gaim/logs directory to the .purple/logs directory.

More about the name change from Gaim to Pidgin:

Pidgin project leader Sean Egan describes the new name in an interview with Ars Technica:

"We like the name," Egan told me. "It was the second choice we all really liked. We were thinking up linguistic terms, and someone mentioned Pidgin. Another developer commented that 'corrupted language' may not be the best thing to associate yourself with, to which another pointed out something along the lines of 'have you ever SEEN people talk on IM?'"

"We all felt that was a pretty valid point, so the name stuck," continued Egan. "It's a corrupted language, much like that used by IM users, it's caused by people talking different languages (or protocols) with each other, and it sounds like a bird known for carrying messages across long distances."

Also, AOL agreed to stop threatening the project with legal action if they changed the name.

Wiki Tips: Joining an Existing Wiki

2007-04-25T10:47:00.000-07:00

It can be disorienting to start contributing to a wiki for the first time, especially if you have used email and document repositories for all your previous electronic collaboration. Here are some tips to help you get started.

1. Find the local landmarks

A wiki server does not provide any intrinsic structure for organizing collections of pages. Teams find different ways to create their own structure. Some wiki software allows pages to be arranged into hierarchical trees, which may not be obvious from the default user interface configuration. You may need to configure your settings to show the hierarchical relationships between pages, or select a specific link to see a tree view the pages. Here's how you do that for Confluence:

http://confluence.atlassian.com/display/CONF20/Tree+View+of+Pages

Even if the software supports page hierarchies, some teams may prefer to use a flat structure with a web of links between pages. If that's the case, find the pages that serve as hubs and main entry points. For example, here are two entry points to the original wiki server:

2. Create pages by linking to them

Here's a time-saver for creating a new page with a link from an existing page. Edit the existing page, add a link to the new page (which doesn't exist yet), and save your modification. Click on a link to a non-existent page, and you should get the page editor with the page's title filled in.

This is also useful for creating an initial outline, leaving the actual pages to be created later.

3. Publish drafts early

"The best reason for putting anything down on paper is that one may then change it." - Bernard De Voto

The wiki and its pages are the most recent draft of a living document, always open for rewriting.

Add content as soon as you have enough material to create an incomplete rough draft or even an outline. Leave markers where you plan to add more information or exposition. Other people will sometimes fill in the missing text, but don't rely on it - you might be disappointed. More importantly, early drafts provide clues about how you are thinking. Your team members may be able to share insights that save you time or open up interesting new possibilities.

4. Sign comments, not content

Writing for a wiki should be in the style of a document, rather than a conversation. (This doesn't apply if you are writing in the form of a dialogue for pedagogical or dramatic reasons!) When inserting comments into the middle of a page, like attaching sticky notes to a paper document, feel free to sign your name. If you have comments at the beginning or end of a page, like notes in the margin, it may also be appropriate to leave your name. That tells your collaborators who to talk to about the comments. However, it is probably best to have that discussion on a mailing list visible to the whole group. In that case, it doesn't really matter if the comment is signed. Resist the urge to put your thumbprint on a piece of content that says "I wrote this!". That clashes with the collaborative spirit of a wiki.

5. Trust the history features

You might be tempted to leave old content in a page, even if it's no longer valid. That's usually a bad idea, especially if it leaves multiple versions of the same text on the same page. If information is obsolete, update it or remove it. You can explain your changes to the team in an email, or possibly in a revision message that the wiki stores in its history.

If people reading the wiki page need to know that some information is no longer valid, then document that on the wiki page.

Most wiki software allows you to view old versions of a page, view the dates and authors of previous changes, and view the differences between two versions. Use those features to look at a document's history, and keep the latest version of the document clean.

6. Put everything in the wiki (unless you have a better place for it)

Capturing information is the first step toward sharing it. If you don't already have a system designed for storing some type of information, put it into your wiki. Most wiki software allows files to be attached to wiki pages, so you don't necessarily need to have a separate document repository. The goal here is to make all information available to the whole team. Don't hoard it on your private email files or local disk drive.

7. Learn to export

If you want to freeze a version of some wiki content, export the pages to PDF or static HTML pages. Your wiki server probably provides some export capability. If not, you can use your web browser or some other tool to download the web pages for safe keeping.

This is also useful for sharing private wiki pages with people who can not access the wiki directly.

8. Watch for recent changes

Good wiki software allows you to subscribe to email notifications for an entire wiki or individual pages. Register for notifications of any area of the wiki that you are working with. You may also want to subscribe to RSS feeds, but only do that if you will actually read them as part of your normal routine.

9. Try editing "raw markup"

After you have become comfortable editing wiki pages with the rich WYSIWYG editors, try editing the raw "markup" text. Wikis traditionally provide a simple notation using plain text to represent formatting. For example, placing asterisks (*) around a word may cause it to appear in a bold font. You may find that it makes creating complex wiki pages faster and easier. Or you may hate it. Still, it's worth a try.

Some wiki software only provides this type of raw "markup" for formatting. If that's the case, you are likely to hate it at first. Give it time. It could grow on you. If not, lobby to upgrade to more modern wiki software. MediaWiki is one of the few popular wiki servers that doesn't offer WYSIWYG editing by default, but even that has a plug-in that can add rich editing from within a browser.

10. Know when to pick up the phone

And lastly, some common sense. If the collaboration is stuck, or if there are conflicting opinions that can not be resolved through comments in the wiki pages, then resolve the situation by communicating directly with your fellow authors. Have a conversation in person, if you are in the same location. Otherwise, you have several options for communicating: email, instant messages, and the telephone. A wiki can be great for collaboration, but it's not always the most effective tool for communication.

Lack of Propinquity

2007-04-17T17:55:00.000-07:00

When is a co-located team not co-located?

(Or "colocated", if you prefer. Or even "collocated".)

The phrase "100 co-located developers" came up in conversation the other day. It was said in passing, but I had a knee-jerk reaction and started spouting off about how that many developers can't be effectively co-located. (Hopefully my schpiel didn't go on too long, because it wasn't really the time or place to get into the subject. That's what this blog is for!) In a large organization, some people will inevitably be far enough from others that they can't be considered co-located. They may be at the same site, but not close enough to have chance encounters in the hallway and arguments over who left the coffee pot empty.

MIT's Tom Allen found that communication between engineers is strongly influenced by the distance between them. This relationship is described by the Allen curve which indicates that engineers located more than 50 meters apart don't communicate with each other any more than people in separate cities. This has been corroborated in other domains since the original research in the 1970's. These findings have been used to design better physical spaces for teams to collaborate and innovate. Cool stuff.

Further reading: