Tuesday, 7 October 2014

The Procrustean Bed of ISO29119


The old stories can teach us a great deal. Every once in a while I see the parallels between antiquity and the present, shown through the lens of one of these stories.

The tale of Procrustes (first introduced to me by the work of Nassim Nicholas Taleb, he writes with great skill and knowledge) and the introduction of the "ISO29119 standard" resonate with each other in my mind.

The Tale of Procrustes in a Nutshell......
"Procrustes kept a house by the side of the road where he offered hospitality to passing strangers, who were invited in for a pleasant meal and a night's rest in his very special bed. Procrustes described it as having the unique property that its length exactly matched whomsoever lay down upon it. What Procrustes didn't volunteer was the method by which this "one-size-fits-all" was achieved, namely as soon as the guest lay down Procrustes went to work upon him, stretching him on the rack if he was too short for the bed and chopping off his legs if he was too long."
(Source : mythweb.com)

So, lets adapt this for our ISO29119 situation:
"The "ISO29119 standard" purports to be the only internationally-recognized and agreed standards for software testing, which will provide your organization with a high-quality approach to testing that can be communicated throughout the world. Advocates describe it as having the unique property that it offers offers a set of standards which can be used in any software development life cycle. What the advocates don't volunteer is that your business problem will need to be stretched or trimmed to meet the new standard. So rather than testing solving your business problem, the focus will be to deliver to the standard."
Who will be Theseus for the Craft of Testing?

In the end, Theseus (as part of his tests) dealt with Procrustes using his own vicious device. However this will most likely not be the case here, I believe most thinking testers are advocating the opposite, continuing to champion the principles of Context Driven Testing. Rightly so, merely rubbishing standards is only one half of the argument. I sincerely hope our community of minds will be our Theseus but time will tell. The uptake of the "ISO29119 standard" is an unknown, concerns are probably in large organisations and government, where group (and double) think can be prevalent, these are the soft targets for peddlers of the cult of the same. 

However all over the development world we desperately and continuously strive to leap into Procrustean Beds. Taking shallow solace in "standards", which humans have been doing for a long, long time as a proxy for thought. Once you jump into a Procrustean Bed, you never emerge quite the same.......

Consider investigating..................
http://www.amazon.co.uk/The-Bed-Procrustes-Philosophical-Practical/dp/0241954096
http://www.ipetitions.com/petition/stop29119
http://www.professionaltestersmanifesto.org
http://www.softwaretestingstandard.org
http://www.ministryoftesting.com/2014/08/iso-29119-debate


Friday, 3 October 2014

N things I want from a Business Analyst....

  
Business Analysts. I give them a hard time. I really do. I love them really but I couldn't eat a whole one.

Is something I used to say.

I even went to a Business Analyst meetup once and asked them if they thought they should still exist in our "agile" world or are they being washed away by the tidal wave. Looks can really hurt, in fact they can be pretty pointy.

I wouldn't do that now though, I think I've grown up a bit. Like any great programmer or tester they can really add to a team. And, conversely, like a really poor programmer or tester they can really do some damage. It was unfair to single them out and very possibly bandwagon jumping of the worst kind.

In addition, I fell into a common trap. I was full of hot air when it came to what was bad about Business Analysts, but could not articulate what might make them great.

So here goes............
  • I want a vivid (preferably visual) description of the problem or benefit - lets face it, none of us are George Orwell. We can't describe in words with clarity and paucity, all the complex concepts present in our lives. However, we can deploy many techniques bring flat material to life. Elevator pitches, mind map, product boxes, models, personas and the like are your buddies.
  • I want you to shape a backlog, not provide a shopping list - hearing a backlog described as a shopping list leads me down a path of despair. A backlog is themed beastie, which needs to be shaped. Delivering the stories in a backlog will not implicitly solve the problem, no more than a lump of marble and a hammer/chisel constitutes a statue. Items in a backlog are raw materials. They need sculpting with care to achieve their goals.
  • I want you to work in thirds - for you lucky so and so's who are trying to figure out how on earth to cope in the agile tsunami which is enveloping the world, here's a rule of thumb for you. One third, current sprint, one third, next sprint, one third, the future. The remaining 1% is up to you.
  • I want you to be technically aware but not necessarily technically proficient - technical awareness is a beautiful thing, many testers are a good way down this path. Knowing the strengths and weaknesses of given technology helps you to realise business benefits, because you can appreciate the whole picture, the need, the constraints, the potential.
  • I want you to really, really try with para-functional requirements - This is in two parts, the response times/capacity/scalability the business needs for the real world, coupled with the constraints of the technology deployed. The answer will be somewhere in the middle. If there is anything I have learnt about performance testing especially, is there are few absolutes, para-functional requirements should reflect that subtlety.
  • I want you to be experts in change - in fact you guys should love change deeply, being able to extol its benefits and risks. Helping teams to help their stakeholders realise the value of change in their marketplace. Not snuffing it out to protect business goals which time has rendered of dubious value. 
  • I want you to distinguish between needed and desired - this burns me deeply. The old chestnut about a small percentage of the product actually being used (linky) is serious business. By not determining the difference between what is needed and what is desired, products are being happily helped to fall silently on swords forged by Business Analysts who struggle to articulate this critical difference.
  • I want you to recognise that stories/use cases/whatever are inventory - Imagine the backlogs as a factory, piles of stuff everywhere that our brains are trying to navigate around, winding a path through these piles of stuff trying to find what we need. This takes time and steals from flow, which we can't afford to lose. Before you add it, stop and consider for a moment, whether or not you need it right now.
  • I want you to challenge really technical people to justify value - "Well, we'll need a satellite server configured with Puppet to centralise our upgrade process." Huh? We will? What value does that give the business? Is what I want you to ask. Anything worth building, should be worth articulating as a value proposition.
  • I want you to take ownership of the product goddammit - There ARE decisions you can and should make. If you wish to survive the agile tsunami its time to embrace that change is king, and it means decisions. Big and small, narrow and wide, they are there to be made. By you. YOU.
  • I want you to continuously improve and I'll be watching - I would never want you to do 10 things to improve yourselves. 'N' things please, ever changing in focus to ensure you are delivering value in the contexts you find yourselves.

Basically I want you guys to be superhuman. I think you can be.

Some say being a Business Analyst is old hat. I say it is a gift. But only if you embrace it.