Why I Recruit Based Upon a Belief System

Recruitment is very time consuming and also very difficult in my experience. It’s a bit like buying a house, if the right house isn’t on the market when you’re looking, do you just “settle” for the next best thing or do you drop out of the market and come back later? Unfortunately, when we’re recruiting it’s usually because we need some NOW!

I’ve recruited hundreds of Testers and Test Managers over the past 25 years and have developed several tools to assist me along the way. Behind these tools is my inherent belief that we can teach someone technical and business skills, but we can’t teach them how to be. How to be is usually what matters most when being with other humans. During my later years (since I turned 45) I have applied a rule to my own job searching and that simple rule is that I have to “like” the people I am working with. So, the obvious question is “How do you work out if you like these people”? For me it’s quite simple – I listen to and watch how the people interviewing me respond to various questions and answers that I provide. It usually takes me less than 5 minutes to decide this, so the rest of the interview is about enjoying the chat or working out how to close it down.

When I’m the one doing the recruiting I use my “A to Z of Beliefs” to determine whether I want someone on my team. This list is not cast in stone and I usually share it with my management team so that we can massage it for the specific company or project. The way it works is that we look for specific qualities in the people we are interviewing and if they possess more that 80% of the qualities we believe are important then we offer them a job. Obviously some qualities are more important than others and therefore we usually prioritise the “Top 3” and make sure these three are always present.

You may question some of the beliefs listed below, but as I said these are my beliefs in relation to what is important in creating an effective software testing team. So, here is my current “A to Z of Beliefs” that I recruit to:
Bravery (in making decisions)
Daring (to be different)
Family & Friends
Healthy Lifestyle
Justice (for all)
Knowledge (the quest for learning)
Love (for one another)
New Ideas (open to)
Understanding (of others)
Xcellence (yes, I know that’s a slight cheat)
Youthful (in attitude, not necessarily years)

This approach has worked really well for me in both assessing prospective employees and employers. I’ll be very interested to hear your thoughts on this approach and list.

Dateline: March 12, 2013; Melbourne

Why Test Managers go on Stress Leave

Being passionate about my job has got me into more hot water than a cooked lobster. I have the burns to prove it. When I first started out on my quest to understand software testing (and ultimately Quality Management) I took the approach that I had always taken with the passions in my life – I embraced everything and everyone and fully immersed myself until I understood the very essence. The result, initially, was pretty messy. But I did come out the other side with greater perspective and harmony – although some of you who have worked closely with me may think I’m being over-optimistic here.

Software Testing is often a challenging/thankless task with many bloody battles fought and lost in the search for quality nirvana and the higher up the corporate ladder you go the bloodier the battles get.

The fact that I’m even writing in this tone is an issue. Why do I think in terms of a quality battle? Because – that’s the dance I’ve been part of for most of the past 30 years. There are many stakeholders in the running of a business and many of them have an opinion (however misguided) on how much money should be spent on testing the software that supports and/or drives their business.

I’ve taken up the Quality/Risk mantle on far too many occasions for my own good. “We must do more Testing” was a line I used far too often before the grey hairs began to appear exponentially. That was until the day Phil King (an exceptional human being and ManU supporter) and I shared a taxi in Sydney and he challenged me on my thinking around software testing and it’s place in the business change universe. It was 1996 and Phil was the CEO of Planpower (my employers at that time) and he wanted to understand how much our company should invest in what I was peddling at that time. So we talked about all the stuff CEO’s care about when running their businesses. We worked on our blueprint and when I left Planpower four years later it had grown (from a fledgling 5 personnel in 1995) to over 300 amazing consultants and was being primed for sale by the four owners. Today, Planpower is still an integral part of the UXC Consulting empire.

As I have said before, software does not exist within a vacuum, it is fully connected to everything that exists and therefore it must obey the same forces of nature as the rest of us. Time is finite. Money talks. Great people are in short supply. The are far too many meetings that discuss bug numbers instead of risks and consequences.

Passion is a very powerful emotion that can transcend culture and beliefs. Normally placid colleagues can suddenly become whirling dervishes if you criticise their ideas or question their design. “Who made you the gatekeeper of quality and where did you get the idea that Quality Management is an activity?”

All too often the Test Manager takes on the role of Quality Champion without ever understanding the organisations strategic views on what is considered good enough or high/medium/low risk (in terms of running the business). How can we (yes, I am a Test Manager) then take ownership of the quality of the software when we are often not engaged until the solution is already half cooked? How can we assume responsibility for the quality of an outcome when we had no involvement in the original business meetings held to discuss a problem and whether it needed fixing?

