The hand-off kanban email

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.

Scrum.org -- Professional Scrum Developer and Scrum In Depth

I am pleased to announce that as of April 13th I am an official Scrum In Depth Trainer (the first in Europe) with Scrum.org
Furthermore, I co-developed the Professional Scrum Developer Course (Java) for which I am also a trainer. From June 4-10, I will host the first training with Ken in Zürich, Switherland.

Stay tuned for more trainings and do not hesitate to contact me :) -- Ralph Jocham

I am looking forward to working together with Ken Schwaber and to pursue the success of Scrum.

Cheers,
Ralph

Things ought to be simple

I come to believe that most product development environments and processes are just to damn confusing. Not by nature, but manmade. Let's look at bug tracking. I've spent too many hours of my live with QA and product managers to prioritize a list of bugs.

P1, P2, P3 and P4.

P1 and P2 need to be fixed ASAP because you cannot ship the product with them. Tough luck for P3 and P4 as they probably will rot in the system as there are too many P1/2.

Now let's look at a classical scenario. Programmer A writes code for two weeks to implement feature F for product P. Once he is done -- it works on my machine -- he reports to his manager and moves on to the next task. Meanwhile the testers are busy testing another product S for two more weeks. Then, after two weeks, tester T looks at feature F and discovers some issues. Let's say four of them. Two are bugs, one is a requirement misunderstanding from tester T and the last one just a minor cosmetic thing, a spelling mistake 'Tset' instead of 'Test'. After three days T is done logging all issues in the issue/bug tracking system.

P receives per mail the list of bugs but ignores them as he has to finish another feature. The following week he is done and addresses those issues. The spelling mistake is fixed easily, it takes him only 20 minutes in total. The two bugs are more tricky especially since 3 weeks have past since the implementation and the code is not fresh in mind any more. It takes some time to isolate the problem and fix. 4 hours for either. Now, the requirement misunderstanding. He reads the description again and again and is sure that the current implementation is right. So he amends the entry for further clarification and emails -- ping-pongs -- T.

The next day T looks at the request for more details and, after some mental swearing, adds more details and ping-pongs the bug back to the developer.

P is busy for another two days finishing up another feature and then looks at the bug again. After two hours he is sure that T is mistaken and puts his conclusion in the system. Ping-Pong once more. T reads the reply the next day and actually agrees with P. He sends an email to M the product manager asking for clarification. Luckily, M works long hours and forwards the email at midnight to S the subject matter expert. After two days S replies to M who forwards the clarification to T who puts it into the system and pushes it back to P. Ping-Pong. As it turnes out P was right but not completely so he needs to make one minor change and send it for a final review to T. T looks at it the following week as she is busy working on another product. Six days later T runs a final test and checks it off as complete.

Wow, what an amazing game of Ping-Pong. Corporate Ping-Pong.

Let's analyze it quickly. The whole implementation and testing circle lasted for over 8 weeks. It is driven by the wrong believe that working in batches and specialized silos makes us more efficient. 100% workload equals to 100% productivity. This is plainly wrong.

How would Agile have handled it. I will give a short description using Scrum as the method. First you work in time boxes which are fix, you don't ever make a sprint longer or shorter. (You can adapt sprint length but usually you plan it ahead; also this is often a sign of ScrumBut). In each of those sprints you deliver value to the customer in the form of running and usable software. Being 80% done does not cut it. It is either all or nothing. The Product Owner specifies what she wants ahead and the development Team estimates how much can be done in one sprint. Once the feature set is decided the acceptance criteria are defined with the product owner. Until those are met there is no chance the product owner will accept the feature. Actually the acceptance criteria are only one point in the Definition of Done. The Definition of Done -- DoD in short -- can include all kinds of requirements to be met. Popular are, automated Unit Tests (Verification) and Story Tests (Validation) for all code. If working in a regulated environment, often the DoD also includes the required Documentation.

Next, in Scrum there would not have been two different departments. The team is co-located and cross functional. In our case P, T and M would have been in the same room. M might not be there all the time but a couple of hours each day. So, the corporate ping-pong would not have taken place at all. The typo bug would have taken 2 min without the entire bug tracking system overhead. The fixing of the bugs less then the 8 hours. Let's say 6 hours as the code was still fresh in mind. Finally, the requirement misunderstanding would have lasted not more then 3 days at most. P and T would have discussed it side by side for about 1 hour and then spoken directly to M. Assuming that S still takes 2 days, the 3 days are rather generous.

