Have you ever had an engineer tell you that they were done and then found out later that what they meant is that they had solved the problem in their head, not that they’d coded the solution, tested it, or deployed it?
Let me be 100% clear. When this (or less extreme examples) happen, the problem is not with the engineer, it’s with your question.
I’ve been this engineer and here’s what happens. I go deep into some problem space and push out everything else so that I have an empty head that I can apply completely to the problem. I stop thinking about my personal life, the blogosphere, and most definitely anything that I happened to have guessed about the project plan and the pressures that my manager is facing.
Then I’ll reach some milestone for a personal goal related to the problem, “Yes! I’m done sketching the solution.”
Right after that, right after I’ve just started a personal celebration for being done with some important-to-me milestone, some manager will ask if I’m done. “Yeah! Want to celebrate me?”
But we’re talking about completely different things and neither of us is being clear. The person asking is in the context of some conversation from a few days ago and I’m in the context of what I was just working on 30 seconds ago.
There’s a really easy solution to this common miscommunication that doesn’t involve any blame or hard behavior changes. Your team just needs a common definition for done and an unambiguous way of referencing it. Enter “Done, Done.”
Done, Done
Stop asking, “Are you done?” and start asking, “Are you Done, Done?”
I learned this phrase from Luke Hohmann at his agile product development firm, Enthiosys. I’m pretty sure it’s at least relatively common in Agile circles.
So, using Agile as an example, your team definition of a task or user story being Done, Done might mean the task has been coded, meets team-wide code standards, includes test coverage, and has been peer reviewed.
You should come up with your own definition with the help of your team. Explain the concept and then have them put things that might be in the definition onto a white board. Then go through and decide together what’s in and what’s out.
That’s your first pass although you’ll want to revisit this both because your first version won’t be perfect and because your product priorities change.
The development team’s API for product
Luke is the person who first made me realize that Agile artifacts are an API for the development team. Tasks, projects, or user stories get passed to a development team and Done, Done defines the format for what the developers return.
Think of what the product roadmap, velocity, and story points look like to the product manager. Suddenly they never have to (although they will anyway) ask developers when something is going to launch. They just have to look at your velocity and the number of story points that they want to include in their launch. If they don’t like the answer then they can drop stories and features.
The better this API gets, the more autonomy and fun both roles get to have.
Ready, Ready
Agile was a big step forward. But Lean is even a bigger step forward because it introduces the idea of validation.
Not everyone thinks this, but I do: having validation means the developer can make product decisions without having to go through the product manager.
Maybe this is the wrong tangent for this post. All I really want to say is that because we’re into validating our work a la things we gleaned from The Lean Startup book, we ended up needing a stronger definition for the beginning of a project.
Before we start coding we need to create some sort of hypothesis about the result we’re shooting for and then take some sort of baseline measure. Enter Ready, Ready.
Now before we start work we have a checklist to make sure we’re ready. And me, the super disciplined product manager, has to actually put some thought into what’s going to makes for a clean, measurable, coherent iteration.
The Checklist Manifesto
I saw The Checklist Manifesto guy, Atul Gawande, speak recently. He’s a doctor that found an amazing way to reduce deaths after surgery: make the surgery team follow a very basic checklist that includes things like discuss the upcoming surgery as a team, have everyone introduce themselves, wear gloves and masks.
Implementing the checklist can reduce complications and deaths by as much as half.
The two main problems with the checklist are that it’s easy and that it’s patronizing. Nobody makes any money by selling the checklist. And it doesn’t help cowboy surgeons feel more cowboy. But it works. Weigh that tradeoff for your next surgery: 50% reduction in your chance of death or boost your surgeon’s self-esteem.
Checklists work in other places too and that’s exactly what Ready, Ready and Done, Done are for developers and product managers.
We think we’re super disciplined, but we’re not. So reducing missed steps, errors, and sloppiness is part of the benefit.
The other part is that now we have a structure for coming to an agreement and adjusting for problems. It’s not really bureaucracy because the definition comes from within the team.
I always want to move faster and rather than rushing people to cut corners in their code (i.e. micromanaging the pace), we can control the basics of code quality in the Done, Done list*. Likewise, we’re experimenting with ways to learn more as we go, and a lot of that gets reflected in our Ready, Ready list.
Jon (my co-founder) and I are major cowboys who are oblivious to risk and live every second on the edge (not really), and checklists look controlling at first. But once you start using them you realize that those are details that you don’t need to keep in your head anymore. That leaves more space for actual thinking and creativity.
That’s all. Please leave a Comment, Comment.
* Scared? The main thing we pushed on was doing the simplest possible thing that works for the first cut, i.e. handle it with Rails defaults before building a more permanent Javascript (Backbone) solution. I’m sure we’ll reverse that when we’re more confident in the configuration of features that matter.
