On the definition of done

The productivity of a team is heavily dependent on establishing the “definition of done” for that team, something that has been debated for at least a decade. It could be questioned whether “done” is even achievable in today’s continuous improvement environment. I argue that however it is defined, it is important to understand the obstacles that organizations accidentally impose and, hence, stop “done” from being achieved. All of these — whether caused by cultural or process issues — can be overcome.

Let’s start with cross-functional teams. Unless the Scrum or Agile team is joined at the hip with IT operations, then the “definition of done” could differ. For instance, a Scrum team might focus on what they are doing in a vacuum, separate from what is going on in the world of customers: stories are completed, unit tests passed, code and security reviews covered, code ready to merge, and so forth. But all of this focuses on the developer, not on the delivery of business value to the outside world.

Imagine the frustration after shipping a new application, and on the first day it is in use, technical support receives a call from an important international customer asking for address line two to be 65 characters instead of 45.

Even worse is when a team believes they are shipping to production on Tuesday evening, when “out of nowhere” an IT operations professional rains on their parade by telling them they need to schedule a database change three weeks in advance.

Estimation

Developers may also be distracted by firefighting and bug fixing, which can derail the schedule and leads us to the next point: estimation. For instance, allocating 60 percent of a developer’s time to stories in an iteration (i.e., being productive) sounds reasonable, but things might happen that get in the way. Also, teams notoriously struggle with estimation; they may over- or under-allocate resources.

One of the key tenets of Agile is the breaking up of projects into pieces and delivering value early, which in itself is a good way to define both “done” and success. In a four-week release cycle, it’s important to have all the stories planned for week one to actually happen in that week and not bleed onto the next — and each subsequent week.

Interference

We all know that during a project, people understandably come up with valid, wonderful suggestions for improvements. This can affect not only delivery timeframes, but also cause scope creep. Going back to that four-week release example, we can recognize such a timeframe is long enough for many great ideas to come forth that could be added. However, it is better to stick with the discipline of finishing what was started. There are long-term cultural benefits to this, not least of which is keeping developers motivated and avoiding technical debt, both of which get in the way of “done.”

Here’s a typical scenario. The CEO comes up with a suggestion for additional features. They may sound fine in principle, but in practice, implementing the ideas within the current release may mean introducing elements that have not been estimated. This can force short-cuts, or create other dependencies that come back to haunt the next release. Change does not always equate to Agile. Of course, nothing is set in stone and, if a suggestion still delivers value and can be built solidly within the same timeframe, it probably makes sense to make that addition.

This brings us to a final and very important point: business value, a term that is used so much that eyes glaze over. But when business value is vague, then it is hard to define “done.”  If the success criteria defined by the business are not met, then “done” has not happened.

Answers

The answer to defining business value that drives a “done” state is to have a clear charter of what the business value is. Set clear goals, such as: “Four months after we ship this new version of this online video game, it will provide this much additional revenue.” Or, “Within two months, we expect new player acquisition generated by existing player invitations to increase by 25 percent.”

We should always be striving to build a “done product” that delivers the most value to the customer. In planning, the most valuable product, feature, or release should have the highest priority. Then, while the sprint is in progress, everyone on the team should frequently be asking themselves, “Is this the most important thing I should be doing right now? And if not, why not?”

A realistic amount of time needs to be budgeted for unforeseen technical debt. It is better to identify this potential obstacle early in the planning process. Doing that might involve sitting the product owner down with developer teams and considering whether the story is doable, is too big, what still needs to be completed, and so on (in other words, a backlog refining process). It’s important that this refinement occurs before any sprints begin.

In addition to “definition of done,” there is a case for “definition of urgent.” For instance, is that additional feature, or distraction from project scope to put out a fire, really an emergency? As a manager, I should ask myself, “If I do not interrupt this developer from what she is doing (which is the most important thing we should do), and have her work on the CEO’s suggested feature or production defect, will the world come to an end?” Or, “Will I lose this important customer?” Unplanned work is the biggest accidental cause of not achieving “done” for most teams. Being mindful of the impact of these type of changes will not only increase productivity but, just as important, engender developers’ trust that the business will not interrupt their work while they are deep in a project.

Similarly, when carrying out estimations, it is essential to include what is expected of Ops within the release timeframe, such as in our example of the database change. In addition to realistic estimation, it is a good idea to remove the personal element, too. Observe over time what the true velocity of a team is, rather than rely on an individual’s guesswork. Agile planning tools can help a lot here.

Yes, the Scrum team probably should be joined at the hip with IT Operations. This is what DevOps is about. By its very nature, DevOps provides the transparency, collaboration, and the fulfillment, in a concrete way, of the basic Agile goal of delivering value to the customer. DevOps does provide greater flexibility, but within a defined and well-documented framework of practices. So there are no surprises to anyone, internal or external to the team.

From a process perspective, improving each of the scenarios we’ve talked about here can be managed in a variety of tactical ways. However, it is the much-vaunted DevOps culture that takes “done” to another level. That a great company culture results in greater team productivity is well understood. While “done” is going to differ according to each project (and that may well be within the context of continuous improvement), the fundamental route to achieving that is identifying how to best avoid the roadblocks that people and processes can create.

Source : https://sdtimes.com