Defining Success - Part 1: When Done Is Done

An old colleague of mine recently reached out to let me know he’s been enjoying the posts I’ve written over the last few months. We worked together at a couple of different stops throughout our careers and he reminded me of something we used to frequently discuss.

During a particularly large implementation we worked on together, we had a big team, comprised of both on and off-shore resources; developing a complex, enterprise grade communication system that involved mobile, middle-tier, back-end, and business intelligence with various integration points.

We were running several independent work streams using agile and holding regular project updates (i.e. scrum of scrums) but kept experiencing issues in which a team would complete a piece of the work and it would fail during the merge, leaving our code base in an unstable state.

We’d investigate each team and discover that what was marked as “Done” was in fact not done. The development team would complete their work and mark the user stories as complete but fail to run their unit tests or complete their merge activities. In some instances, they would fail to coordinate with the other team in order to ensure their individuals pieces could coexist and work together using the same libraries.

We held numerous internal meetings and pulled the leaders from each team together to discuss how we could better communicate across all functional areas. We needed to ensure what was marked as “Done” was, in fact, “Done”. We started asking this question to the teams: “Are you done, or are you done done?”

While a bit tongue in cheek, it became the catch phrase for this release across our teams and proved very useful during our scrum of scrum meetings. A team would report a feature complete during these discussions and someone would ask: “Are you done, or are you done done?”. This would inevitably lead to some great discussion about the true-state, uncovering missing tasks or work that needed to be coordinated. It became an essential question for these meetings and the team’s behavior began changing; ensuring that when they said the work was done, it was in fact done (done).

My colleague who reached out reminded me of this phrase, telling me he’s still using it with his teams today. It was a great reminder that teams need to focus on their individual sprint deliverables but also keep in mind the overall release goals and how their work will ultimately make it to production.

Welcome to 2021! I wish you a successful year and that all your projects may get to done done!