What is done Baby don't hurt me
- productivity
- business
- non-technical
Done is a relative concept. The majority of the project/programme/initiatives I’ve been part of have included effort towards agreeing the formal definition of done, whether that’s part of a Programme Kickoff or within a Statement of Work. However, where Statement of Work approaches are explicit and robust, project approaches are disconnected and occasionally delusional.
This article has been prompted by a project completely unrelated to any clients.
More on that project in the future!
Ownership ¶
The SoW includes consideration towards where ownership begins and ends, ie, a working context. This is part and parcel of a contract which has its very nature rooted in two separate entities trading. The SoW recognises that those entities are separate and explicitly defines the separation. As part of that separation, the ownership of activities and other concerns must also be separated.
This is the same across most of the commercial world. The most relevant example considering the topics of these articles would be the AWS Shared Responsibility Model. AWS won’t let you know where its datacenters, hardware and physical assets are or how they’re managed. That’s the AWS domain so the responsibility to keep those assets secure and operational within the bounds of the service agreement must rest solely with AWS.
On the other side of that, AWS absolve themselves of both access and management of the software, architecture and non-physical security of your AWS hosted technologies. That’s where AWS ends and you, as the user, step in and take whole responsibility.
The boundaries are so explicit, they slap it in a diagram on the open internet:
AWS can and will help you with the areas that you contractually control, but it comes under their Professional Services model where they’ll deploy a consultancy team with agreed responsibilities specified in a - you guessed it - statement of work.
Not only does the statement of work indicate who is responsible for what but it’s also a de facto definition of done. If all the elements in a Statement of Work have been completed by the relevant entity then whatever has been delivered has been delivered. For that entity, it’s done. The product may not work, or it may be completely unusable. It could also be total shit, but if it matches the SoW then the current tasks are done.
Definitions of Done ¶
In my experience projects, and specifically typical project teams, don’t have the same clarity of ownership as exists under a Statement of Work. The attempt at this is the definitions of done but they’re usually a fuzzy construct that doesn’t offer the same brutal reality as a Statement of Work.
Playing with the idea, if we were to fully scope out all the steps and responsible entities involved with delivering a piece of work, the usual product delivery turn around would look something like the below, with numerous parties, optional steps and deliverables required before even starting work. Spewing out some examples off the top of my head, below are the generic steps involved in a simple product update alongside who could be involved, who is responsible for most of the work and the potential time scope for the item to be completed. This is not a final list but a rough outline. There’s at least three typical things that need to happen before work can even start under the Prior to Work Commencing steps and then any number of places that Implementation and Delivery can take us:
Prior to Work Commencing
| What | Involved | Potential Timeline Scope |
|---|---|---|
| A full user story has been provided and approved for the functionality | Product Manager / Whoever raised the issue | Immediate - ∞ |
| The functionality has been estimated by the team | Whole Team | Part of at least a 1/2 hour meeting, usually longer |
| The functionality has been prioritised against the backlog | Product Manager / Team / Anyone with influence | Any time period |
Implementation and Delivery
| What | Involved | Potential Timeline Scope |
|---|---|---|
| The functionality has been coded and committed | Responsible Dev(s) | Depends on your dev(s) |
| Any and all pipelines are passing for the relevant code | Dev / Whoever owns the pipeline | Pipeline build time + resolution of issues, this can go on for a while |
| The code has been code reviewed | Highly Dependent | Anything from typing ’lgtm’ to eternity |
| Has passed automated testing | No-one, should be in the pipeline / Might be a dedicated team | Should be quick, although I’ve seen this drag for days |
| Has passed functional testing | Product Manager / Design / Stakeholders / Client / Client’s mums | You’re lucky if this ever happens |
| Has been integrated and has passed any integration testing | Ops / DevEx / Dev / Testing | This is usually just hoping the preprod deployment goes well |
| Has been deployed to production | Everyone in the company / Small subsection of the world depending on the client | Variable |
| Has not totally blown everything up resulting in a roll back | Everyone in the company / the whole of ITIL / possibly some media queries | This bit is usually pretty quick to work out |
Dry hot takes aside, the reality is that even as a solo worker doing all the work, it’s expected to have to bounce around a number of different people, teams, departments, processes and stakeholders when trying to get anything done. The larger and more regulated the environment, the more tasks there are going to be.
Furthermore, the responsibility matrix is in constant flux and the baggage train of previous issues never departs. As a consequence, it’s next to impossible to nail down who has to do what, especially when working amongst and within teams. Business and delivery architecture methodologies also tend towards deliberate obfuscation of individual capabilities leading to variable outcomes and repulsion of ownership over structural purity. There’s a huge difference between Frank fucking up the pipeline and the DevEx team having an extended ticket response time due to build issues, in reality they’re the exact same thing.
Organising vast quantities of people over complex and disparate deliverables is an immense challenge and not one I’m going to solve here. Statements of Work are better than most in-house project delivery methodologies, but they’re not easily scalable and they leave considerable gaps. The problem of people management remains; it is what it is.
The Best Definition of Done ¶
With this in mind, there is one definition of done I’ve experienced working near 100% of the time. It’s probably one that you might have experienced as well, though may not have given it due credit nor compared it to your professional day to day struggles with definitions of done.
Personal to do lists.
A personal to do list can be as simple as a shopping list and as complex as a passport application. It can be life changing or completely forgotten about. The importance of the list doesn’t matter. What does matter is that every task on the list:
- Has to be actioned by you - no one else is going to complete your personal to do lists for you
- Has consequences that are owned entirely by you
Note that this doesn’t mean that you have to personally perform every action on the list, some can be as simple as Ask lawyer to burn documents or Book plane flight to Kuala Lumpur. But the ownership for each of those actions belongs to you. The context of the list is for things that you have to do that you can mark as done. If your lawyer has already handed the documents to the police and British Airways declined your credit card then both of this tasks would be complete. You’ve both asked your lawyer to burn documents and attempted to book a flight, you have completed everything within your personal contextualised capability. You would still have overarching goals of escaping the country but your task list would be extended to include Buy some trail mix and Find an open shipping container. Once again, two tasks that are in your personal capability to pursue to their completion.
How This Fits into Modern Delivery ¶
It doesn’t, I doubt it ever will. However, it’s non-intrusive and low baggage to manage personally owned responsibilities outside of the professional sphere. For me this has historically been the perpetual-todo.md file that contains snippets of all the stuff I personally must get done. A simple, small and light solution that’s like having a propane gas can sitting on the desk whilst the rest of the company chucks wood into a muddy hole in the ground.