I was chatting with a friend the other day about getting things done and driving them to completion, when she raised a common problem I have seen with teams:
“ Our team either seems to overcomplicate things and never finish them, or we finish something quick and dirty and nobody else is happy with it and it has to be done again.”
Every single team I have seen that has the problem of either over complicating features so they never finish, or finishing fast but missing core or critical functionality has had the same core problem: lack of a common definition of “done”
There is an Indian parable where group of blind men come across an elephant, and when they each touch a part of the elephant, they each think they have encountered something different.
Like the parable of the blind men, our individual interpretation of any requirements are based on our own unique knowledge and experiences, and how we see the world. When a group of people come together to build something, if they begin working without having a clear and common vision of what it will look like to be finished, the end results can vary dramatically.
Like many problems in modern software development, this is fundamentally a communication problem. When a team gets together to review and discuss requirements, even if they are all co-located they are still going each have a different interpretation of the requirements based on their individual knowledge and experience - and this is even more true for cross-functional teams. There is a simple solution for this problem: when the team is discussing the requirements, they also need to discuss what “done” looks like for the finished feature or functionality.
I have encountered a surprising number of teams that not only do not discuss what “done” means for a given feature, but also don’t have any core shared definition of done for the software they create.
Most successful teams have common definition of “done” that they use for all features and functionality they work on, and then will discuss whether there is anything additional they should include for a specific feature or functionality on which they are working.
In Agile software development, we embrace the idea “working software is the primary measure of progress.” If this is true, then fundamentally we are not “done” with a feature or functionality unless it is “working software”. For individual teams or companies, this may or may not mean that the software is deployed to and running in a production environment, but at a minimum it should generally mean that it is deployed to and functioning correctly in a production-like environment. From this we can also assume that a core part of a definition of “done” would generally include being code complete, and having been tested.
With any new team, I will have them discuss what “working software” means to the team and to the company. I start by having the team think about a piece of software running in production, and imagine the things they hope would have occurred prior to that software running in production. The team then names as many things as they can think of, and we capture these in an immediately visible manner. We then go through each one of things and try to identify whether it is something that always needs to occur before software is released, or just sometimes. If it is always, these start to build the foundation of our definition of done; if they are sometimes, then these can help build a list of things that we might add to the definition of done in certain circumstances or for certain types of features or functionality. Some of the types of items that might be part of a common definition of done are: code complete, code commented, diagrams updated, peer reviewed, unit tested, functionally tested, integration tested, automated tests created/updated, regression tested, user acceptance tested, documentation updated, deployed.
A common definition of done is a great starting point, but it only helps to ensure that something is getting done, but not necessarily that everyone understands and agrees on what is being built and how it should function. When a team starts working on any individual feature or functionality, the team then needs to discuss what that feature or functionality would look like running in production.
In a future post I will discuss the problems of misinterpretation of different requirements, and how teams can come to a common understanding of a feature or functionality prior to beginning work on it, so that they can get to a common point of “done” for that particular item.