When I wrote (late last year) that the majority of Testers have no desire to become Test Managers it is this sort of behaviour that the Testers see and want no part of – it’s a no-win situation…. If you are a Test Manager then your job is to manage (and possibly strategise) the Testing – not take on all-comers when it is time to triage the latest bug hunting safari. You are there to represent the efforts of the Test Team, not to pass judgement on the impact of a specific bug remaining unfettered when the “Go Live” date arrives. This is the domain of the business representatives.

I have witnessed countless Test Managers go on stress leave due to the contortions they put themselves through in the name of the Quality God. They lost sight of the independent role that Testing should play and became embroiled in the cross-fire between the Business Owner(s) and Project Manager. Provide the ammunition, but don’t ever fire the gun!!

Stress is something we take on, not something that is given to us. Stress less and have fun, that’s why you’re doing it – because you enjoy it.

Epilogue: As an addendum to this week’s Blog, I want to dedicate this article to a very dear friend of mine who passed away this week after losing a four month fight against cancer. Pat, you will be missed by all who came into your universe and I look forward to seeing you one day when my journey on this planet is over.

Dateline: January 9 2013, Doncaster, Australia

Test Managers Toolkit: The Model Office (Part 1)

I am constantly amazed at how many Test Managers have never used my favourite (and to date, most effective) Testing technique – the Model Office. In fact, I’m even more amazed at how many Test Managers have never even heard of a Model Office. Where have you all been the last 20 years?? A search on Google supports my assertion – that it is an under-utilised technique. Only one of (what I consider to be) our Testing thought-leaders (Paul Gerrard) mentions it on his website, all other Google references are from non-Testing practitioners, generally Program/Project Managers or Architects.

So, what is a Model Office? Simply put, it’s is a (scaled) replica of an entire business (or sometimes a clearly defined sub-set of functions or departments within a business). It is a model (generally) defined in both business and technology terms to depict how an organisation works. Typically, at the centre of this model is a level 3 process/workflow map (or maps) depicting how stuff happens, who does it (and when) and what outcomes occur as a result of stuff being done. It’s major benefit is that everyone gets to see what the organisation looks like today and how it will look in the future, once the changes you are making have been implemented. Some folks describe a Model Office as a simulator, but I prefer to think of it as scaled-model where real-world scenarios can be tried and tested – even before you start to build the solution.

My most successful applications of a Model Office have been on significant organisational change type projects where we have built a physical manifestation of the current state and overlaid it with the proposed solution. We do this by expressing the current organisation as level 3 process maps using sticky notes and then covering these with a see-through material and then placing more sticky notes on this cover where the changes occur. This provides a before and after series of images that can easily be modified by simply replacing the offending sticky notes. Once we have these pictures approved (by the various stakeholders) we commit them to whatever software we are using to build the long-term process maps.

Examples of Model Offices we’ve created include:

  • A Branch of a Retail Bank – so realistic that customers tried to come in and perform their daily transactions (we set it up in the foyer of the bank’s Head Office for maximum visibility)
  • A complete online Supermarket that encompassed everything from product-line buyers, a mini warehouse, real delivery trucks and “friendly” customers who ordered and received free produce for 3 months
  • A Supply Chain business that was being transformed via a complete technology overhaul
  • A Business Bank that was undergoing a major merger
  • A government department implementing a new Training and Development package

Four of these program’s of work were delivered successfully, while the fifth was canned based upon information gathered using the Model Office during the solution design phase.

I have been using this technique for over 10 years and the biggest challenge is generally gaining buy-in from the technology stakeholders – business stakeholders are always supportive of a business-centric Test Strategy.

So, why haven’t you set up (or considered setting up) a Model Office in your organisation? The most common reasons I come across are:

  • Lack of strategic knowledge or technical understanding of the Model Office technique (you won’t find it mentioned in the ISTQB syllabus or glossary)
  • Lack of insight/foresight as to the short and long term benefits
  • Lack of ability to convince potential sponsors to fund it
  • Lack of a suitable location or space – some Model Offices require significant physical space

When we were Testing the Supply Chain business we were allocated a (spare) warehouse with an office that overlooked the main storage area, so that we could monitor and record all the warehouse-based functions in real-time.

Unfortunately, not every organisation is willing to provide this level of support; however, this is not a show-stopper and your powers of creativity just need to be exercised a little more. As I said a couple of weeks ago, I’m currently on the road in Europe and therefore don’t have access to my entire Test Managers toolkit and therefore I can’t attach a multitude of photos of some of the Model Offices I’ve designed and implemented, but I will rectify this once I am back in Australia.