Effective communication is key for distributed Agile development teams. Many technologies and applications are very helpful for improving the communication channel for distributed teams. To name a few: video conferencing, phone, email, wiki, instant messages, text messages, and shared documents online.
A simple and straight-to-the-point update email is a must have for distributed teams. A daily update email sent at the end of the da-=y is named the hand off email. It works like this: whenever the working hours are over for the team members on a given location, the team on that location sends the hand off email for the whole team. Typically, the hand off email provides an effective summary for the whole team and the people interested in knowing how the work progressed. In this brief post I will share a simple format for a hand off email that has been working well for my current distributed project. Please note that such email is complementary and not a replacement for many other effective communication mechanisms.
The Context: my current distributed project happens in between two locations with a time zone difference of 5 hours, a city in the USA West Coast and a city in the south of Brazil. The sponsors and product owner are in the USA West Coast and the development team is in Brazil.
The format for this email has evolved over time. The first version was very informal; it listed everything that happened during the day. The second version followed the daily scrum format; what the team did today, what the team will do tomorrow, and if there is any blocker. The current email format has been influenced by the daily scrum format, the kanban task wall, and workflow stages (as per our card wall).
The figure below depicts the physical card wall used in this project.
From the picture you can see that the story goes through the following workflow stages:
Backlog -> Q -> in Dev -> Q -> in QA -> Q -> Signed off (done)
Q represents the queue prior to an action stage. For example, a story in the Q prior to In QA is waiting for someone to perform QA activities on it. Our team does a tasking of the story prior to moving it to the In Dev stage. The tasking activity and follow up has influenced our card wall and the email format described below.
The following are the story workflow stages listed at the daily email updates. Please note that a story first appears in the email when it goes for Tasking. The team uses other tools for storing and managing the product backlog, the iteration backlog, and the stories attributes and lifecycle. Once again, the email is used for a quick status update, not a replacement for all other tools and activities.
[Story]: Tasking -> in Dev -> Q -> in QA -> Q -> signed off (done)
A story is tasked before starting its development. These are a few sample tasks from a story my team is currently working on: (1) create new JSP form, (2) save JSP attributes in the DB, (3) update automated test for scenario A and B.
Below is a sample email:
Blockers
• This is blocking the team
• This is blocking story N
• CLOSED: yesterday blocker was fixed…
On the card wall:
NEW [Story1] tasking (John)
[Story2] (Story Title) tasking -> in Dev (Mary)
Doing: [task 2.1] task brief description
To do: [task 2.2] task brief description
To do: [task 2.3] task brief description
[Story3] (Story Title) tasking -> in Dev (Paul)
Done: [task 3.1] task brief description
Done: [task 3.2] task brief description
Doing: [task 3.3] task brief description
[Story4] (Story Title) tasking -> in Dev -> Q -> in QA (Phil)
Done: [task 4.1] task brief description
Done: [task 1.2] task brief description
[Story5] (Story Title) tasking -> in Dev -> Q -> in QA -> Q -> Sign off (Sandy)
Done: [task 1] task brief description
Done: [task 2] task brief description
Done: [task 3] task brief description
[Story6] (Story Title) tasking -> in Dev -> Q -> in QA -> Q -> Sign off (Sandy) -> signed off
After a few weeks using the email, the team got used to marking information in bold, italic, underline, colors, or within [] () {}. In fact the email content got a little too colorful, and then it came back to a simple normal and bold text style.
Two final recommendations: (1)keep the email simple and let people do a reply all whenever they feel like discussing further details. (2) Inspect and adapt: the email style should match your team needs, not the other way around.
Posts
