What does done mean?
Clive Beavis
Ex-Meta and 40 years of Software Development Management focused on Engineering Efficiency, now hands-on with compilers again.
Software development is non-deterministic. Predicting time lines is difficult, even impossible.?
Missed expectations can easily develop mis-trust across stakeholders.
In my experience one of the biggest sources of the problem is a difference in understanding? of what “done” means among the stakeholders.
Why done matters
Imagine a product manager has an idea for a new feature. She talks to a senior engineer “how long would this take to build?”
He replies “about a week”
From this brief interchange the two parties leave happy, though with completely different expectations.
The PM thinking “new widget in production within a couple of weeks (Everyone knows you always double the engineer's estimate :) )”
The engineer thinking “That’s a good idea. Wonder when we will have time to slot that in the priority list.? Of course it’s going to take a lot longer if someone less familiar looks at the code”
Two weeks later the engineer’s manager is confronted with “Your engineer said we would have this in the product by now. What’s going on?”??
Perhaps it’s only me that this has happened to, many times?? ??
When are we done?
The above scenario is may seem a little extreme, though it is absolutely real in my experience. You could of course force everything to go through a project approval process.
However even when we really believe we have agreed and scheduled a deliverable. Still these miss communications persist.
The question to align on is - When are we done? e.g.
This gap in understanding of Done can and does lead to a lot of missed expectations and creates that mistrust among the stakeholders.
领英推荐
All of the above can be valid “Done” states. Getting clarity at the beginning is critical to aligning teams, meeting expectations and building trust.
What does done mean?
Anyone that has worked with me will likely have heard me ask this question.
Program management processes use “Release Criteria”, a heavy weight version of the same thing. I see eyes roll into the tops of heads, mine included, when Release Criteria is mentioned. The problem I have with release criteria is it is hard to see the wood for the forest (trees if your in the UK) as the list of release criteria becomes lengthy. Worse also implicitly says “I don’t trust you, so here is a checklist to make sure you doing your job right”. Dividing rather then aligning teams.
Keep it simple, what is the end state we collectively want as a team? It is likely somewhere between
For the latter it might make sense to have multiple internal steps that each can have its own Done state.
Iterative Development
Many development organizations implement some form of iterative process as a way to keep all stakeholders aligned on the progress vs expectations. Personally I have been practicing iterative development for over 40 years (topic for another post) and would not use anything else.
Depending on your preferred iterative process you might spend more or less time on the end state for a given iteration.? Agreeing the shorter term Done states for features, as opposed to the individual iterations, can be hugely valuable for agreeing and meeting stakeholder expectations.
One project I worked on was very uncertain in terms of even being viable.? We set a goal of getting a target metric, an error rate, below a certain value.? This was our proof that the project was potentially viable. We were done with the speculation phase and could move on to much larger more ambitious parts of the project and add more resource.? My point here is that Done does not have to be an external deliverable. It simply has to be something that everyone aligns on.
Done!
"Our time is up the show is over, thought I'd something more to saay." So yes I’m Done. At least as far as this article is concerned.
Oh wait what about replying to comments ??
Are we ever truly done?