Done means DONE!

One of the great fallacies of the software industry since time began has been that code complete is equivalent to the product being ready to ship.  Nothing could be further from the truth and I have 30 years of scar tissue related to this misconception.

The Agile framework and the Agile Manifesto behind it has four very simple business process declarations on how to build pertinent, valuable and timely software and 12 equally obvious operational principles on how to operate so as to deliver quality software that meets the business need.

These declarations are simple and obvious.   Whenever I have presented or discussed them, much head nodding and agreement ensues.  They are so simplistic "Our highest priority is to satisfy the customer...." that they are almost impossible to argue against.

The dirty secret behind these simple statements is a series of ceremonies and artifacts which regulate, measure and improve both the software product under development as well as the development process around it.    One of  if not the most important artifact in agile is Definition of Done.

Definition of Done ties directly to the principle "Develop Working Software frequently" and is articulated in Scrum/Sprint terms that when a sprint is done and a story is accepted as Done, both the story and the product around it  is ready to deliver to customers for use. 

And so starts the slippery slide - arguments I have heard 100 times "the new code is complete and tested, we will deal with system and stress test of the product later".    "We always write test automation one sprint behind the code". "Tech. Pubs is busy, they will document it later - for now we can get by with a readme".  "we really aren't delivering for a few sprints so we will catch up with defects in the next couple sprints",.  And of course my absolute favorite " we only changed one small area of code, we don't need to regression test the entire product".

Usually the argument is followed by a chorus of responses which boil down to one thing - there is a lot of detail work after Code Complete before a feature within a product is truly shippable.  There is even more work to make sure both the new feature as well as the product around it is shippable.

And here is where Definition of Done comes in and forces a game changing mentality.  When a team sits down and maps out all the work needed after the code of a feature is complete, or for that matter a defect or an enhancement; it a formidable list.  Definitions of Done checklists can cover pages and span multiple organizational bounds.  Often an item on a checklist  "User training updated" or "Penetration and security scan complete" cross organizational boundaries and require complex and high latency handoffs.  "Push to production" can be a 2 week process in many companies.

Yes - you can cheat and play process games with hardening sprints, system test sprints and the like, but ultimately Definition of Done forces a mindset change in both teams as well as the organizations around them.  My viewpoint is that when a team accepts DoD as a true measure and gets past the impossibility of meeting all those checkboxes on each and every story in each and every sprint they move from talking agile to being agile.

Definition of Done forces confrontation with all the pains of technical debt and organizational impediments.   It forces the team to devise ways to either reduce or remove both technical debt as well as any other impediments to velocity.  Confronting these areas leads a team from talking agile to operating with agility. 

A team must move from the blame game and "not my problem" to being accountable for the success of a feature at customers.  Operating with agility means accepting and welcoming responsibility and accountability as part of everyone's role.  Operating to the spirit and meaning of Definition of Done helps to bring that ownership of customer success to teams.  Shipping a feature that isn't complete, has defects, hasn't been fully tested or documented rarely satisfies customers.

Discussing DoD can be uncomfortable, especially in light of one or two week sprints where there is no time for outmoded manual operations, workflows and checklists.  Addressing the challenges behind Done means DONE forces thinking and inventing new ways to do old processes as well as challenging the status quo.   When "we have always done it this way" meets the concept that each accepted story in a sprint is potentially shippable *now* an organization is forced to reinvent engineering workflows in a lean and significantly more efficient fashion. 

I can think back to release checklists with 30-40 items and a 12-15 day timeline being confronted by an agile team trying to "ship" in 2 week sprints.    I can think of products with manual functional test cycles measured in months where no automation existed.

 In both examples it took hard work, much of it around communications and collaboration, and only some of it technical in scope to address decades old embedded processes and mindsets.    To get to a point where we could reengineer the process or write test automation, the first step was to get past entrenched mindsets and move from impossible to possible.  Addressing years of status quo is not easy, nor are the conversations comfortable, but the effort is necessary if an organization is going to truly commit to agility.

Definition of Done is a simple concept, one that makes complete sense at the agile product and team level.  Making it reality in a complex and entrenched organization is hard work, but work that must be done for both the team as well as the company around it, but most importantly to meet those 4 declarations and 12 principles of the Agile Manifesto; all focused at creating product value and satisfying customers.