In my experience one of the hardest things to get from a technical team is honesty. I don’t mean people are being purposefully deceitful. It’s not a question of ethics. I mean people have a hard time facing the truth themselves. It’s an often repeated axiom that programmers are overly optimistic. I’ve come to think of it as learning to be honest in the assessment of the situation.

Honesty is facing up to where you are on a task. Often times in a stand-up, I’m thinking about a task that I’m working on in terms of how many hours I have left. In a highly functioning team we may not need to think in terms of hours. But an individual who is in control of the work they’re doing is thinking about the number of hours left on a task and how they can complete it. When we start a story, the hours are the entire estimate for the story. After working on it for a day, an honest reporting of how many hours I completed and how many hours I have left is how I improve my estimate and track my actual hours.

Honesty in the stand-up helps continue to improve our estimates as we do work. In the stand-up, I’m thinking “I spent 4 hours on it yesterday and I have about 8 hours left to work it to completion.” If the task was a 4 hour estimate originally I now have much more information about the task that I need to share; and that has impact on the progress of our iteration. Although it’s less common, the opposite situation is just as important (when we spend 4 hours and complete a task that we estimated at 12 hours). At the macro-level our highly functioning team can report out “I finished yesterday” or “I’m going to finish today” if that’s a reliable statement. If not we need to dig deeper to improve our predictive ability.

Why is it easy to avoid honesty in the stand-up?

It’s very easy to avoid honesty in the stand-up. We’ll talk about a few reasons why; I’m sure they’re not exhaustive. I see these reasons very often with less experience people or teams.

We forget some of the details behind implementation and we aren’t secure to admit our oversight. It’s hard to admit we’re wrong. Especially if we’re trying to prove how good we are - new team mates, new boss, new project. We want to prove we’re right. And if we miss something in the implementation of a story we would much rather cover over it and smooth it out without having to say in front of everyone “I forgot that this API was used over here so I have to make sure it works in both places."

We get surprised at the difficulty that a previous decision has made this current task. It’s hard to admit that we took a short-cut before that makes this harder. This comes from incurring technical debt - something to talk about managing at another time. We will make choices to incur technical debt for all kinds of reasons. Many of them are good reasons. And when we come to a point where that debt makes our next story harder (before we’ve paid it off), it’s hard to be honest that we took a short-cut before. So now we’re trying to refactor a short-cut and implement a story; and it’s embarrassing to have to admit that the short-cut before is putting our current story in jeopardy.

We want to control the story by continuing to own it even if it’s bigger than we thought. We love owning things; we love the sense of completion. It’s why we became programmers in the first place for many of us. When a story gets out of hand and the estimate gets bigger, asking for help means giving away some of the control in how this story is implemented. This sense of ownership can be moderated if you have fostered a sense of ego-less programming (also common code ownership). But it’s natural that someone one your team is going to have a favorite way to implement something and desire control to see it through. We don’t want to see our story split and given to someone else

We fear missing our commitment. As much as we aren’t great at being honest about the situation, in the end it comes from a good place. We don’t want to disappoint. We don’t want to miss our commitment. Either explicit or implied, there are expectations we don’t want to miss. So we’re apt to hide from deviations in the hope that we can overcome them before they end up with big consequences.

How to encourage honesty

It is easier to tackle specific root causes If you identify some of the above as reasons why it’s hard to get honesty from your team. As a leader, you can direct positive reinforcement to downplay the fear. There are some overall tactics you can use with your team to drive increased honesty in your team stand up.

Encourage continuity between stand-up updates

One of the very best things about stand-up meeting is the cadence and frequency. They’re meant to be daily and short. And therefore there isn’t time to forget what happened yesterday. We use it as a feedback cycle to help one another get things done. Often it’s mistaken for a reporting meeting; status on the story. And while you can often get status on a story from the meeting you can get status on a story many different ways. It’s intended to surface roadblocks and ask for help; and offer to help one another. One of the best ways to identify when help is needed is to pay attention to what folks are saying from one meeting to the next (“you planned to get this done yesterday, how much is left?”). They can use your perspective to see what they may not -that they’re struggling with something they didn’t expect to struggle with.

When things go long, ask “How can I help?"

So what can you do if someone is struggling. Or if you see them struggle and they don’t realize. Ask “how can I help?” If you see yourself struggle, ask for help. Or just say “this is taking longer than I expected.” The honest of the situation in the stand-up will result in a supportive team taking action to help you out.

Pay attention to when folks are working longer hours to complete the work they expected

When folks are working more than you expect from them, or more than they usually do it’s another sign that things are going sideways. You can ask “are you able to get out of here at the normal time today?” Or “are the hours your working sustainable?” Remember one of the keys to agile development is sustainability of the work. It’s continuous, repeatable and sustainable.

Context switch stories more frequently.

Context switching isn’t for everyone. The act of shifting story ownership mid-stream has some overhead. The benefits are many for a team that can commit to doing it. It creates a hard-wired culture of code ownership. Everyone works on every story throughout the iteration. Setting the expectation that if you start a story you won’t finish it removes some of the hidden reasons to avoid honesty.

Hold everyone accountable

Pay attention in your stand-up. Ask yourself if you are being honest with your own progress on stories. Engage your colleagues; ask them if they have a hard time owning up to the status of their stories if you see the telltale signs. Ask for help. Ask to help.

If it feels like you’re ending your iterations with a big push to finish and accept stories; start paying attention to your stand-ups early. A two week iteration isn’t long enough to not be making good progress in the second or third daily stand-up. And if the problems only show up late in the iteration you probably need to ask whether you’re getting full honesty in the stand-up throughout the iteration.