Herding cats

A developer tells the team something will take 2 days. After 3 days, you ask him when he will be done and he answers "tomorrow". After 5 days, he asks for more time. Finally, after 2 painful weeks he's finally done. Your customer is furious and you're frustrated that your developer is slow.

How did this happen? Where did the team go wrong? The developer responsible can't explain why in plain English and everyone is left scratching their heads.

There are two problems here: poor estimating and bad communication. This post concerns communication; you can learn more about improving estimates here.

Standups, duh

The first obvious solution is to do a daily standup with your developers. If you're not doing this already, start immediately! In case you're not familiar, the purpose of a standup is to convey the following information from each developer to the team:

1. What she worked on yesterday
2. What she plans to work on today
3. Any blockers or headwinds to completing her project

If conducted in real-time, standups should last no longer than 15 minutes. As with all developer communication, however, I recommend doing your standups asynchronously via email or Slack so the team can stay focused.

Bug them, but be gentle

When you find yourself needing to pry information out of a developer, try to keep in mind the cardinal rules of developer interaction:

1. Never call a developer on the phone unless production is down.
2. Communicate asynchronously via e-mail, Slack, or project management tool. In writing is always better.
3. Don't interrupt a developer unless the building is on fire.

Respecting these rules will go a long way towards keeping a positive relationship with your development team and will make them more likely to share information with you. It's okay to be persistent!

Asking the right questions

Unfortunately, asking a developer for information is often like inquiring about a teenager's day at school. Be sure to ask for clarification, ask follow-up questions, and repeat back what you're hearing so you're both clear on exactly what is being communicated. Here are some helpful questions to get you started:

1. Why do you think it'll take that long to finish?
2. How familiar are you with the language, framework, or library?
3. Does that estimate include testing and deployment?
4. What's the most difficult part of this?
5. Which requirement is the most poorly defined or is taking the most time?
6. What part of your remaining task scares you the most?

With the answers to these questions in hand you'll be able to work with your developer colleague to reach a more accurate estimate so you can manage other stakeholder expectations.

Don't just do this once, though! You should be asking these questions regularly as the project progresses so you can continue to adjust the approach as-needed.