Skip to main content

Posts

Showing posts from 2014

Hard Skills > Culture Fit

So here's a little bit of hiring people logic for you. I've expressed it as pseudo-code all those technical people who insist on exclusive hard skill hiring, despite the long term pain of it all.


private Handler handler;
public Employee effectiveEmployee;
public int numberofEffectiveEmployees = n; 
if (hard skills > culture fit) {
            handler = new Handler;
            numberofEffectiveEmployees -= 0.5;
        } else {
            effectiveEmployee = new Employee;
            numberofEffectiveEmployees++;
        }

What?

My code probably doesn't explain itself (and probably won't compile), so here goes.

So, a handler is the person (who may well have done the hiring if there is any justice) who tidies up the mess of a hire that doesn't fit with the culture that exists at your organisation. Not the public facing culture either, the actual one. Effectively for every poor cultural fit hired, you reduce the effectiveness of your remaining employees by a bit. Probably a f…

Train the Trainer - Course Retrospective

What's up with that then?

So, I've been charged with becoming a trainer within my organisation.

Just to set expectations here, I know a tiny amount about how to furnish humans with new knowledge, skills and attitudes. Make no mistake, if this field is an ocean, I am a puddle by comparison. I have dabbled with coaching, but much learning from me will probably have been via proximity and osmosis.

Personally, if I'm going to do something, I want to use my whole arse to do so, not just half of it. I want a set of models to apply in context and (more importantly) a strong paradigm, so when I discuss, create and iterate on training material and courses, I have a starting position to challenge/be challenged on. So, I attended the Train the Trainer course to compliment my own buccaneering learning tendencies.

What did you learn that t'internet didn't know for free?

The internet probably knows some of this stuff but here is a bunch of stuff I have learnt over the last few days:

I…

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 hi…

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. W…

The 'Just Testing Left' Fallacy

I am mindful that many of my blogs are descending into mini tirades against the various fallacies and general abuse of the lexicon of software development.

Humour me, for one last time (thats not true by the way).

In meetings, at the Scrum of Scrums, in conversation, I keep hearing it.
"There's just testing left to do"And then I read this:

http://bigstory.ap.org/article/social-security-spent-300m-it-boondoggle

An all too familiar software development tale of woe.



I thought; 'I bet everyone on that project is saying it too.' Next to Water Coolers, Coffee Machines, at the Vending Machine, in meetings and corridors.

At first, it gnawed at me a little.

Then a lot.

Then more than that.

I have three big problems with it:
It's just not true. There is not 'just testing left.' What about understanding, misunderstanding, clarifying, fixing, discussing, showing, telling, checking, configuring, analysing, deploying, redeploying, building, rebuilding and all the small cyc…

The name of the thing is not the thing

I often ponder the question 'should we care about what we call things in the software development world?' One could argue that as long as everyone has a common understanding, then it shouldn't matter right? I rarely see a common understanding (which is good and bad in context), suggesting that we do care enough to name things but sometimes not enough to care about the amount of precision those names have.
Gerald Weinberg quotes in the excellent 'Secrets of Consulting' that 'the name of the thing is not the thing.' As a tester (and critical thinker) this represents a useful message to us. The name given to a thing is not the thing in itself, its a name and we shouldn't be fooled by it. This is a useful device, as I believe the name is an important gateway, to both understanding and misunderstanding, and names take root and spread.....
Testing is not Quality Assurance
There are probably a great many blogs about this, but I hear/see this every day, so it n…

Software Testing World Cup - An Experience Report

After much anticipation, myself and three of my colleagues embarked on the Software Testing World Cup journey in the European Preliminary. We had prepared, strategised, booked rooms/monitors, bought supplies and all the other (actually quite long list) of tasks to get ready for the big day. Armed with the knowledge that I would be jetting off on holiday the following day, we entered the (metaphorical) arena to give it our all and hopefully have a little fun. Here are my thoughts about 3 interesting (exhausting) hours.
When I reflect.....
Over my testing career, I have learnt to really value time to reflect. Study a problem, sleep on it, speak to peers for advice, come up with an approach. The time just doesn't really exist (in the amount that I needed it) during the competition, which made me uncomfortable. A little discomfort can teach you a great deal, and indeed amplified the more instinctive part of my testing brain.Following on with the above, I'm happy to say I kept my sh…

The Fallacy of the Single Point

Ever heard of the 'Fallacy of the Single Cause?'
It refers to the rarity of single causes resulting in particular effects, it turns out the world is more complex than that. Many different inputs are required to created the blended and various outputs we see in the world around us. Some may contribute more than others and at different times, but as a rule of thumb for life (and testing), pinning your hopes on one cause, is likely to leave you disappointed.
We communicate in stories, but what's the point?
This fallacy has been refined to apply to the penchant for storytelling that is intrinsic to how we communicate. The question is this. How often do you listen to a story and you take away a singular outcome or learning? Thing is, the end of a narrative is only part of that journey, a great many stories express many subtleties as they progress, especially that rich vein of intrigue and oblique learning, reality.
In my eyes, this ability to tell a story has always been critica…

Reviewed - The Testers Pocketbook by Paul Gerrard

