I have, on a couple of occasions, attended a presentation for a product suite which did everything. It was all-singing and all-dancing, and it meant you could have an all-encompassing solution from a single supplier. And, I will confess, it was mightily impressive. It had a certain appeal.
Of course, it also had an eye-watering price tag and involved a company putting all its eggs in one basket by signing up to a single supplier. And despite the real-World demonstration and the client citation used to champion the benefits, I’ve yet to encounter an instance of such an all-encompassing, all-singing and all-dancing suite of products outside of those presented on a couple of occasions.
What I have seen is the opposite. There has been what I term as a “Tool Proliferation Event”, with an explosion of alternative tools flooding the various sectors of the test tooling market (such as test management or test automation).
Some of these tools have spawned from boutique operations, small challenger organizations whose survival depended upon factors such as adapting rapidly to change. This means typically these organizations are pioneers and early adopters of agile processes. Within this realm, there was another trait, one of finding or creating niche tools. Tools with functionality not available from the mainstream vendors, or a reduced functionality and reduced cost version.
So … how many times can you recall seeing a defect management spreadsheet “knocked together in Kevin’s lunch hour”? Or an estimation tool, probably again in Excel, which “Geoff created and maintained as part of the project?”. This leads me to two questions:
Why is it always Excel? I believe this is quite easy to answer. Quite simply I put it to you that Excel is the most powerful programming language in the World. Quite a claim but think about it: it has a rich offering of easily accessible built-in functions; it’s exceptionally simple to learn; it’s available to pretty much anyone assigned a computer.
Secondly, and more importantly:
Why did Geoff and Kevin make these tools? I’ve already provided two fairly straightforward answers which apply in varying amounts to almost all situations – the tool fulfills a niche requirement and they are cheaper than the commercial alternative. But there’s more.
The IP of these tools is in-house, meaning new features or functionality can be delivered as and when required, without waiting for a new release from a vendor and not knowing if your requirement was important enough for them to include. Your tool is now agile to meet your organizational model. As long as nothing happens to Kevin or Geoff (Don’t worry, they’re fictional….).
Some of these tools created by Kevin, Geoff and their friends in other organizations, were made commercially outside of their original organization, and some of those, in turn, caught our imaginations and were adopted into everyday usage.
So why is this important?
As an industry we are transitioning from providing quality control (testing) to providing quality assurance, implementing a process which ensures best practice and high quality, where quality control is an automated part of this which confirms we got it right by design from the outset.
For instance, we are seeing test automation on the increase but also process automation gaining increasing prominence to support a Continuous Integration (and Continuous Deployment and Continuous Testing) pipeline. Examples of this include the increasing demand for Robotic Process Automation (RPA) or automated environment tools to support different levels of testing through the provision of disposable cloud environments.
This is important because the tools needed to support the transformation of our industry need to be created somewhere, and with increased agility, there is decreasing appetite to wait for incumbent vendors to react. Especially when the Geoffs and Kevins of the World are already creating the solutions we need right under our noses.
And that’s very much the point. If you talk about MVPs then people very much think of these in terms of the product, the system under (Development and) test. Only now we’re not solely focused on improving the quality of the end-product, but also, we are focused on improving the manufacturing process. And the chances are someone somewhere has created an MVP of some sort which already does some part of that. We just need to find the treasure hidden within our organization and productize it.
This approach is ingrained into what we do at Sogeti, with the experience of our consultants feeding back into creating World Class, global offerings reflecting the long term needs of our clients.
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.