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

 

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.

 

Will we ever have the kahunies to publish or be damned!!

 

"I shared a vagrant optimism that some of us were making real progress, that we had taken an honest road, and that the best of us would inevitably make it over the top. At the same time, I shared a dark suspicion that the life we were leading was a lost cause, that we were all actors, kidding ourselves along on a senseless odyssey. It was the tension between these two poles - a restless idealism on one hand and a sense of impending doom on the other - that kept me going."

Hunter S Thompson - The rum diary

Publish or be damned is one of those scientific mantras you see sometimes, I believe it stems from needing to get your research out first before some other lab trumps you to it thus consigning you to an interesting foot note on the bibliography of a vegan honors students thesis.

Not a pleasant ending to a life's work.

In software development and testing especially it tends to be more publish and be damned. There is always a get out clause, a reason to not go live with something. In Agile there is this theory of producing potentially shippable code at the end of each sprint. What does that even mean?? I wouldn't be happy if I went to get my car from the mechanic and he told me I have potentially working brakes for example.

Now there are loads of places that will help define what "potentially shippable" is supposed to mean but I suspect that for most people it quickly translates into a BIG POTENTIALLY - and a very small shippable.

Is it shippable as soon as we fix that bug? or is it shippable as soon as we finish these five stories? Or more likely its shippable after an 8 week stabilization phase :-) so it was never potentially shippable at all.

That got me thinking, How would you change your work practices if your customer said to the team "You know what - I like this agile lark - Here are they keys to the live production environment and after every sprint review I want it in live within the hour!"

Can you imagine! A customer that put every sprints work directly into live!

I would probably react with total terror at first but then I started thinking about how the team and the process would change. I am willing to bet for a start that our velocity would half over night as various team members started thinking - "well I cant put that off, This is going live next week!". I would probably go on a one man uber crusade to automate every facet of the acceptance criteria before any of the code was written in case it came to me late and went live before I ever saw it!!

And then I thought "Why the hell am I not doing that now??"

I had a sudden image of a testers perfect world - Its a bad sprint, the developers are running late. Very little has made it through to be tested let alone marked as done and we have 5 stories in progress. Its 3 hours before sprint review and everything gets checked in all at once! - Normally that would be a nightmare scenario!!

[Scrum Master] "So what did we finish to demo?"

[Tester] "Did all the builds pass?"

[Scrum Master]  "Yes"

[Tester] "Demo the lot! Its done!"

 

Has the Agile wave finally broken??

"There was madness in any direction, at any hour. If not across the Bay, then up the Golden Gate or down 101 to Los Altos or La Honda... You could strike sparks anywhere. There was a fantastic universal sense that whatever we were doing was right, that we were winning...
And that, I think, was the handle — that sense of inevitable victory over the forces of Old and Evil. Not in any mean or military sense; we didn't need that. Our energy would simply PREVAIL. There was no point in fighting — on our side or theirs. We had all the momentum; we were riding the crest of a high and beautiful wave...
So now, less than five years later, you can go up on a steep hill in Las Vegas and look West, and with the right kind of eyes you can almost see the high-water mark — that place where the wave finally broke and rolled back"

Hunter S Thompson - Fear and loathing in Las Vegas

I think about this quote sometimes - I remember as an Agile noobie thinking Agile was the answer- All those heavy weight processes and endless pages of spec had finally given way to something elegant. As a graphic designer I was brought up on the customer never really knowing what they wanted, The trick was to give them a series of choices and gradually adapt to what they were after in the first place, Ask them up front and they never know. When I started working with software I found it insane that people believed that a company could define what they wanted up front but that was the way it was done?

I saw Agile as the thing that fixed this but I find myself coming back to the above quote and wondering if, Like the San Francisco hippies we have hit the point where it has been taken over by big business and rendered meaningless as more and more process is inserted,

Previously there were no qualifications in Agile - You did it because you knew it made sense - It was never easy for people to adapt but we fought hard to do it because we could see it made sense, Now I get an email a day about someone who will certify me as a Blah certified agile guru for the one time basement price of £1111111 or some similar clap trap.

The elegance in agile is its simplicity - Why would I pay to have someone tell me do the most important things first and your customer may change their mind?

I accept that is somewhat of an over simplification but I find it curious how little work has been done on the role of testing in agile - It has become so fundamentally different to what it was before but when we started out in agile there were lots of statements about how the developers are agile so we don't need you as much because they will write better code now!

If thats the case how come I'm so damn busy these days?

Testing has changed, More than development or Project management, And many of the scrum smells and agile failures can be identified early via testings response, Classic signs like trying to move testing to the following sprint. Or claims that Automation is too expensive to do for <n> project, It is up to us to educate people and also to adapt to the changes. If we don't then the hippies fate will be waiting for us

"We had all the momentum; we were riding the crest of a high and beautiful wave," But it hasn't broken yet, it is down to us to see that it doesn't 

August 12 2009
Newer Posts Older Posts