Iteration 35: Building a better way to communicate with your team

The work I did in this iteration was all about communication.

I've started building a messaging system. You'll find screenshots below, but before we get into that, I wanted to say a bit about the pros and cons of communicating online, rather than face to face.

When converations beat email

I'm a big fan of the traditional approach to agile communication. It's best done face to face. Sending emails is convenient, but in many respects it's a poor substitute for getting up from your desk, walking across the room, and having a chat with a colleague.

Imagine for a moment that you're a developer who needs clarification from the product manager about how a feature ought to work.

If you fire off an email you'll normally get an answer to your question, but it's often a different answer to the one you'd have got if you'd spoken to the product manager face to face.

Irrespective of whether they've understood your question perfectly, the product manager (under slight pressure to solve the problem quickly, so that you can carry on with minimum disruption) is likely to suggest a solution.

As the developer, when you receive a proposed solution from the product manager you might have a nagging doubt about whether it's the right one. Do you question it? You don't want the PM to think that you don't trust their judgement, so there's a slight pressure to implement their proposal without asking for clarification. Were you sat next to each other getting clarification would be easy; you'd just ask, and they'd tell you. Or maybe they'd realise they'd misunderstood your original question, and you'd both hash out a new approach.

I'm sure you get the gist of what I'm getting at:

• Good communication is vital to the success of your project.
• Email is a poor substitute for face to face conversations when you're thrashing out what you ought to be building.

For a long time I resisted pressure to implement a way of sending messages from within Agile Planner. I didn't want to build a user interface that would exacerbate the trend in poor communication that I've seen in the wild, but it's been clear for a while that Agile Planner needs a messaging system.

When email trumps conversation

There's also a place for written communication. It's ideal for:

• Keeping the rest of your team up to date on discussions and decisions that they've missed.
• Sharing information in distributed teams (of which there are more and more, these days).
• Staying in touch with people who work unusual hours, or who spend time working from home.

As agile practitioners, we just need to stay mindful about whether we're communicating in the most appropriate way.

Once I'd accepted that messaging was required, the next step was to work out how to approach it.

Designing a better UI

Some planning tools allow you to write comments that are shown underneath the description of a story. Writing a comment causes your comment to be emailed to interested parties, so developers often use these comments to ask for clarification on how things ought to behave.

As I outlined above, verbal communication works better here, but let's assume for a moment that it's not an option. Are comments a good way to approach it?

In a nutshell, no. There are two primary reasons:

1. Some stories generate a lot of questions, on several topics of discussion. It's not fun digging through a torrent of unrelated comments to follow the particular "thread" of the conversation that you're interested in.
2. Comments that clarify the intent of a story are shown on the same screen as the description of the story. This makes it easy for a product manager to fall into the trap of assuming that these comments serve as an update to the story, even though the story's description (which is now out of date) has remained unchanged.

When these two situations are combined on the same story, you're just one step away from a cock up. Stories that don't reflect the product manager's current intent have become commonplace on some projects.

Developers (who might come along a few days or weeks later) will assume that the stories they read are an accurate reflection of what they need to implement. When they start work without scanning the comments for "updates", they're likely to be wasting their effort.

So how can we discuss our stories (in writing) while encouraging people to update them as their understanding evolves?

I think the solution is simple; we shouldn't display comments about a story on the same page as the story itself.

Overview of our messaging system

Here's how it'll work in Agile Planner:

• Agile Planner will allow anybody to start a new discussion.
• Like an email thread, discussions will have a one line subject, and a series of messages.
• When creating a discussion you'll be able to choose who you'd like to be notified (emailed) about it.
• Discussions will be automatically linked to cards that are mentioned (e.g. "card 42" or "#42") in the text of a message.
• When viewing a story card you'll be able to see the subject heading for discussions that refer to the card, but you won't be able to see the contents of the messages themselves.

I'm hoping that moving the contents of the conversation off the same screen as the story will encourage people to update their stories to reflect the latest thinking. If it's not on the same screen, you're less likely to assume the messages will be read.

Screenshots

You're still here? Blimey – hats off to you, that was fairly dry stuff! Time for some pictures…

If you want to discuss a story, there's a link underneath the card:

Kicking off a new discussion is pretty simple. Note that a card is mentioned (by it's number) in the text of the message – this creates a link to the discussion, ensuring that this conversation will be linked to from the card.

In future you'll be able to upload files with your messages (useful for iterating on designs, or sending people documents).

Replying is similarly straightforward:

Back on the story page, we can now see a link to the conversation:

Retrospective

So how did this iteration go?

I'd expected to complete 2.75 points of work this fortnight (my points scale is a little unorthodox, so don't worry if that seems low), but I only managed 2 points worth. I took a couple of unscheduled days off, and procrastinated my way through another two.

When procrastination sets in it can be crippling. I lost my motivation on a Monday morning when I failed to get stuck in early enough. I had plenty of motivation when I first woke up, but made the mistake of taking a "quick" market research call from a company that wanted to chat to entrepreneurial developers. I gave them plenty of feedback on their product (which was fun), but by the time I looked at the clock it was almost lunch time. I'd been distracted, and never really got started in the afternoon. I should have scheduled it for late in the day, by which point I'd already have got lots of work done.

I had two days off for unavoidable medical appointments, but there was no excuse for procrastinating my way through the fourth lost day. I'd been feeling a bit guilty about having missed three days already, and it seems that was just enough to divert me into spending the rest of the day researching cameras. Whoops.

This is the kind of thing you need to watch out for when you're working for (and paying) yourself. The freedom's great, but it can be a problem if you don't manage your time effectively.

All that aside, I'm very pleased with the beginnings of the messaging system that I've built so far. Once I've added email notifications (with an option to unsubscribe from discussions that you're not interested in) it'll be a really useful way to get clarification on stories and communicate with remote team mates.

Onward! :-)

I love feedback and questions; please get in touch on Twitter or ask a question in the comments.