Altogether we are looking at two weeks, the length of the sprint. Compare this to the 8 weeks in the high productivity setup. Slack, for some people this words is associated with very bad things. In agile, you need some slack to be able to react fast without too much task switching. A good book about this topic is Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency.

Actually, I’ve started to throw out the bug tracking system altogether. It is just too much waste. Don’t allow bugs by building quality in. Whenever a bug pops up, it is being addressed immediately. This might look counter productive but in the long rung it speeds you up. I like to use this metaphor; a bug is like a pothole in the road. So getting from A to B gets slower the more bugs you have. In order to go fast you need to improve the road condition by fixing the bugs. Once you have a state of the art road condition, you can move at high speed continuously as upcoming holes – bugs – get fixed immediately.

I like Sports but not Corporate Ping-Pong!

The future is lean agile!

Mobile Me iDisk and rsync

I’ve been using Mobile Me since 2002. (Then it was called .Mac). One of the features I really like is the iDisk. This is really convenient when you have to transfer large files. Also, I use it to keep a set of files I need again and again for my work as an agile coach. To make the access transparent and fast you can keep a copy of your iDisk on the local Macintosh HD and use it like any other drive. There is a sync process running in the background taking care of the data syncing. Very nice and convenient. In the beginning I could put a symbolic link into the local iDisk to reference a folder with the files on my local hard drive. Then the files were synced onto the iDisk in the cloud and I could access them from anywhere.

However, with the release of Leopard this stopped working. Well, rather annoying but not a real big problem. I just created a folder which I kept up date manually. But, since the iPhone has an iDisk app I started to read and re-read certain documents while on public transport. As you can guess, it happened again and again, that I forgot to do the manual update and therefore could not read important documents.

rsync to the rescue. With rsync you can keep folders in sync. I use it to keep the folder on the iDisk an exact copy of the folder containing the documents.

Well, next problem. Now, I have the copy process automated but I still need to run the script manually. The fix for this is crontab. Crontab is a list of scripts to be executed by the cron demon at certain times. I cannot tell you how much I like that OS X is Unix based. A nice UI with the power Unix underneath, what a great combination.

Now at midnight, the documents are automatically synced from the local folder on my hard drive to my iDisk. There I can access them using my iPhone or my notebooks. (iDisk also has a Windows client).

If you run into the same problems, then hopefully this shed some light onto it.

Productive Meetings

Don't know what your experience is like, but for me it is the following. Meetings are much more productive when someone is standing at a white board and writes down ideas, risks, problems and what have you. I am sure every single human being who has attended enough meetings has observed the default pattern -- or anti pattern -- in meetings. Everyone has their point of view and does all necessary arguing to protect their idea. They fight each other instead of pulling together towards a common goal. Often after a long and useless meeting it is commonly decided (the only agreement) that another meeting is needed.

One way to counter this behavioral pattern is to mail out an agenda with all the topics and asking the participants to prepare. This might help but most often it does not. I even doubt that every recipient of the mail does read it entirely. It usually drowns in the sea of more important emails.

Now, imagine you are in a pissing contest meeting and someone gets up and starts to write the different points clearly visible down. In a heart beat the whole meeting has structure, everyone turns their head towards the board. Not the loudest voice is heard but all ideas. Often, after some time the whole group is working together towards a -- just identified -- common goal. If you don't believe it, then give it a try at the next deadlocked meeting. You will be amazed how much power a white board and a marker in hand can create.

Why am I writing this? Well, Scrum has this at the core of all of it's meetings. In Scrum we have four different meeting types. Sprint Planning meeting, Daily Scrum, Review and Retrospective. Usually each of those meetings is moderated by the Scrum Master. It might be moderated by someone else but it is always moderated! The medium to write on are either index cards or PostIts which are aranged on a white- or corkboard. Those cards are then updated and rearranged during the course of the sprint. A very visual way of management. Alistair Cockburn named it accordingly: Information Radiators.

