Bad Workmen II
In my last blog, I may have inadvertently, and possibly inadvisably, let the cat out of the bag. My intended focus was on the importance of getting People, Process, and Tools in the right order (conveniently already done here for you – you can thank me later!) based on how many times I have seen tools-led implementations being cited as the reason for the failure.
I think I’d have gotten away with it if, as I have often long-suspected, no one ever reads my blogs. However, a colleague kindly re-shared it and those illusions in my mind of a quiet life quickly evaporated. I’m now slightly panicked I’ve tarnished my own reputation as a bad workman! I’m blaming it on the utilitarian giant screwdriver…
Moving on from potentially dropping myself in it a follow-on thought struck me as a consequence of a conversation on metrics. The conversation itself was fairly simple, in that it was an observation that someone had, through hard work and determination, improved the reporting metrics to the overall benefit of test within a project. Something many of us could learn from, and it is rooted in my intended subject from my previous blog about using the right tool for the job to get the best results!
It was this which sparked this follow-up blog, as usually I find a new topic each time (through a painful creative process). Whereas the first part was about not picking the tool until you sort out the process (or plan), which is in turn driven by the culture or people – this focus this time is on culture.
I sat in a conference call recently and it was fascinating to listen to what was actually being said at both a tactical and a strategic level. Tactically there were no issues of note in the meeting, and I think most participants were present in a tactical mindset. However, I recall a lesson from a course in Les Fontaines, our campus university near Paris, about being able to take a step back, and to absorb the view from a balcony perspective, looking down upon all the tactical activities.
In doing so I heard simple statements that contradict all of the lessons the move to agile methodologies and DevOps are supposed to have taught us. For sometimes we can’t see what’s under our noses, and we may be unwittingly reverting back to inefficient practices because they feel familiar and easy. To an extent I guess there is a simple truth to that, in there is a logic to waterfall development and, with the wind in our sails on smooth waters, it works.
I am not, however, condoning a return to waterfall methods. Because I would hazard a guess that many of us have been on projects like that which seemed to very simple at the outset but as various different turds hit various different fans, we all learnt the hard way that there is a better way. In the same way that I’ve just about worked out that it’s easier to put a nail in with a hammer and not the large screwdriver of legend. And how I admire true engineers who measure a hundred times and cut once, their processes learned in the way of error-prevention.
This simple answer is one of metrics: capturing a set of numbers, measures of our performance, which we can monitor and spot when things go out of tolerance and we may have an issue. Sogeti’s CognitiveQA solution is an advanced solution to this which builds on our experience of capturing metrics and creating dashboards – and creating the feedback loops so familiar within agile methodologies that allow rapid change. We’ve cut our teeth over many years doing just that, and at scale too.
But there is also one other lesson I feel is important, and it’s a cultural point. We need to learn to listen to what’s going on, and to subject it to critical thinking and scrutiny. If, for example, a sprint has tickets or tasks added to it once in progress, then we’re probably breaking a key process somewhere. And it can even happen often enough that we become blind to it. In our minds we remain “agile” but we fail to notice we’re bypassing the processes and we become simply paying lip service to the methodology. We become culturally lazy and ineffective.
And just as we have CognitiveQA to help with metrics, Sogeti’s expertise in Transformation can help keep teams on the right track to make the transformational change effective and permanent.
About Alistair Gerrard
When my childhood dream to become a commercial airline pilot came crashing down, I fell back upon my long-standing interest in computers, which started with learning basic on a Commodore Vic 20. This journey ultimately led to reading Computing and Information Technology at university, via Amstrad 1512 (PC DD) and Commodore Amiga ownership, and a holiday job as front-line PC Support for both the Associated Examining Board and SMART Store Windsor (part of Andersen Consulting).
More on Alistair Gerrard.