Les Cunliffe - Fotolia
It's past time to revisit Agile's definition of 'done'
The definition of 'done' only covers what happens on the dev side. So, it's not very useful in a DevOps shop. Expert Theresa Neate explains what needs to change.
The definition of done has received much focus since its first mention in 2002.
The explicit completion/done criteria mentioned then were as follows:
- Are all aspects of the story done?
- Is the code as refactored as possible?
- Is there an acceptance test?
- Do all acceptance tests for this story pass?
- Have we explained to the customer (or quality assurance, etc.) how everything works?
XP and Scrum experts Jeff Sutherland, Ron Jeffries, Bill Wake and Ken Schwaber have said and written much to clarify the topic and influence the breaking down of our work into actionable chunks. As a quality assurance (QA) professional, my job-satisfaction and efficiency directly benefited from this evolution, and I read and watched and listened to their materials with fervor.
The definition of done was critical in my output as tester -- what was delivered was agreed-upon, deliverable, measurable, testable and all the other fine "-able" qualities. Consequently, I became an enthusiastic participant in all discussions where done was topical.
In those pre-DevOps times, none of us realized that in our definitions of done we routinely missed the point that pre-DevOps Agile missed: operations! We never included operability criteria in the definition of done!
A new definition of 'done'
As we know, with the advent of DevOps around 2007/2008, development and operations teams began to work more closely together on Agile infrastructure, automation of repeatable work and collaboration around on how to better serve each other. The goal is to deliver better quality and high-value systems more quickly.
The traditional Kanban wall remained, though, with "Done" still lurking as the last column.
As we still treated it, however, "done" was still only "development done." The other half of DevOps was still not explicitly included and defined in that.
I have alluded to ops' exclusion previously. I originally wanted to title this article "Done is no longer done," but I realized that that may unintentionally disrespect the hard work of those I've just mentioned.
However, I still want you to seriously consider the definition of done, as it now applies to DevOps, and what completion (of each increment) really looks like.
Items to now possibly include in the definition of done could be, but aren't limited to:
- Have all forms of feedback, including continuous integration, been satisfactory? Have changes even integrated back to trunk?
- Have we built in monitoring and alerting (telemetry)?
- Is infrastructure (relevant to this story) tested, too?
- Where relevant, have security measures been applied?
- Has it been successfully deployed? (To production?)
DevOps means 'delivery'
If we define these, it may help to reduce significant rework (aka waste) when the story or code hits trunk or production in the real world.
Just remember, even though the original definition of done was pre-DevOps, it was always about delivering value to customers. Bear in mind that value to the customer starts once delivered to production, not when ready to be delivered to production.
So, to each software development team, each developer, product owner, business analyst, tester, operations person and other key players: Have a look at your definition of done, and consider how the operations or operability aspect of DevOps should be applied to them.
