Hello everyone, this is my first blog on medium, I plan to write mostly on technical stuff, mainly systems (storage systems), that's what I have been doing since last 10 years and still think that I am just getting started.
Since long time, I wanted to start blogging, but was procrastinating, so finally thought, why only to start with technical stuff. So, this one is going to be a small but an important one.
So, recently and throughout my career, while developing features, working on software products, maintaining huge code bases, fixing customer issues, a common pattern, that I usually see in terms of work is(developers perspective mainly), that engineers always use the words I am done with my task, I think this is the most overloaded term, I have heard literally thousands of times(though I have not counted, but I am pretty sure of :)).
Let me explain, what do I mean by overloaded, see mainly the overloading applies to the done part here. The problem is, definition of done is different for different people. Like for some developers, done means, coding the task up, for some it means, coding and unit testing, for some, it means, coding, unit testing & integrating within the place where it was suppose to fit, for some it means, all this plus, QA testing too.
See, we all software engineers are already familiar with the conceptual understandings of software engineering practices at-least in general terms, so I would not like to talk about it, but the reason to mention here is, even after that, we still don't conclude on what does done with my task actually mean and mostly as always what I have seen is it turns out that everyone believes in their assumptions (definitions) of completeness of a task, which causes(leads) to disappointments, delays, frustrations (& all other adjectives). While controlled chaos is good, this is definitely not a controlled one :)
I am sure, this at some point in time would have happened to everyone while working within their teams. So, now after explaining(talking) about the problem, the question arises, yes we know this is an issue, now how to fix it?
I think, the fundamental requirement of the solution is "clarity", clarity according to me is everyone in the team, defining (agreeing), what done means and that too for every task. Having said this, team members, could still seem to have their own notion of agreements too, hence, defining what agreement is also important :)
Now fulfilling this requirement looks to be a mammoth task in itself, which would feel like such a big overhead. Agree, at the face value it does, but considering a fact that we are humans(with brains), I am pretty sure, we will find ways to optimize this as well, if we really want to fulfill this requirement.
Some pointers about clarity :
- It is easy to be clear if we have thorough understanding of the task(no/less unknowns)
- It is easy to be clear if we have broken down the big tasks into smaller ones to have more details (related to above one too)
- It is easy to be clear, if we can explain it simply (a well known comment :))
- It is easy to be clear, if we discuss(communicate), with others, about what our understanding is and what their's is and then try to converge(be consistent). I would like to call this eventual clarity, though eventuality is or should be a short-lived one, otherwise, its unclear :)
- Having a wiki or a document(with checklists) for each role, or set or patterns of tasks, to say when it is done.
- Roles of everybody in the team can be different and hence the expectations too. Being vocal and direct(transparent) would help. Many times it happens that management asks for something to be done and engineers commit on the face initially and deliver saying I am done, only later during integration or deployment its clear that its not quite done yet.
What process to follow then to be clear on definition of done?
I think it should be up to the teams how they want to do it, what works for them, obviously they will come to know eventually about it. But the intent about this should be there and once the intent is there, obviously we all can figure out what works best for ourselves, our teams, our organizations eventually.
Also, would really, like to know other peoples view on this.
Disclaimer : All these ideas(views) are mine and not any of this is of my employers. Aim is to improve and not offend anyone with these.
Top comments (0)