You ask for a status update.
The engineer stands up, clears his throat, and begins a long epic of wrangling Cassandra to integrate with Rails. The process uncovered a strange issue in Bash not being able to get the right Ruby version, so the engineer had to go talk to another engineer which thought he needed reformat the computer. Which ended up wiping out his saved changes because he forgot to commit his code. And then he lost his backpack and a mysterious old man appeared offering a AWS decoder ring with an important quest. He had to help the old man because… [1]
You get the point. He’s had a rough week.
But he’s not done. The project is not ready.
You begin checking in every day and you do daily stand-ups. You’ve lost trust in predicting schedules. You may run the risk of annoying your engineer.
What I would do instead is be completely okay if the task is not done. Revisit the plan. How closely was the plan followed? What went wrong?
Try asking the following questions, “Okay, you can’t hit the deadline. What do you need to accomplish the tasks? What’s blocking you?”
I also add, “How many more days do you think it will take?” But I never leave it at that. I’ll ask for steps to finish the project. As you talk this out, you can rework the plan for a better estimate.
Do not accept a “oh we’re like 99% done.” That 1% could take another week. If the code can’t be shipped, the project is still in development.
Projects are only done when they’re done. Duke Nukem Forever. [2]
[1] He gave up and dropped the ring in the volcano.
[2] Duke Nukem Forever – A game that took over 10 years to finish. And the creators were famous for saying, “It’s done when it’s done.”
Leave a Reply