My Journey Towards Increasing Test Maturity

In my last post I wrote about winning the hearts and minds of those people affected by the operational and organisational change that’s needed to increase test maturity. I discussed the emotional and psychological impact of change and how, in my experience, the behaviour of those people impacted by the change but who don’t support it, tends to follow the model proposed by Kübler-Ross. This model was originally hypothesised to recognise the series of emotions experienced by terminally ill patients after being told of their prognosis but has more recently been adopted by the change management community.

In that post, I gave my thoughts on how important it is to allow these emotions and reactions to be processed by the change antagonists. This processing can’t be hurried along to align with the timescales of a project plan. Instead, individuals need recognition and to have the opportunity to air their grievances, put forth their views, recommendations and ideas. This is critical if you want to be successful in your bid to increase test maturity, and interviews and workshops are efficient tools to enable this.

I used to follow a very formal interview structure, instilled in me from my days as a Management Consultant at Price Waterhouse. However, over the years, I’ve learnt that I get far better results by being more Tao with the interviews and allowing them to flow more naturally and be more conversational. The interviewees open up, drop their guard and often find the (preferably) hour-long sessions extremely cathartic – which is the desired outcome. However, for that to be the case, it’s important to bond, create trust and for the interviewee to recognise that I’m truly listening to their views. They need to know I’m trying to help by making things better and I am independent.

No organisation is perfect and it’s usually pretty easy for me to identify several things that are causing the interviewee frustration and identify improvements that they support. Not only does this help me get them onside, but importantly it is the process by which I (we) identify the problems with the current model and start shaping the solution. By following this approach and interviewing as many peoples as possible, I get various perspectives of the underlying problems. Often the views are generally similar and are corroborative – which certainly makes it easier to identify the root causes. Sometimes there are differences of opinion though – and that makes things more challenging, so I need to stay impartial, recognise there are sometimes politics or personal agendas at play and rely on my experience and judgement. Then I can identify potential solutions.

It’s this problem solving that I really enjoy and what makes this type of work so much fun. I also enjoy and recognise the value of sharing ideas with my nFocus colleagues, benefit from their different experiences and debate the best thing to do. This is why I insist on having at least two consultants deliver this kind of engagement. A recent client pushed back on this approach and would only proceed with a single consultant. Against my better judgement we decided to proceed as they wished but within a day it was clear this was the wrong decision and I won’t do it again.

As important as it is to build support and to recognise that unless those impacted by the change have an opportunity to shape the solution, it is just as important to get the IT leadership on board too. As you might expect, it seems to hold true that Director level stakeholders have a greater focus on the big picture rather than the detail. This means they generally have a better view of the impact of the problems from lack of test maturity but are less aware of the causes of the problems. That’s not to say they don’t have an opinion of the root causes, or that their opinion is invalid, but I usually, and respectfully, treat it as a good place to start. When I’m engaged, I’m engaged by the Directors and so naturally, they will share their opinions and views. I therefore have to assume that it’s possible, that at some point in the future, I will need to contradict their opinion and I communicate that this might happen at the very start. I can only recall one instance when this level of independence was not well received. I therefore suggest that if you’re embarking on a journey to increase test maturity, you create a structure within which independence is protected.

The main reason I believe it’s important to get the leadership team on board is because although it would be preferable to get the complete support from all stakeholders and have everyone pulling in the same direction, it’s just not possible. Some people need to see the benefits of the change before they’ll believe it - and rightly so. As such, some things need to be mandated until they are widely and willingly adopted. The new methods and processes need to be pushed into being, individuals need to be constantly reminded and encouraged to adopt them. This needs the sponsorship and support of the senior people in the organisation. Sometimes, the senior organisation members can be the problem. I recall one of my clients I was taking on a journey to implement a more rigid change control process as part of their drive to increase quality and I failed to get the buy-in of one of the Business Unit IT Directors. Every time the Change Advisory Board (CAB) I set up rejected a Production change because of a lack of testing, he pushed for the change to go ahead anyway. It happened repeatedly and frequently – despite the majority of people from the PM, to production support, to the developers recognised the risk of these poor decisions. Months of effort to encourage more thorough testing was wasted.

In my next post, I’ll go through the specifics of increasing test maturity in a bit more detail.