Here’s a number of scenarios which I’ve seen played out repeatedly in different settings.  They all have a common root – see if you can spot it:

So what’s the common link?  Right … quality!  Or more specifically, different views around levels of quality.

Now in agile terms, quality is best represented in the definition of done.  This definition should codify exactly what you mean when you say “this story is done”, or “how long until it is done?”.  Scrum itself doesn’t provide any specific guidance around the definition of done, but says that it’s important the team agree this.

It’s important to note that the definition of done should not be specific to a given story.  So my story about bank transfers may have a number of acceptance criteria around how to debit and credit various accounts, but even if my code works I might not be done because I haven’t had my peer review yet.

With that all said, here is what I see is going wrong in the above scenarios:

There are numerous good discussions and articles on the web about a definition of done (StackOverflow question, another question, an article, and another, and a HanselMinutes podcast), but I’d like to propose the idea that we should have some overall quality levels.  For instance, it doesn’t make sense to develop a strategic, long-term solution in the same way as a prototype.  So here’s what I propose as some overall quality levels:

• Spike – Written to prove one single technical question.  Should never be extended unless that technical question needs to be explored further.
• Prototype – Written as a quick-and-dirty demonstration of some functionality.  Can be used for on-going demonstrations, and so may need to be extended, but should never be deployed into production.
• Tactical – Written to fulfil a specific, limited business requirement.  Life expectancy should be in the order of 2-3 years, after which it ought to be decommissioned and replaced.
• Strategic – Written in response to on-going and continued business requirements.  Will be expected to evolve over time to meet changing business needs and emerging technologies.

And in terms of what I think these mean for a definition of done, here is my strawman (additional steps will most likely apply for a specific project, depending on the nature of the project):

So the next time you start a project, make up your own grid like this (or use this list, I don’t mind) and use it to have a detailed discussion with your product owner and scrum master.  It may surprise them to find that you are thinking about these issues, and their position on quality may well surprise you too!

"No sympathy for the devil; keep that in mind. Buy the ticket, take the ride...and if it occasionally gets a little heavier than what you had in mind, well...maybe chalk it off to forced conscious expansion"

 Hunter S. Thompson (Fear and Loathing in Las Vegas)

On our mailing list where we discuss all sorts of important development issues and organise pub trips, a mate of mine came up with an interesting problem to do with testing - It went a bit like this ..

“I've just been talking to someone who I has attempted agile without any QA or automated tests at all. Unsurprisingly they've seen an increase in regression issues and are now looking to retrofit done automated testing.”

As the resident tester it got me thinking. What is the cost of regression testing in an agile project ? - well the cost in my opinion is actually 0, zip, nadda, snake eyes !!

Right about now everyone who has faced the cost of regression testing is thinking I am smoking crack? or maybe hill billy drunk on the 4th of july? - I’m not and here is why.

Lets say you have a project you estimated at 30 points - whatever - you figure as you are going along you can do roughly 5 points a week including getting it manually QA’d in a test environment and showed with great fan fare to your product owner  - Happy days!! - you will be out of there cashing the check in 6 weeks... 

or will you.. 

What was your ACTUAL velocity??

Easy I hear you all say - 5 points!! 

The problem is, it wasn’t really - The 5 points a week was stuffed with tech debit, Now I’m not talking the stupid tech debit i’ve cited before where you just sweep all the hard stuff into the tech debit backlog to temporarily inflate your velocity (and we all know how thats going to end) I’m talking about serious tech debit that wont bite you for a month or so. The question is actually what did you DO for that 5 points? 

Write code that solved the problem?

Or write code that solved the problem with unit tests, integration tests, platform tests, automated UI tests that prove every build and deployment you haven’t broken anything??

In most cases its the former  - And here is where logically (though not financially I’m sorry to say) it doesn’t cost. What is actually happening is your velocity gets corrected. You weren’t doing 5 points, you were actually doing maybe 3 but incurring the tech debit of poorly tested code allowed the team to inflate their velocity to an unrealistic 5. The over all correction theoretically will be 4 weeks in this case - but anyone who has tried to go back and retrofit tests to poorly tested code will know its harder than writing them at the time. so in this case it will take longer. 

I guess if you can guarantee some other poor stooge will have to deal with it later you *could* give them crappily tested code to work with but once the smell has pervaded the building you wont be working back there any time soon and your rep wont be the greatest.

Some people will tell you that slow is good – but I’m here to tell you that fast is better. I’ve always believed this, in spite of the trouble it’s caused me. Being shot out of a cannon will always be better than being squeezed out of a tube. That is why God made fast motorcycles, Bubba…"

