How much business value is in your tech debit backlog??


"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 :-) 



May 13 2010

Lost in the Delta Quadrant!


"A word to the wise is infuriating." 

Hunter S Thompson 

OK, for the three of you that read this I have been absent for a while due to never ending project pressures and futile attempts to buy a house at the moment (All things I had put off till after Agile 2009)

This post is (unfortunately) a bit on the short side, and really just an outline of some of the things I have in mind to write about in the coming months, as much to jog my memory as to, hopefully, keep you all interested,

Agile and UAT - Where this can come unstuck, how we can prevent it from doing just that

Behavior Driven Development and how we started implementing it (Given my project breaks, And I don't want it to, When I have better tests and they run, Then I am a happy bunny)

Stubborn QA Departments What do you do when you have a QA department that refuses to give you testers until the release phase of your project?

Where is the risk? Why is it when we contract agile we seem to expect our clients to take all the risk?

A bit of a brain dump on what I'm thinking at the moment. H opefully its enough to whet your appetite. among those topics I will probably be discussing some of the training material we generated while researching our talk for Agile 2009. Maybe I'll drop a bit of insight to what we are proposing for Agile 2010?

Or maybe I won't let that cat out of the bag - You'll have to wait and see.



Agile 2009 - We entered the water and got out alive


"It was the Law of the Sea, they said. Civilization ends at the waterline. Beyond that, we all enter the food chain, and not always right at the top."

Hunter S Thompson - The Great Shark Hunt 

Agile 2009 - Simon Bennett and I presented this talk and I have to say, it went down quite well. It could have gone horribly wrong after all.

When we proposed this session we had quite a few comments (All visible in the above link I think) that "the hate" we were talking about didn’t exist. So when we presented and asked the room to vote, Green if you didn’t feel the hate red if you did ....

 We got a LOT of red.

Which is just as well! If it had been all green we would have been letting people out early J

So - We see the hate, other people see it, Why is there so little information on it? The point of our talk was to investigate the reasons for this hate, see if there were clear reasons for it and see what the overall drivers were. This I think we achieved and I'll post some of the feedback here soon. Suffice to say what we got was quite positive.

We did get a few people turn up for a different session however - I believe they were looking for practical tools to make their testers (Or themselves) more agile. They wanted more direction which we didn’t give them but then that wasn’t the point of the presentation. And as Alistair Cockburn would say (Did say!) "That is a Shu question with a Ri answer"

I think it is probably a good topic for a whole other workshop (That I might consider for next year but hey, you will have to wait till next year to see if I do it)

The main thing I think we got from it is the environment your team and company creates for your testers has as much, if not more, impact on their ability to be agile than they themselves do. Treating people in a certain way in my experience will cause them to react in that manner.

Take teenagers, Where a shop decrees that all teenagers are shoplifters and a security guard must follow them around the teenagers will (In my opinion justifiably) think "Well - If you are going to treat me like a criminal anyway regardless if I steal or not then I may as well steal - You will treat me the same anyway"

If you don’t treat them all as criminals you will still get the odd thief (But you would have got that anyway) now though you won’t be actively encouraging the rest of them to behave that way

Your testers are no different! If you treat them as the last line of defence (Identified by the sentence "Why didn’t testing find this bug") they will take on a gatekeeper mentality

If you treat them as the sole people responsible for quality (Identified by the sentence "I’m finished it just needs to be tested now") then they will sit at the end and wait for you to throw the code over to them.

I could go on but basically I am saying until the environment permits your testers to be agile they simply can’t be, and many places won’t change the environment until the tester is agile.

So which really does come first? The chicken or the egg?

At the risk of sounding all Kanban and eastern mysticism ;-) you need to change both together, if that proves impossible change the environment first! You may have some short term testing difficulties while your testers attempt to maintain their to their old methods in an environment that  is hostile to those behaviours but then again. You cant drive a car on water, and it’s quite difficult to be non agile in an environment that is hostile to those behaviours.

I'm not saying this will work for everyone but I suspect that, as in nature, if the environment is hostile to behaviours you want to minimise then those behaviours should die out by a process of natural selection.


An architect is like ... Polyfilla

A colleague insisted that everyone knows what an architect does.  More by nature of a comparison than from wanting to assume the label of "architect", I said "Well, what I do when I join a team is to try and fill whatever holes there are and then do what it takes to ensure delivery".  To which he replied "And that's it in a nutshell".

I find that quite an unsatisfying definition of an architect.  I've met people in the past who are clearly very good architects, in that they can come up with system designs which are incredibly simple and yet solve the business problems at hand in a very powerful way.  I think that someone like this does more than just fill in cracks.


[small print: Polyfilla is a registered trademark of Polycell]

November 27 2006
Newer Posts Older Posts