The Setup

Recently, I’ve had a few complains about the daily standups. The gist of the complain is that the daily stand ups do not provide any value because of the information been given its already known.

And I agree with the sentiment based on what is currently happening. Most of the time they are a waste of time: There is no sense of progression, no actions being taken, no clear view of the advancement of the project.

The Question

What is causing this current dissatisfaction with the dailies? Is it something inherently wrong with them? Are they just an unnecessary meeting? Can the time be used more wisely?

Now, I do not know the previous experience of the team with dailies. But mine has been quite positive in the past. I have seen first hand the power of the dailies, and I have used them to great advantage to move forward projects.

So, what is different now? What is making them so useless?

The Scrum Definition

First time that I encountered the dailies was when I learned Scrum. What has been done? What is going to be done? Is there any problems? Are the three questions on a daily. I’ve found that the first two can easily be answered with the panel that holds the tasks/user stories and you only have to ask the last question.

That last question is what makes the daily important, on my view. Is the one specific moment when you say: “we have to take action”, without being disruptive nor transforming anyone into a micro-manager.

The System

Dailies, on their own, have no value. They only hold value because there is an specific system around them that makes them useful.

Which are the parts of this system? If I have to distill them, there is just a single one: Tasks that can be completed in one day at most. And take into account, that when I say one day, I actually refer to 4 hours of work. You can never dedicate your 7.5 or 8 full hours to complete tasks. It just doesn’t happen.

Without this single-day tasks the dailies are not useful. They are, in fact, wasteful.

If you manage to have single-day tasks, what are the benefits?

The Benefits

There are several benefits to the use of tasks and dailies.

Visibility

With dailies and single-day tasks it becomes much easier to see the project moving. Or stopping. Because the tasks are supposed to be done in one day at most, you can see the functionality come into life. You can see, as well, if one is taking more than a day, where we have blockers. I have used both digital tools (TFS) and manuals (whiteboard) to follow tasks. There is nothing like getting on front of that whiteboard once a day, everyone, and see what is going on. If you don’t have that specific time where everyone looks at it, is quite easy for people to aboslutely ignore it.

Satisfaction

It is quite satisfying see your project come along. See how the tasks (and User Stories if you use them) are completed at a steady pace. I would say that it reminds me a lot of the mini-dings that Everquest has during levelling of a character. They become a refresher. A small dose of hope and happiness that moves the project forward. A daily achievement that impulses you to continue.

Un-blocking of stoppers

The other benefit is that is very easy to see what is blocking the advancement of the project. And, therefore … often?, unblock it. You, or any other member of the team, will aks “Why this task hasn’t been finished yet?” And based on the answer you will take the appropiate measures: get someone to help with the code, talk with another department to facilitate the task at hand, discard or delay the task, break the task into smaller pieces, …

Knowledge

I have always found that forcing yourself to create single day tasks allows you to better understand what is going on with the system that you are developing. Tasks, unlike User Stories are not created from the point of view of the user, but from the one of the developer. Is there a database here that I need to create? Do I need extend an interface? Or create a new one? Do I have a business layer that I need to change? A UI? Is just a question of adding an Endpoint to my REST API?

These questions, and others, will help you understand the innards of your system. And how the different parts are connected.

The last one

There is one additional benefit. Estimation is difficult. We, humans, have problems estimating. Have you ever seen a big building done on time and on budget? I have not. Though, hopefully, somewhere out there we can find it. That is after 7000 years of construction. It is not a new field.

If we have problems estimating building construction how are we not going to have estimating software development? In the eyes of construction we are a newborn.

I have used story points before. They are complicated, because you still need to give a number. Because that number is a nebulous abstraction of difficulty. They take time to correctly assert. Quite a few tries. And if you have not done a good job of getting the base number correctly (and I’m guilty of it) is difficult to rectify or stop balloning the estimates. Furthermore, the “experience” that you can use to reuse them at a later point is shaky.

Tasks are far more concrete. Very specific time frames. Very small. You can’t go astray. Furthermore, task are much easier to reuse. I believe they give you better traceability. It is much easier to go back in time to a user story done in the past, check the number of tasks and understand what was originally estimated, what was done, what was forgotten to add to the original estimate, and to, therefore, extract learning for the future.

Communication

There are issues with communication. Other than brain to brain, there is no perfect technique of passing information between people. As soon as we have to put down our ideas, through language, formulae or code imperfections will appear.

But even if we could achieve perfect transmission of our ideas there are still issues.

I have found that, if you have more than two people on a team, constant communication is just difficult. There are cases in which information is going to be shared between two people that will not reach the third, fourth or nth member of the team.

“But”, you will say, “we have Slack/Hipchat/other-mass-communication-tool”. They are noise, lots of noise. It is very easy to get information lost on them, drowned by all the other entries that are not the specific information that you want. Fully unstructured (even if you have different channels). I don’t see them fit for this specific job. Replacements for IRC … maybe. But then, IRC was a lot about noise as well.

There is the fact that the PO/PM/BA/SH/Another_Acronym needs to see what is going on. And you don’t want them asking every 5 minutes (or hour) to everyone the state of the project. Single quick meeting everyday, update the board, and they don’t need to pester people.

As a team leader I wouldn’t intervene with someone’s work if it was chugging along. Only when an issue happened I would take action. There will be no block going unnoticed for days. Furthermore, it would help on getting team members to look for help earlier than otherwise.

Conclusions?

Use dailies in conjunction with tasks. If you do, they are a great tool/process to deliver a project.