The UK telecoms industry is a very competitive market. One of the keys to success is to deliver software changes quicker to market than your competitors – that not only need to functionally work but also, perhaps, more importantly, have a superior user experience.
If that wasn’t hard enough along came COVID-19. Although the telecoms industry is relatively resilient to COVID-19, it is certainly not immune to the impacts of it. The perennial efficiency targets have now been added too.
Many challenges...
That challenge of improving time, cost, and quality seem paradoxical. I started my career as a project manager and remember vividly being told that you could only ever affect two of those forces. In order to meet this challenge, it is inevitable that QA & Testing needs to modernize. New technologies, trends, and demands are changing the shape of ‘Testing’. Joachim Herschmann (Senior Director at Gartner), during a keynote speech at a recent conference, said “the starting point has to be the adoption of the aforementioned Continuous Quality Strategy, moving from ‘quality control’ to ‘quality assistance’, socializing the idea that everyone is responsible for quality and starting and ending with the user in mind. Quality should be infused right from the inception of an idea”.
But change is difficult. In my experience, the bigger and more complex the organization is the harder it is. Like most large organizations, there are plenty of siloed working (and mindset), tons of legacy systems and technical debt, lots of egos, and getting things done is not always straightforward. Our flagship transformation program ‘Simplify’ is looking to tackle some of this. But in order to support that program, it requires a complete change in approach. There’s plenty of work outside of that program that also requires an improved time to market, better quality, and reduced cost.
So, during all that change, huge complexity, and numerous challenges, how is it possible to implement and scale-out a continuous quality strategy, whilst simultaneously embracing new trends and technology and move to a quality control mode of working?
Well, I certainly don’t profess to know all the answers. In fact, what I’m about to talk about comes largely through doing the ‘hard yards’ and learning from our own mistakes. Although every organization is different, I believe the challenges and landscape that I have described are widely common and have resonated. We’ve still got a long way to go on our journey.
So, here are my top 10 tips and learnings on how to scale transformation, based on our Continuous Testing transformation within BT…
1.Choose the right partner(s)
Although we use a lot of open-source software with BT, sometimes large organizations need enterprise-grade solutions to deal with the different challenges and landscapes. At BT, we have a mixture of different delivery modes (Agile, Waterfall, ‘Scrum-fall’, etc.) and different types of technologies and hosting (on-premise, various Cloud infrastructure providers, ERP cloud-based software providers, etc.). But perhaps more important than being technically capable is having partners that share the same vision, have program champions on both sides, and show their ‘skin in the game’ (flexible commercial arrangements where software providers back their product and work with you to exploit areas for growth rather than over-promising and tying you into long term contracts is a good example of this).
At BT, there is a huge engineering legacy that has often led to a belief that everything must be built internally. This often tends to take time, becomes more costly (although some of that enormous cost is hidden) and even then the product doesn’t quite do the job as well some external companies, who benefit from scale of economies and continuously learning from the plethora of companies that they are involved with. This reminds me of a project called Chrysalis. You probably won’t know what that is and that’s the problem. By the time the product came to market, it had missed the boat, was functionally great but had a terrible user experience, and wasn’t well made (we didn’t make those kinds of devices, so it was always going to be a stretch to do it well!).
Oh, and it’s important to have fun and celebrate achievements together! That applies to all teams and everyone should feel part of the same team.
2. Be human-centered and service-oriented
In many companies, the business holds the purse strings. Getting the business to part with money is another thing. I’ve seen many technical teams not getting funding or support for transformation because they jump to solution mode and fail to understand the problems or aspirations of their stakeholders and/or struggle with business cases because they are not data-focussed.
By adopting a human-centered design approach, we were able to connect with our stakeholders and customers, take a more service-oriented approach rather than just delivering functionality. It provided a clear and more repeatable method for judging the viability, feasibility, and likability of proposed solutions to problems. When introducing new services, we delivered a MVS (‘Minimum Viable Service’) to further assess the value of services and track how well it was tackling the problem.
We even applied this method when our test and defect management systems were up for renewal. By understanding the ‘jobs to be done’ and extracting useful data from the system, as well as understanding the pain points of the current system and aspirations of the teams using the existing suite of tooling, we were able to move from a practically EOSL, waterfall-based, clunky (as captured in research with users), monolithic system to a much more flexible, light-touch system that met all our needs but saved £5m over 3 years. It also has a much better user experience and also supported our move to Agile (which is also the mode of delivery for our Simplify transformation program).
In our IT function, we have the concept of a virtual ‘MarketPlace’ where services can be ordered, which was a great showcase for some of the new innovations we wanted to introduce, along with the relative uses cases to show the value and support to aid adoption.
3. Lighthouse projects
Don’t try and boil the ocean all at once. One of our first human-centered design services was called ‘Quality as a Service’ and was looking to reduce the ‘CX gap’ – where testers think that they have delivered on the requirements they are given but the business is then unhappy with the quality of the product that they have delivered to them.
During a PIR of a project in our HR space that went live 6 months late and with 40 defects in the warranty period we realized that the biggest contributor to those issues was around requirements. It also took us weeks to manually create test scenarios and test cases, whilst still having low test coverage. The testers blamed the business and the business blamed the testers. In a subsequent phase of that project, we rolled out our ‘QaaS’ service, based on a Broadcom tool called Agile Requirements Designer, which meant the testers and business could collaboratively develop models using flow charts (which was a lot more effective than flinging requirements documents over the fence and asking them to list acceptance criteria). This helped tease out acceptance criteria, increased test coverage and we were able to generate test cases in days rather than weeks. This, in turn, led to the second phase of the project being delivered in time with zero defects reported in the warranty period.
From this, the business then asked for us to roll the service out to all their projects. Getting funding was easy after that (to note – our partner, who understood our challenges, provided the licenses for the lighthouse project for free).
4. Ring fenced resource
Ring-fencing the resource so that it is protected against ‘raids’ from the BAU work is essential. Any resource assigned to these roles needs to have great stakeholder skills. They should be identifying key stakeholders, understanding their needs and looking for vision alignment, and then working with those stakeholders to support their needs (whether that’s presenting on their team call, helping provide data for a business case they have, formally recognizing the right behaviors in that other team, etc.). We’ve held QA days and invited senior stakeholders to improve their understanding of our vision, gather their support, and give them our asks.
It is critically important that the ‘ring-fencing’ is for the purpose of resource ‘protection’ and does not result in the Transformation Team’s ‘isolation’ from the rest of the organization. I’ve found that having a strong change and adoption manager who is conscious of this can help to avoid organizations falling into that trap.
MD of IT (far left) attending a ‘QA Day’ that was arranged in Chennai
5. Different horses for different courses
One mistake we made was to treat our stakeholders in the same way. Where we got traction with one stakeholder who ‘got it’ the same approach with another stakeholder – who were up to their neck and it and because we didn’t pitch the business outcomes immediately adopted a “we’ll wait and watch how others get on” approach. It didn’t work and we missed the opportunity. It also often helps to give a visual mock-up or storyboard of what you’re trying to achieve and using real data to clarify the positive impact that the change will have on that area that you are pitching to.
6. Tools will only get you so far…
We’ve started communities of practices, carried out QA maturity assessments (it’s amazing how some spider diagrams can spark competition between different areas to adopt something), created Continuous Testing handbooks, stored training courses on our learning platform, to name a few. These are key to both increase and sustaining adoption.
Example QA maturity assessment
7. Shared objectives
If you need another team to be successful then why not ask their senior leaders that they have the same objectives as you? The potential to not hit a bonus is an effective carrot-and-stick!
8. Tie into wider organizational initiatives
For example, Human-Centred Design was the key driver of our IT level transformational at the time. As well as large organizational initiatives, there will be other opportunities e.g., we’re currently undergoing an internal audit around test data, the output of which may well an enabler to accelerating a test data management capability. One of my team is a part of a ‘Tech Accelerator’ tribe within the Simplify program, which gives us visibility of problems faced by the business and the chance to increase adoption by showing we can tackle those problems, and in a consistent way.
9. Identify people who have got the ears and trust of senior leaders in other parts of the organization
There was another part of the Technology organization that it was always felt was difficult to engage with. They externally hired a resource who came with a fresh approach and through proactively reaching out to that person and being open to their expertise on other fronts we now have three joint lighthouse projects across our OSS stack. Through that, we’ve been able to present to other key stakeholders in that area and increase the profile of what we are doing.
10. Get formal risks raised at the right level about the impact of not using CT
For example, can’t keep up the pace in a competitive market; may not achieve targeted efficiencies; impacts of poor quality/customer experience gap. It will focus on senior stakeholders’ minds and is likely to at least provoke a discussion.
Article written by Glyn Martin, Head of QA transformation at BT
