What is Done?
Few things blow up software budgets, timelines, & deliverables more than a misunderstanding of what constitutes completion. Let's explore how bad things can get as well as how to get on the same page.
There is no way that we can select a set of measurements before the goal is defined." —Eli Goldratt, Theory of Constraints
“When you assume, you make an ass of you and me.” — Unknown
Consider this innocuous request: can you clean up the kitchen? While the answer may be a simple yes or no, the amount of effort it will take will depend largely on the person asking, whether or not guests are coming, and just how messy the kitchen is at the moment. It could take 5 minutes if you just need to declutter. It could 20 minutes to clean the dishes. It could take over an hour if you need to dust, vacuum, and mop.
This simple thought experiment is one of the reasons that estimations in software development can vary wildly. Different stakeholders may have different definitions of done that were not surfaced early enough in the conversations. This is why I love the user stories structure within the agile scrum methodology. It explicitly prompts a discussion for the “conditions of satisfaction” or “acceptance criteria” for each task. Inevitably, assumptions will be surfaced and clarified.
Highlighting the Extremes
When introducing someone to the concept of acceptance criteria, I often reference the (rather extreme, but appropriate) view by a member of the DevOps community by the name of Kris Buytaert. In an article he wrote What done REALLY looks like in DevOps , he challenges the concept of what is considered “done” from a developer perspective with that of his role as a member of an operations team supporting the uptime of services (websites, APIs, etc).
His viewpoint is summarized by the following 2 sentences:
"Done is when your last end-user is in his grave"
In other words, when the application is decommissioned.
I could spend a lot of time rehashing historical challenges between developers and operations, but a large part of it boiled down to different areas of responsibility. A developer might get a feature working on their local machine and consider that a success. However, when that work was handed over to an operations team, that same code would fail in production due to differences in server configurations and a myriad of other reasons.
Falling Short of Lasting Change Within a Team
I’ve had similar situations play out in companies I’ve been involved in where a combination of rapid team growth, a high volume of customers, and a huge wishlist of internal initiatives led to a lot of false starts and abandoned efforts. Here’s a personal example to illustrate how this tends to play out:
Team member (me) identifies a problem (we're unable to quickly and accurately ballpark an estimate for an RFP). Team member goes through many 1-off situations before he/she has “had enough” and wants to solve the problem for good. Said team members create a tool to solve the problem (the project estimator template is born!) and uses it for all RFPs moving forward. Nevertheless, it's a net win and the person (me) is so excited that the pain has been reduced that he/she shares the template and moves on. Others try to replicate the process, but the document has lots of assumptions and is insufficiently documented. Other users try to make due, sold on the fact that it's better than nothing. However, these same individuals often feel like it’s no better than their existing processes because they are not realizing the gains that the person who created it.
The fundamental issue? I considered the issue closed and moved on, falling back to the same mentality of a developer that says "works for me on my machine" and can't empathize with others trying to take on and support the process.
Redefining Done for Team Norms
I want us to challenge you to change where you draw the finish line when implementing changes that affect others. No, I don't want to adopt the extreme view of Kris, because I feel there has to be a more pragmatic finish line. However, I do think we need to consider the following:
Delivered: At a minimum, does the solution exist?
Documented: Could someone else perform the task in your absence?
Distributed: Was this announced to everyone affected by the change?
Trained: Have the end-users verified that they can successfully use it?
Training: Do we have a mechanism in place to train new team members?
It’s important to note that most people or teams will stop at 1. However, in my experience, there will be no lasting impact unless you’ve at least made it to step 3. If you and your team are serious about making a lasting change in your organization, this should become a short-term baseline. Long term, if you can consistently reach for steps 4 and 5, you will get the most benefit out of this approach.
Final Reflections
Looking back at some of my frustrations and pain points over the past decade, these steps could have saved 100s if not 1000s of hours of wasted time across my various teams because of all the course corrections that were needed. It’s counter-intuitive, but slowing down to work through these assumptions and properly define the true finish line will ultimately speed things up. It just takes the discipline to do this despite the fear that you can’t afford the time to do this right given the workload in front of you. However, if you’re not even sure where the finish line is, no amount of running and effecting will consistently get you there. That is why it’s critical to continually re-assess the situation by asking the simple question… what is done?