— Hunter S. Thompson (Kingdom of Fear: Loathsome Secrets of a Star-crossed Child in the Final Days of the American Century)

I haven't been at ThoughtWorks long but its been a happy couple of weeks - There is good conversations on a wide number of lists about all sorts of crazy stuff.

One that really grabbed my interest was a whole fiery chain about test automation and much opinion. Again someone raised the point of view that testers are like tigers (In the future survival stakes rather than the scary stakes) and will be extinct soon. This is something I have been yearning after for years - Imagine a world where the development practices employed by development teams are so quality driven we didn't need to test at all after they were done :-) 

I actually think many of the projects I have worked on were like this - It didn't make me redundant - In fact I have never been so busy! I spent a lot more of my time on defining acceptance criteria, Defining automation Scenarios, writing automation fixtures, Working with the devs on their unit tests, Generally finding ways to prevent the issues from occurring in the first place. In some ways the vision of the room full of testers busily finding fault with a release is redundant. But I think that has been going the way of the dodo fast with the uptake of agile.

However it seems that people are not sure what to do with us (QA) these days, Its as if the quality of a tester is ranked by the number of bugs they find. I would argue that if you are doing your job right the answer should be none!

On a big bang project with epic specs and reduced testing time I remember getting into trouble when I found bugs. "You keep raising issues like this we'll never go live!" my standard defence was always "I didn't put the bug there - I just found it" These days I don't believe that is sufficient. I think any bug I find is a failing of a process I am an integral part of. It is a failure of mine to get the right acceptance criteria, Or a failing of the communication channels between myself and the devs to ensure we are building the right thing, Or a failing in the automation scenarios we designed that allows some of the common edge cases to be passed incorrectly. These are just some examples but where you compare this to the old Us and Them (test and dev) mentality that used to exist I much prefer driving the quality of the process and application from the front where I can make an impact rather than from the end where all I can really do is find fault.

So does all this mean I never look at an application in a test environment anymore? - Not a bit of it - It does however mean I try to never spend hours going through a costly tedious boring and above all expensive regression test suite. I spend my time exploring the application and assessing the strange edges where it may fail - Its much more fun and a lot faster to identify critical issues. and I think I started this post with a quote that says fast is better.

Don't squeeze your application out of a tube 

"A man who procrastinates in his choosing will inevitably have his choice made for him by circumstance."

-Hunter S Thompson

So I was thinking the other day about tech debit - Where does it come from and how do we wind up with so much of it? 

so some of the scenarios that might ring (alarm?) bells are when you start finding extra details that need doing to get a piece of functionality to work and someone yells "Put it on the tech debit" or when all the Yack Shaving you are doing to get a story in is dumped on to the tech debit back log "For tracking"

Now I don't agree with this tactic and I'll tell you why - How much business functionality are you putting on a backlog that the product owner DOESNT PRIORITISE ??

Think about that for a bit while I try and disguise what I am doing enough to give you a concrete example.

Lets say you have a down stream system that is handling your orders for example - Now the guys building that system are behind you so you stub out the functionality and it looks good - What do you do with the integration piece? what does THAT user story look like?

"As a down stream system I want to communicate to a live up stream system so I can *Do some stuff*" 

OK This sounds like a tech debit story - The user doesn't really care about integration so we shouldn't bug them with it right?

Or hang on a second - What if we never did this ?? Then our down stream functionality is utterly useless - It is the proverbial lipstick on the chicken.

Suddenly it is starting to sound like our business user *Might* care about this story - But when you start saying "Upstream, Downstream, Integration etc ……… oh my god! I just bored myself!! Your product owner is unlikely to react much better. So what IS the business benefit of this piece of work.

I know! 

How about!

"As a business user I want my interface to book on to a live system so I DONT LOOK LIKE AN ASS WHEN I BOOK Y AND NOTHING HAPPENS !!!!!"

You may want to taylor the "so that" clause a little but the sentiment is there - The business value of the application *Actually doing something* is, I think, pretty clear. So I suggest the following - When you are next confronted with a bunch of tech debit stories that you are trying to shoe horn into a sprint around the eye candy your product owner is busily trying to prioritise (Ohh shiny!!) maybe see what the actual user story is? Start by thinking "if I never did this what would the end user experience? and would that experience result in no change to me or my p45 on my desk tomorrow?"&n

If the answer is the P45 better re couch it in terms your product owner understands 

Nobody likes to see another unemployed IT professional :-)