I had heard a great deal about this little book. Some who had read it appreciated its premise, some were in fairly fundamental disagreement. If a text generates polar opposites of agreement, then that immediately piqued my interest! So lets begin with that premise:
"A Test Axiom is something we believe to be self evident and we cannot imagine an exception to it"
I feel this is indeed a risky premise for an approach to testing, could be easily misinterpreted as a set of iron laws to be followed, which will magically output an appropriate approach to testing. With this in mind I set about the enjoyable challenge of the dissection of these axioms. Lets take for example:
"Testing requires a known, controlled environment"
There are absolutely benefits to this statement, but also damaging flipsides to your test approach. A known, controlled environment is limited in variance, therefore only able to expose bugs of a certain nature. In addition, tests run in an environment suc…

Lets celebrate! Anyone still out there.....?

Pyrrhic victory. I was reminded of this term a few days ago. 
It is when winning decimates *almost* everything, so winning is basically not worth the cost exacted to achieve it. I believe I have seen this effect on teams during and after very long development projects, the dreaded 'death march.' The projects aims might be valuable and completely worthwhile, but at what cost?
Sometimes, the stresses and strains of such endeavours decimate the team tasked with delivery. Relationships are strained or break, enthusiasm is replaced with cynicism, previously open minds are closed to protect for harm and monotony. Previously conquered silo's re-embed themselves.


Consider those precious 'T-Shaped' people, who are consistently pushed to their limits and burn out, or retreat back into their shells. As a complement to the determined specialist, these guys (and encouraging more of them to flourish) are the key to unlocking effective delivery. Their flexibility and enthusiasm …

Reviewed - The Effective Executive by Peter Drucker

I'm always slightly sceptical of the phrase 'timeless' when it comes to management literature, given the infinite variance of people and the situations we find ourselves in. The Effective Executive was described as exactly that by the excellent Manager Tools podcast and I found myself in front of a well know online store ordering a copy.
Overall, it struck me immediately the sparseness and matter of fact nature of the language used by Drucker, although that sparseness expresses the practical nature of the guidance given, starting with managing one's time.
The reality of time is that it is the one thing (on an individual level at least) that you cannot gain more of. Drucker's message is quite bleak at first but the reality of it I will not contest, most executives I know will admit to rarely being able to focus on the critical issues as they are drawn in varied directions to tend to the issues of today, where they may be better served focusing on tomorrow. Indeed t…

The bigger the rock, the smaller the pieces need to be

You know what I really, really value in a fellow professional in the information technology delivery world? That special, magical ability to decompose a large (and potentially complex problem) into small, simple subtasks.
A child can do this right? This is 'Being a Human Being 101.' So why is it a behaviour that eludes a large percentage of those in the information technology industry. This is a trait of people who I like to call 'people who get things done.' Not through heroism or great feats against monolithic bureaucracies, but a simple application of critical thought.
Is there a problem here?
People like the idea of building big stuff, stuff to "get hold of", its very grand to say we're building an "enterprise level" application. In that vein, I hear "well, this a step change to the product" or "there is no value in splitting up the project into smaller deliverables" on a regular basis. The justifications of the desperate, d…

If you don't believe it, why should anyone else?

The question of what skills do testers need intrigues me. 
This always occurs to me when engaged in the search for 'good' people to hire. We (as in the technical sphere) tend to hire predominantly on 'skills.' Very rarely do we look for behaviours, even rarer we consider beliefs.
After some consideration (and no little practical finger-burning), starting with skills is often a false position, starting with beliefs can be much more powerful.
The following question always strikes me, when I consider this context. How many testers you know can give you explanation of what they believe the essence of testing is? I know relatively few. In fact, I often received the look of a startled rabbit when I lead with this question. You do it every day, but you can't tell me what you believe it is?
To not be compelling with what you believe testing to be puts you and your chosen vocation at a significant disadvantage when interacting with those who are sceptical about its value. To be…

I KNEW IT!

I like to think I have a nose for a problem. Not necessarily a bug, but just when something doesn't seem right. The extent to which I follow up on these gut instincts varies depending on how strongly the nagging feeling remains. 
These 'hunches' last for days, weeks or even months, often I struggle to find the vocabulary to express what I am thinking or feeling.
For example, on a past project, the system under test needed to store certain characteristics about a customer (derived from an external service) on their first interaction with the system.
'First interactions' could take a number of different paths. Something about this nagged at me after the system went into live service. I looked superficially several times at the evidence (including with the product stakeholders) and all SEEMED to be well, yet something still chipped away at my consciousness. By now I felt a little crazy, but time and change then proceeded to distract me.
Then the big day came. The informat…

Shallow Statement Syndrome

'Surely its just a case of doing X and creating a Y, then we'll obviously get to Z. I've done this lots of times before.'This is an example of Shallow Statement Syndrome, one I hear often from those involved in software development. It comes loaded with preconception and assumption and is generally delivered with great belief by the speaker. As a tester it sets my common sense tingling.
Lets decompose the highlights:
'Surely' - I have already decided, I'm already sure, my mind is closed to options.
'Just' - I don't believe this to be complex, I am implying simplicity and ease.
'Obviously' - The outcome is obvious to me, I don't need to encourage others to envisage the outcome.
'Before' - The issue at hand stirs nostalgia, I have done this in my past, therefore it can be done again in a similar way, possibly by others. 
The problem with Shallow Statement Syndrome is the chasm beneath them when you scratch the surface. Beneath each s…