As more companies try to adopt ideas from Scrum, I notice that some have real trouble with the so-called “Definition of Done”. This idea seems sensible: we define general criteria for what constitutes calling a story “done”. In part, we do this to avoid ongoing arguments; in part, we do this to give teams a goal to reach for; in part, we do this because the book tells us to do it. I’ve heard about and witnessed many well-meaning people adopt this idea, then create all manner of chaos for themselves. I certainly don’t blame the technique for this lack of success, but something causes these people not to see the results that one expects from a disciplined approach to “done”. I offer a few observations and a recommendation.

I’ve watched many companies waste a lot of energy arguing about how to define “Done” when they first start to talk about it. I wouldn’t expect otherwise. A team, for example, refines its definition of “done” precisely in order to improve it: generally in order to move closer to the customer “at both ends”. By this, I mean both taking work requests more directly from customers and delivering the new features more directly to customers. I like the term “from Concept to Cash” to refer to this goal, which I learned from Mary and Tom Poppendieck’s book of a similar title. Pushing the team to move closer to “Concept to Cash” sounds perfectly reasonable, so why doesn’t everyone succeed wildly with it?

I’ve watched teams waste a lot of energy arguing that their definition of “done” makes them responsible for things outside their control, such as when a separate group tests the feature, safeguards the database design, or turns shipping features into a bureaucratic nightmare. Bear in mind that defining “done” this way should expose these kinds of problems—if it doesn’t, then you need to consider trying harder! Unfortunately, in many companies, it exposes problems that the team feels incapable of fixing, which demotivates them.1 If someone in authority supports the team in their efforts to live up to this aggressive definition of “done”, then this builds trust and improves the team’s performance. The team likely needs someone in authority, because policies will have to change to accommodate the team’s need to balance their new-found responsibilities with the authority they need to influence that work. This might mean giving the team priority access to a database administrator or experimenting with giving them an express lane for deploying new features. (This happens to take a step towards the famous “cross-functional team”, but I note this as a happy side-effect, rather than make it a goal in itself.) Without this kind of support, the team tends to wallow. We call this “learned helplessness”, because not only does the team not live up to the standard of “done”, but it learns that it can never live up to that standard, and before long, it stops trying. It has only one remaining option: negotiate with stakeholders to redefine “done” to make it “more realistic”, by which the team generally means “easier”. This almost certainly will not lead to the results you need and expect.

It gets worse.

Many companies that create an explicit “Definition of Done” do so in the context of adopting practices from Scrum. These practices often include estimating stories in story points in order to measure velocity. In over a decade of watching teams use story points—and I freely admit that I taught some of them to do it—I’ve noticed one recurring theme: they waste energy fighting to increase their velocity without disrupting the larger system around them. Once again, we do something that seems quite sensible: we measure velocity hoping that the team will improve, which we intend to detect by seeing their velocity increase over time. Unfortunately, many of the company’s systems block most of the significant potential improvement, which leaves the team with only dysfunctional tactics, such as padding story point estimates and fighting for “credit” for stories even though we agree that they don’t meet our definition of “done”. The team complains loudly that they ought to receive credit for a story, because they did their part. Once again, if they feel supported in their efforts to change the system around them, then we can hope for genuine improvement, but so often this does not happen, and the team learns more helplessness. Rather than improve, the team negotiates even harder with stakeholders to redefine “done” to make it “more realistic”.

What do we do?

Sometimes it suffices to reframe the situation. Don’t push a new definition of “done” on your team, but rather analyse with them how work requests go from their inbox to their outbox.2 The team will notice at least two kinds of issues: things within their system that delay work and things at the boundary of their system that delay work. Many teams learn that work moves slowly from their inbox to their outbox because, for example, their design ideas don’t work out, they make mistakes in writing code, or they assign work to a busy specialist and that work sits waiting for days to attention. You can help the team realise that they can learn new techniques to help them shorten these delays, including unit testing (even writing tests first), integrating their work together more frequently, or pooling their work into a single backlog and letting the next available people work on the most important task. You can help the team see that they can start experimenting with these techniques now, without the fear of impacting people outside the team. They have the authority to try, they can learn what to do, they have an idea what results to expect, and they believe those results will help improve the situation—such a team will feel motivated to try. This takes care of delays caused by things with the team’s own system, but what about delays caused by things (and people) at the boundary of the team’s system?

Many teams shy away from changing how they interact with the people and policies outside the team. Even if they start aggressively renegotiating those policies with those people, if they don’t feel well-supported by leaders or people in positions of authority, then they will lose their nerve and retreat—they’ll learn more helplessness. You need to find ways to support them, such as showing a willingness to stand with them as they work through difficult conversations with their peers3, staying calm as they struggle to integrate these new techniques with their old ways of working4, and watching for potential problems that they might not see coming5. If you do this, and the team succeeds in renegotiating how they accept work and how they deliver the finished product, then you’ll probably find that they’ve (magically!) adopted a more aggressive definition of “done” and that they work harder to meet that standard. It almost couldn’t happen any other way.

What changed? They felt responsible for the improvements. They felt supported in making it happened. I believe some people call this “owning it”. And it really works.

I don’t want to leave you thinking that I’ve criticised Scrum for recommending that teams adopt and enforce a strict definition of “done” as some bureaucratic element of a defined process. Far from it. I want to leave you thinking that I’ve described a way to help teams discover that they need to adopt and enforce a strict definition of “done”, feel responsible for making that happen, then run out and do it. I believe Scrum advocates for this kind of self-directed improvement. In fact, I believe Scrum puts this kind of self-directed improvement at the very heart of all work.

Try it!

Need Help?

If you’re not using techniques like these, then you’re missing out on most of the value of agile software development. Really! One CEO told me that learning techniques like these saved his company multiples of $100,000 in investment in software development. This is no joke. (If you don’t care about a few hundred thousand dollars either way, that’s fine, but it’s still a lot of money to me.)

Don’t waste your agile transition building the wrong product better. Learn more about Value-Driven Product Development training.

If you’re not ready for training, but you’d like me as your trusted adviser, get fractional consulting, coaching, and mentoring. It costs less than you’d think!

Reactions

https://geek-and-poke.com/geekandpoke/2017/4/28/a-definition-doesnt-blush

  1. I use a fantastic, simple model for understanding motivation, which I learned from Dale Emery. If you want a simple way to understand what causes people to feel motivated (or not), then read this.↩︎

  2. I help teams map their value streams, which sounds complicated, but I can teach you how to do it in a single 45-minute working session, and you don’t even have to fly me to your office to learn it.↩︎

  3. If you want to feel more comfortable in otherwise uncomfortable conversations, then I have a trio of books to recommend, and you can feel free to read any one of them to start. In no particular order: Crucial Conversations, Difficult Conversations and Just Listen.↩︎

  4. I’ve written about this before, albeit specifically about the dangers of “throwing training at the problem”. Read at least the first section of “You’re probably sabotaging your people’s training” to understand better what I mean. Whether your people go through formal training or not, if you panic while they struggle, then they will sense it, become timid, and fall back into their old ways.↩︎

  5. We also know this as “managing risk”, and you don’t have read a dry textbook to learn how to do it well. I loved reading Waltzing with Bears for the first time, and revisit it every few years. I find opportunities to teach a little of what I learned from this book in almost every engagement with almost every client—even when I train programmers in test-driven development.↩︎