Uncharted Waters

Sep 14 2016   4:22PM GMT

What is Definition of Done?

Justin Rohrman Justin Rohrman Profile: Justin Rohrman

Tags:
Agile
Kanban
Scrum

I saw a retweet last week trying to make a statement about the definition of done. Jim made a good point, software is never really ‘done’. After new software has shipped to production, there might be bug fixes, or new additions to a feature or refactoring to hopefully improve that future somehow. Software is always in flux, so it might never be done. But, being technically right doesn’t really help people that are in the business of releasing software. We still have to deliver to customers.

Most of the problems I have had with definitions of done come from agile and kanban. Or rather, people using those ideas to justify not changing anything in how they work.

Every discussion I have had around the definition of done is a little bit confusing. At a high level, companies create a set of criteria like no critical bugs, some percentage of unit test coverage, and complete testing by a qa person (or tester if you prefer) as criteria to help figure out when they can release software. In practice, I generally see managers trying to treat software development like a football field that can continually be sliced up into halves.

Self defeating Process

I see this most often with Kanban boards. One company I worked for used a kanban board to visualize work in a very granular way. There were columns for analysis, planning, design, coding, review, ready for build, test, and ready for prod. Large tasks started at the left of the board and made a great migration to the right. Hopefully by the time a card made it from one side of the kanban board to the other, we were ready to go to production. That’s not how things really work though. One release might have a new page to capture a specific type of healthcare information, an update to a few different analytic reports, and a new permission to control access to that data.  Features that made it to the done column still had a couple of big remaining questions. Were any new problems introduced by the interaction of these new features together? How does the product work as a whole? Done for the programmers was not the same thing as done for the testers or the product people. And done for each of those people was miles away from what the company wanted done to mean ( a shippable increment ).

definition of done

For this group, the kanban board was just an excuse to keep doing what they already knew and have always done. Kanban, or at least how this group chose to use it, was exactly why it was impossible to figure out when they could ship.

The teams I’ve worked with that actually understood when they were done ditched software that mediates how people work together. I was working on a new part of a healthcare product several years ago. The team was a couple of developers, and me. We had a list of tasks and a board that was only had columns for todo, doing, and delivered. We worked together on one thing at a time in a branch just for that feature. Developers created production code, and I helped with test infrastructure. When there was something to look at in the UI, we all tested there. Once the three of us agreed that something was ready, we shipped. That was that.

Figuring out what done means is much easier if you take a small group of people, give them something to build and some time to do that. Get out of their hair and don’t add anything new to their queue till they surface and ask for more. When they do, it’s time to ship. Done is about shippable increments, not divisions on a kanban board or imagining never ending projects like lawn mowing.

 Comment on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: