Sometimes bed is not an option

 

"What passed for society was a loud, giddy whirl of thieves and pretentious hustlers, a dull sideshow full of quacks and clowns and philistines with gimp mentalities."

Hunter S Thompson - The rum diaries

How many times do you hear that to do the right thing is “Not an option” because of your client engagement.

I sometimes suspect this is much more driven by fear of the Consultants engagement than by the actual need – Sometimes being unpopular is the only option. Let me illustrate a fairly common scenario for you.

You have a piece of work where the client hasn’t actually agreed to the tech and visual design yet, this piece of work may be quite important and needs to be done very soon and as a team you might really want to get it out of the way? – The correct response is to NOT do it until we have a consensus on what the functionality should do – Hold off it – drop it – The product owner may be unhappy in the short term but then it saves you generating waste willingly. The problem is you don’t actually know what they want so are you building it because;

You are arrogant enough to think you know your product owners business better than they do?

Or because you are in the “More haste less speed” camp of “How wrong can it be?” (See above)

Now this happens all the time but let’s take this situation out of its comfortable context and put it somewhere where it really shows its flaws.

You take your car to a mechanic (You are now the Product Owner and the mechanic is the team) and the mechanic states that there is some serious damage to your engine. He will likely be able to get away with re doing the head (£x) but thinks it is wise to replace the engine (£3x)

If you have a good quality late model car maybe the engine replacement makes sense

If it’s an older car you are considering replacing in a year or two most likely the head

If it is an old banger you will probably tell him to not bother and scrap it.

How do you think you are going to feel when you decide to tell him to scrap it, call him up, and he says “We got bored waiting so we put in a new engine. You owe us £1800”

I reckon you are going to be a little less than pleased.

by Malcolm
June 8 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.

Mal

 

by Malcolm
March 13 2010

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.

 

by Malcolm
March 13 2010
Older Posts