Talking the Talk – Focus on Goals, not Best Practices (Part 2)

Mark Kilby and Jeffry Hesse

Mark Kilby and Jeffry Hesse

by Mark Kilby and Jeffry Hesse

In our last blog post, we discussed how it’s better to set process goals versus best practices across teams in your organization.  We’d like to continue that thought by discussing another goal we set for our distributed teams: Talking Daily.  This goal definitely aligns with principles of the Agile Manifesto, but it’s more than that.  For any team, (distributed or not; agile or not) communication and feedback are critical to delivering the right thing at the right time.

Why talk daily?

The goal here is to make sure everyone “checks in” on a daily basis.  They have an opportunity to hear team members, a chance to weigh in on key conversations and decisions, and just to be able to hear from another human.

As a distributed team member, if all you do is work “heads down” and rarely come up to communicate, you WILL run into some problems.

Working on the wrong thing

First, you may discover too late that you are creating the wrong thing.  Our business moves quickly and someone on the team will discover something about the system or get feedback from a customer via support or customer success or product management.  There is a very high probability this information could affect what you are working on.  If you don’t connect with someone else on the team on a regular basis, you will end up generating waste.  If you connect with most (if not all of the team) on a daily basis, you are well assured you are building the right thing.  I find most people prefer to build the right thing.  So communicating with some frequency becomes important to them.

Psychological effect

Second, working solo for a long period of time may have some detrimental psychological effects.  There are ways to overcome the effects of solitude when working remote.  The best way is just to connect with your team as often as you can … and it doesn’t have to just be about work.  As a matter of fact, we encourage any kind of communication.  That’s why we established our Lounge in Hipchat.  Anything and everything can be shared there .. and it is.  It allows us to learn more about each other as teammates.

How to talk daily

At this point, you are probably saying “Really?  Do you really need to tell people how to do this?”  The short answer is “no”.  But we do need to make some options available so that people have ways to connect daily that work best for them and their teams.  So while we have the goal to “talk daily”, we try to provide options and not mandates.  Each team has the following communication “tools” available to them at almost any time:

  • Daily Scrum (a.k.a. Daily Stand-up)
  • HipChat
  • GitHub
  • Email (use sparingly)
  • JIRA (our system of record for product)
  • Confluence – (our system of record for process)
  • Telephone (TurboBridge) – everyone has the standard employee phone directory but each team has their own conference bridge that anyone can use at any time.  No reservations or special codes needed.  Just dial the number.
  • Video – via HipChat or Google Hangout

The CLM and Nexus teams tend to use these tools in slightly different ways to meet the goal of “talking daily”.  For CLM, preferred “communication tools” are Jira, Github, the team Hipchat channel, the daily scrum, and the telephone bridge.   Jira (and the Jira Agile task board) is probably the most used of all the tools as it tracks the work of the teams.  This task board is not only visible to the team, but to everyone in the company.  Our colleague Jamie talked about code reviews with Github in another blog post. Hipchat and the team channel is really the “team room” for CLM.  Conversations about the work on the task board, how to coordinate on the work, people checking in and out for the day, and helping folks that jump into the channel to ask questions (like support, customer success and sales engineers) are all part of the conversation of the room and is visible to all.

Key event for CLM team

In fact, the daily scrum is the key event for the CLM team.  In our last post, we mentioned how the CLM product team has two separate scrum meetings as we had two sub-teams.  That has changed since our last blog post.  In a recent retrospective, we had one of our team members shift to another product.  With seven team members remaining, the two CLM teams decided it was time to merge into one team.

The first thing they brought up was the daily scrum and what time that would be convenient for everyone.  They decided to ask the two individuals that were farthest apart in time zones to suggest some mutually agreeable times.  We quickly settled on a new time.  This meeting was that important for the team to synchronize their work.  So we settled on the new time first.  Even though distributed, the team wants to connect and communicate.

The Nexus Team

For Nexus, we function very similar to the CLM team but perhaps with more of an emphasis on email. Being we are spread out so far geographically email can be a fairly useful tool for us. HipChat can move very fast, and we often find the need to channel our thoughts into email threads for decisions around architecture. We however do try and use email only when necessary, or to send out notes. The reason we try and use it sparingly is we do make an effort to talk as a team more often, and sometimes we will setup quick meetings to avoid sending an email. Examples of what we send as notes are Sprint Review feedback, progress from Backlog Refinement meetings, and other information we think would be of interest to our stakeholders.

What’s left?

We’ll save the details on stakeholder communications for another blog post.  So what questions do you have for team communications?  Let us know!

The following two tabs change content below.

Mark Kilby

Agile software project mentor helping organizations achieve profound productivity, increased quality, and intense customer loyalty to rapidly adapt and thrive in today's marketplace. Interests include organizational change breakthrough methods, collaboration techniques and technologies for distributed and co-located teams as well as automation of software construction to allow developers to focus on craftsmanship and quality.

Related posts