Next time your are stuck in a non productive meeting just get up and start to use a marker and whiteboard. Everyone in the rooom will be grateful.

The future is Lean Agile.

PS If you are interested in a simple way to moderate a meeting then try out Edward de Bono's Six Thinking Hats

Pomodoro Technique

About one and a half years I made a huge mistake. A mistake which cost me lots of productivity. One and a half years ago I read about the Pomodoro Technique and was excited about its approach. I even printed out the free PDF. My mistake was to totally forget about it. So never read the PDF and did not learn about this great technique for too long.

Since I read a lot of books from The Pragmatic Bookshelf, I was surprised to see that they published a book -- The Pomodoro Technique Illustrated -- about this powerful approach. So, I got the book read it over the week-end and finished with the free PDF from Francesco Cirillo on the following Monday. Reading about the Pomodoro Technique was a great and enlightening experience. I come from an agile background and do agile software development since 2001. First XP and then added Scrum by 2004. In my professional life I do Scrum trainings and agile coaching. So, it was great to see the similarities between Scrum and the Pomodoro Technique. It made perfect sense to me from the get go.

Well, needless to say that I am a convert now. Being a consultant, I am often on the road at customer sites and only focusing on one thing. However, between projects or every couple of weeks I am working at the home office for a couple of days. During those days I have to work and catch up on many different things in a short time frame. In the past it was hard to get going and keep the overview. Too many urgent tasks, and at the end of the day the feeling that something important was forgotten. Pomodoro Technique to the rescue. Know I keep an Activity Inventory up to date and on my office days I go through that list and identify the most important ones, either by date or by priority. I get about 10 Pomodoros done in one day. At the end of the day I reassess what I was planning to be, were I actually am and how I could improve. With that in mind I go into the next day.

As I had mentioned, there are some stunning similarities between Scrum and the Pomodoro Technique, here is a list of how I compare them.

Scrum             Pomodore Technique

Product Backlog   Activity Inventory List
Sprint Backlog    To Do Today List

Sprint Length     Pomodore Length  

Review            Assessment at the end of the day

Retrospective     Assessment at the end of the day

I can only stress how effective the Pomodoro Technique has proven to be for me and I would recommend it to anyone who has to juggle several tasks in parallel. If your are an agilist then applying the Pomodore Technique should be rather easy.

Ring …. 25 minutes over – 5 minute break and then of to my next task.

Agile is about Deliverables

I just came back from a wedding which took place in a small remote place in northern Bavaria, Germany. What does a wedding have to do with agile software development? Nothing at all, but quite a bit.

The bride and the groom are both living in Paris, France. She is from Germany and he from Algeria. The location of the wedding was chosen for one single reason. A relative of the bride´s family owns a hotel. This guaranted excellent service for a competitive price.

Ok, now I will elaborate about my epiphany I had there. But first here it is:

Agile is about deliverables

whereas

Classical processes are about completed work steps

What do I mean with this? In classical, Taylorism style driven workflows you are completing work steps in a long sequence. If you have 10 steps and are done with 8 you have 80% completed.

In agile it is about usable deliverables, value. It either exist and can be used or you better don't mention it. 0% or 100%.

Now, as you can see from the geographical distribution it was not straight forward for everyone to be there on time. Some people only had to drive, others took the plane or train. Many of them had a combination of all sorts of meaning of transport. Also, as it happened, there were snow storms all over Europe with tons of snow and really chilly weather. Those weather conditions caused quite some traffic havoc.

Nevertheless, every single person was there on time. Not one single one was late. They all were standing in the church when the bride and groom walked down the aisle.

They delivered. They delivered value by being there and paying their respect. I am sure many of them had quite a stressful adventure behind them but all of them only smiled at the couple.

The alternative would have been the following. Imagine the phone ringing and a conversation sounding somewhere like that: '... we are 90% there. In the beginning everything went according to plan but then there was an accident because of the weather ...' or '... we heard about the weather but we assumed everything will be fine, but now the airport is shut down for a couple of hours, we will arrive tomorrow. Guess this is ok?'

Don't track and communicate your progress in regards to your work steps but deliver value. This is the ONLY important thing!

It was a great wedding, mainly because everybody was there!