The Story Behind Dunelm’s 360° Digital Transformation

Dunelm is a billion-dollar British home furnishing retailer with 169 superstores, three high street stores, and over a hundred in-store coffee shops throughout the United Kingdom. It is listed on LSE (London Stock Exchange) and has been a major retailer for homewares in the country.

Like many other brick and mortar retailers, Dunelm came up against a challenge about meeting the modern tech-savvy consumer demands with legacy infrastructure. After careful planning and execution, the company started its digital transformation journey in 2017. By October 2019, the entire platform was rebuilt and redesigned to give a faster digital experience to all of its customers in a more optimal manner.

To talk about this amazing transformation, we successfully hosted a webinar in collaboration with Dunelm on 17th February 2020. The host, Harshit Paul, Digital Marketing Manager at LambdaTest, got together with the panel from Dunelm consisting of Stuart Day- Head of Quality, Ali Warsame- Principal QE, Adam Pike- Principal Quality Engineer, and Tomi Tiihonen – Principal Performance Engineer. This was a one-of-a-kind AMA webinar involving the story of Dunelm’s Digital Transformation journey. It was a full house during the webinar, and many people have requested more detailed material about it.

So here it goes!

How Dunelm Started its Digital Transformation Journey

Back in 2017, Dunelm was a very old monolithic platform. As an organization, it was evident that the platform would not provide what was needed to scale. That was when the Dunelm team decided to go all out on their most significant goal- accelerating the customer-first transition. They wanted to look at the purpose and proposition.

Stuart’s team had a clear idea about the focus areas, foundations, and shared values they were trying to go after as an organization. Instead of being defined as a brick-and-mortar company with a website, Dunelm wanted to become an omnichannel retailer that was digitally and technically focused. They wanted a platform that would help drive these ideas forward.

Stuart and his team discussed the idea at length and were confused between buying a new off-the-shelf product or engineering one internally. The final decision was to engineer internally, which and to this day, they all agree that it was the right decision. Yes, they did face some challenges throughout the process, but they agree that this digital transformation has brought some great learnings along the way.

Let us dive deeper and walk through the three-year journey of Dunelm.

The Awakening- October 2018

During this time, Dunelm was still running on a monolith IBM WebSphere commerce platform. It didn’t really provide what they needed to move forward, even in terms of how Dunelm was structured as teams at that point. Only a limited number of those teams focused on working in Agile and Scrum and were finding it rather hard to change through the system.

Stuart accepts the fact that they had a bad codebase. Releases were slowing things down, and deployments were taking too long. If they were lucky, they could release once every two to four weeks. Test deployments would take one to two hours, while production deployments took over two hours. And this was all done manually. All things considered, the quality standard was well above average, but they simply weren’t releasing very often.

Quality was considered to be only a QA’s job. They were expected to have razor-sharp focus, finding bugs left and right. While this was not too big of an expectation, it wasn’t working out well from a monitoring perspective. Instead of the QA team finding issues and getting them fixed, customers and website visitors were coming forward with their own set of problems.

It was high time Dunelm changed things for good!

The Initiation- 2019

Fast forward to 2019, and Dunelm started shaping up its move towards a new architecture. They were leaning towards API-driven, Microservices architecture and cloud-based technologies to back it up. After a lot of contemplation, they decided to go with AWS serverless architecture. Making the decision was easier than actually implementing since nobody in the organization had done this before. Stuart says that this was a bit of a leap of faith. It might have been a massive decision, but it was a risk Dunelm was determined to take.

He proudly reveals that today Dunelm is the second largest user of AWS serverless tech globally, right behind Nike. This shows that all the planning, investment, innovations, and team reshaping were completely worth it. They had to rewrite everything in Node.JS, React for building an amazing front-end website. Yet, some of their website’s major components, like the basket checkout, were still in PHP.

In 2019, they were finally able to launch the first version of the new and improved dunelm.com platform. This was despite the fact that a part of the website was still running on a legacy tech stack. But this was a big part of the transformation. It gave Dunelm more value than the risks behind it. It enabled the tech team to start releasing more frequently to their customers. Now, they were releasing about 20 times a week on average, with the extremely delivery-focused team.

The production environment brought in the sense of semblance for the tech team and was okay with issues. Yet, Dunelm didn’t want its team to get into a bad habit of being reckless, so they utilized Agile, Scrum, and Kanban to their best capabilities. They adopted the Spotify model for scaling agile and broke out into tribes and squads. The teams were divided into component-facing teams, allowing them to focus on specific components.

Dunelm was evolving fast, yet Stuart, the Head of Quality, felt it was not fast enough. They were releasing 20 times a week, but their releases were still relatively slow and cumbersome because of manual deployment & testing.

Quality was the topmost priority for Dunelm, and there was still a lot of room for improvement.

The Culmination- 2020

The Dunelm platform was improving rapidly and covering a lot of ground. Now, the team was looking for ways to improve their technology stack. Taking a step in the right direction, Dunelm joined hands with LambdaTest in April 2020 (more about this later). Furthermore, they collaborated with Datadog (from a monitoring perspective) and Fastly (from a CDN perspective). All these tools have helped Dunelm strengthen its Digital transformation journey and make its platform more superior.

Onboarding these third-party tools has helped support the speed of change that Dunelm wants to deliver. From quality engineers to product managers, everyone is much more aligned in terms of product quality and delivery expectations from their customers. In terms of releases, they’re now releasing up to 40 times a week and about 200 times a month on some key pipelines. The average production deployment duration across their CI/CD pipeline is around 30 minutes, with some of them implementing Continuous Deployment and others implementing Continuous Delivery.

Stuart further explains how despite different variations of maturity within the team, they have continued to collaborate and work on the quality. There was a time when they started noticing a few cracks building in because of so much change. But they have strived on with the aim to drive change non-stop. The entire team at Dunelm has ensured to reflect back now and then and look at how they can improve those things instead of letting their guards down. The best part is the amazing mindset shift around quality and how the entire team now owns quality.

Today Dunelm-

• Has a significantly improved website page load time.
• Can serve over 150% more traffic during peak periods.
• Has an average speed improvement of over 472% across the entire platform.
• The homepage has witnessed a speed improvement of over 900%.
• Has better security and the ability to feature flag new improvements.

Challenges Faced by Dunelm During Digital Transformation

It’s exciting to hear stories like Dunelm and see a brick and mortar business blossom into a successful eCommerce retailer. While the journey was exciting, it was also quite exhilarating for the entire team at Dunelm. Let us look into some of the most significant challenges faced by Dunelm during the past few years-

• Bringing Quality and Engineering together- How do you engineer with quality in mind? With their QA engineers working collaboratively with engineers every step of the way, a lot of pairing was happening. While this posed a challenge for individuals, they could think about the bigger picture and work together on the end solution.
• Setting the Right Mindset- From a quality perspective, it’s really important to have the right behavior and mindsets within teams. Otherwise, it gets tough to make these things work. Dunelm spent a lot of time and investment getting things up to the core and wanted everyone to contribute wholeheartedly. The team is still building and maturing, and there’s a long way to go.
• Onboarding New People- Over the last year, Dunelm has been onboarding many new people, which is amazing. But it’s also been very difficult for people to get to know each other, collaborate, and build those relationships, which are important for the foundational pieces of a team.
• Shift Left & Shift Right- Dunelm has been focusing on how they shift left and right and has been implementing many of the tools available. But implementing those tools and getting everyone on the team ready for them was quite a bit of a challenge. This is especially difficult because Dunelm is in the middle stage of shift left and shift right.
• Pipeline Monitoring- Using tools and automation has helped Dunelm deploy with their pipelines, but then once the code gets into production, there’s a whole lot of confusion. How do we monitor and observe the changes? How do we use customer feedback to innovate better?
• Minimizing the Impact of a Failure- Dunelm also does many feature flag releases to enable its team to test stuff in production. They build it, run it and own it. They believe in finding failure and recover quickly, which was a little tricky in the beginning. One way to do so was by rolling out to a percentage of customers at a time. This enables the tech team to recover quickly and deploy faster.

How LambdaTest has Helped Improve Quality at Dunelm

The COVID-19 pandemic further established the need for a well-oiled digital platform. Dunelm’s digital platform became the sole source for bringing in new customers, and this was about the time Dunelm partnered with LambdaTest. They needed a partner that would enable them to support the speed they wanted to deliver, and this was important to the team.

LambdaTest provided Dunelm with a much more robust solution than they’ve had before. It enabled them to test a wider range of browsers and devices. LambdaTest integrated well and easily with various tools they were using, including Test Cafe, Jenkins, and much more. Additionally, Dunelm was able to resolve 90 percent of the issues or questions they faced within a couple of hours, which was an amazing feat in itself!

With LambdaTest, Dunelm was able to-

• Find a robust solution to test a wider range of browsers and devices at speed in their pipelines.
• Integrate easily with tools they were already using, e.g., TestCafe & Jenkins.
• Get excellent ongoing support, with fast response times and quick issue resolution- 90% within a couple of hours.
• Listen to their customers about improvement and new features.
• Able to run 100s of tests a week at speed.

Here’s the complete recording of the webinar-

AMA (Ask Me Anything) Session

Here are some of the top picks from the exciting Q&A session at the end of the webinar-

1. What are the adjustments that you made in your company when the pandemic started? (31:12)

Ali Warsame- Although I wasn’t working for Dunelm at the time, I have seen within Dunelm that the main adjustment they have made was the cultural change. They had a lot of a good culture at the beginning, but they gave more team autonomy. Each team has got their ways of working. They make their own decisions, and they kind of create a fun environment amongst them. Collaboration is one of those things that makes me very proud to be part of this company.

Dunelm is the place where you get support from day one. I joined Dunelm last December, and I haven’t met any of the team members face-to-face. But I felt at home within the first week or so because there were the right kind of meetings that I was having in half an hour, very precise and, you know, just hitting the target. It was like if you need help from any team, you can approach them easily and get the type of support you need. You could share ideas, and when you bring your idea to the table, everyone kind of takes them on board. So you get the bonding of the teams that you’re working with.

Tomi Tiihonen- Before the pandemic, many of us were able to work from home anyway, so that wasn’t a huge technical challenge for the workforce to work from home. Obviously, we had to close all the stores, so all the emphasis was on the website. I think we were in quite a good spot with the technology for the website. There were some other things like social distancing during the shipping process that maybe had some challenges in the beginning.

2. From a quality and testing perspective, what should be the key pointer to note while breaking down a monolithic system into a more microservices-based one? Does serverless add more complexity to it? (35:24)

Adam Pike- One of the challenges I see is managing the re-platforming from a monolith to microservices. Because we carried over a lot of the same testing styles and techniques that we had there and while going to microservices architecture, actually alleviates some problems around testing. For example, you can develop and test your changes relatively independently, which is much more flexible. You can do that quicker, and you’ve got more control over it, which creates an explosion of integration points. And obviously, that makes it much harder, as you can’t test every integration point locally when you’re developing. So you rely on pushing things to the pipeline, running all of those tests you find out later in the pipeline if something has broken.

It’s also a lot more challenging to manage the data needed for those integration tests across your environments. So that style of testing is causing us some problems. It still works to catch issues, we’ve got those areas covered, but it’s maybe not as efficient as it could be. So we want to look to a way of working that speaks to the way the developers work. Like, how they develop independently, how they run their unit tests independently. We also want integration tests to give us that same ability.

There is a way of doing that, so we’ve been using and exploring consumer-based contract testing. The way that works is that it allows you to essentially run integration tests against the contracts between applications and run them independently. They have this concept of a consumer and a provider. The consumer is the app that’s making a request. The provider is the app that’s responding to it. So you start with the consumer- the consumer says we’ve got a requirement, we need to ask you for something you’re going to return it. So we’ll start a contract, and they do that by writing a test- a unit test against their client code. The result of that test is a file, a packed file, that details everything they expect to send and receive. We can then share that with the application that’s going to respond to it, and it can use that test asset to run its test and check that it’s verifying correctly that it’s responding the way it should do.

So, we’re doing an integration test against the contract, but we’re doing it independently. We don’t have to push to an integrated environment where everything’s running and wait later in the day to find out whether something’s broken or not. We could do it as early as possible in the dev cycle to work in a much more aligned way. The way you want to work with microservices anyway. This is something that we’ve been exploring more, and our coverage is growing. I think now, wherever we’re starting new APIs or starting to build new stores on existing APIs, we include Pact as a part of that, and we’re exploring how that works both from the technical perspective and also the workflow.

One area where it’s more difficult to bridge the gap is where we’ve got existing APIs where they don’t currently have Pacts. We need to retrospectively try to add in, and that’s more difficult, so we’re looking at a challenge and how we can add to it. But so far, we’ve already seen that the Pacts we’ve added have added value for us. They have founded issues earlier on in the development cycle than our integration tests. The end goal is to start to alleviate some of the pain that we see with their integration tests, their current legacy integration tests and have a more sensible approach to how many of those we need, how many we need to maintain once we’ve got our coverage up.

In terms of AWS Lambda, I’m not sure it’s more complicated. It’s a different complexity over running a monolith. There are different complexities, and once you’ve understood what that complexity is and how to manage it and work with it locally, it’s not a problem. We know the CLI tools that we need to use. We’ve got AWS SAM, we’ve got our Docker set up locally. So we can run those tests in a local docker simulating how it would normally run in the environment. As long as you’ve got your mocks in place and if you’re using solutions like Pact for consumer contract tests, then you can do that in isolation pretty well.

3. What impact did the front-end redesign have on the performance of your site? (40:21)

Tomi Tiihonen- When we started the re-platforming, we wanted to create a new front end to our site, and there was a benefit of knowing all the things you don’t want to do when designing this. We decided to design from the ground up, not using an existing framework, but it’s a React Single Page Application (SPA) that we decided to build. We ran the current site parallel with the new site as we were building, so we could monitor the difference as we were building. The site performance was one of the most important things to ensure that the site performs better than what we have now. So that was clearly on our view all the time, and we had good statistics on that. It was pretty obvious when we then switched over that it just felt like you’re in a different decade. Maybe not many people in this audience have used Dunelm in the previous life, but it’s an entirely different shift when we released the new app.

There was also an element that we wanted to get across the line quickly. Some of the functionality we decided not to take over straight away, so the site was also barer. There was an element of using new technology and reduced functionality that resulted in a very fast experience. Now since then, we’ve added more functionality and this battle around the site performance is ongoing. As we add more things, there’s a constant battle of what we should be doing correctly. For example, we have a task force in place right now that is looking at some improvements for the site because there’s a new Google search engine update coming in May that has a special focus on user experience, so in anticipation for that, we’re not quite where we want to be. Overall, I think we’re performing quite well for most users, but there is a kind of a long tail of users on certain devices that don’t have as good an experience as we want them to have. So it is an ongoing effort, but it’s clearly in a completely different category where we are now than where we were before the transformation.

4. How has team collaboration and productivity been impacted by remote working? How have you ensured this hasn’t impacted any quality aspect? (43:04)

Ali Warsame- At Dunelm, we have many different service providers, so we are already used to remote collaboration, where we know what tools to use and how we overcome that. When the pandemic came, it became business as usual, where many people used to work from home anyway in the first place, and kind of took a bit more. I believe that productivity has gone up a bit more in terms of productivity due to the people being locked down and having more time to work. Although culturally, we make sure that we also look into the human side of the employees and have a personal chat to understand everyone’s well-being.

When it comes to quality, we don’t compromise the quality. The quality stays in place. Every release that we conduct has to go through all the gates that it should go. This involves the different layers of testing and also the involvement of our quality engineers, who are there in each and every team. They kind of shift left and get involved in the early stage, so we don’t compromise their quality. Quality never dropped from where it was.

Stuart Day- I think we’ve done well to reduce the impact. There’s always going to be an impact because of the scale at which the changes will come in. The speed at which everything was changing from a pandemic perspective- what is next, what is next. I think we’ve set ourselves up to write that out and be successful. I mentioned in the presentation that we’re just starting to see a few little cracks here and there. We must identify those things and be open and honest about that to ourselves and say, yes, we aren’t as good as we thought we might be. We need to address these issues, and that’s what we’re doing.

We’ve got road maps of improvements we want to continue working on. When you’re doing stuff at speed, there’s always going to be a risk to the quality, and it’s getting that balance right which is still very difficult. That’s where the agreements need to come in across our engineering, quality, product communities that everybody is on the same page. That yeah, there might be issues, but can we fix them quickly and resolve them? That’s kind of where we are with that.

5. Has Dunelm seen a noticeable change in demand through your mobile site? (53:46)

Tomi Tiihonen- Over 50% of our usage and revenue comes from mobile now. Mobile is by far the most important interface to Dunelm.com. There is a slight difference in conversion. I think that the desktop converts better. Maybe people might typically browse more on mobile and still prefer to buy on a desktop. The conversion on mobile is quite stable, tablets have less importance nowadays. But yeah, mobile is the most important thing, and all the monitoring that we do really for the side speed is mobile-centric. We don’t see an issue with the desktop for the speed. Our site is fast enough on desktops. The issues that we have are on mobiles.

6. What metric are you evaluating the use of LambdaTest? Is there any particular metric in place on which the product is being evaluated? (58:18)

Stuart Day- When we did the POC with LambdaTest, there were two significant factors. One was in terms of spin-up times and how things would spin-up in terms of speed to enable our test to run. The other one was very much around the support we would get if we had an issue. The previous providers were challenges for us, and for us, it wasn’t about running the tests in different browsers or anything like that. There’s a whole host of people out there that offer the same type of service and can do the same thing in terms of coverage and maybe more. It was very much about having somebody to partner with, someone who understood our values, our ways of working and would be supportive of that.

We talked a lot about that when we were speaking with LambdaTest initially, and I’m happy to say that since signing up and working with the guys, it has come across that they can support us very quickly if we have an issue. We’ve not had any issues in our pipelines from a speed-to-test perspective, which are the key measures for us. We don’t need to run thousands of tests today, but the tests we do run are valuable, and we need them to run quickly. If we do have an issue, we need that issue resolved quickly, and they were the metrics that we were working towards.

Adam Pike- With this and everything else that we do, we still try to evaluate everything that we’re doing continuously as part of our continuous improvement. Double-checking whether we are using this to its full capacity? Is there still value in the way that we use this? Because quite often we, especially larger companies, fall into the trap of the standard way of working and we keep using it. We only find out later what pain we’ve caused ourselves by not doing this the right way or not using it to its full capabilities.

So it’s something that we’re trying to continually evaluate our use of LambdaTest or any other tool or service provider. Just verifying, have we got the best out of this partnership? Can we get more from it? Do we need to involve anything else? Is there something else we do? This ties into our UI automation and testing strategy overall, so there are many questions that we still have about how we approach our tests with this. We like the setup we’ve got, but we’ve got some challenges. Certain tests perhaps don’t give the value that they should, and there are maybe other ways to test those things. So, part of our continuous improvement is always to continually evaluate based on how we’re currently working and seeing any cracks or anything that we need to have a further conversation with.

As Stuart said, we found that LambdaTest has been a perfect partner whenever we have evaluated and thought about what we need more. We’ve got some more performance testing that we’d like to do through the front end. Is that something they’re thinking about for their backlog? Can we join that conversation? That’s always something they’ve been open to, and that continued dialogue with us.

7. In terms of shifts and trends around quality and testing, what would you say are the key things to focus on and get better at? (1:04:27)

Adam Pike- My perspective when I worked as a contractor for a while I moved around a lot, and I don’t know about trends, but I would always say look at the way you are. Do you want to have a culture in the company? What are you trying to achieve as a company? Also, look at how you’re building your software. Your quality culture should follow that right. You can’t try and have a separate initiative around how you do testing and quality. That’s separate from how you develop your architecture or the direction that your business wants to go.

So it’s more about not worrying too much about the trends in the market unless they specifically align to the way that you’re doing things like, for example, you’re going microservices you start looking at trends and how that is a trend in the market people are going that way, so you start looking at what are the trends around quality and testing for microservice. We’ve talked about consumer contract testing as one solution that helps work in that correct way for microservices. But the most important thing is to talk about how you’re working, so if you’re working with a monolith, you know there’s no point trying to implement ways of working that don’t work with that style. You have to work and test and have a quality culture that speaks to how you develop your software and the culture you have in the company.

Stuart Day- Yeah, from my perspective, I think if we look at the industry now in terms of- you can’t, well you scroll through LinkedIn you look at job adverts, etc., everything is crying out for automation, and it’s quite damaging to it. I think many people ‘drive’ just purely around automation. Automation is an enabler to do all different things. One of those great things is enabling you to explore your products manually far better because you’ve got time to do it. From a trends perspective, I would encourage people to be looking around that balance more and not looking for the silver bullet.

Automation is not a silver bullet. Use all the different tools and techniques to build the approach you want to take. That way, you’ll start getting the best quality out there. Ensure that you’ve got a mix of people with different skills, don’t be afraid to have exploratory testers with expertise in that area, and mix well with engineers who are very good at automation and things like that. They’re all going to help each other, and that, for me, is the biggest thing. I would encourage people to be mindful of this, whether you know whether you are a QA, whether you are a leader in any organization, don’t look for a silver bullet because it’s not there.

8. Boards are addicted to the numbers. Is there a specific set of metrics you use with them that is not team-level metrics? (1:08:23)

Stuart Day- One of the things that we’ve worked hard on during the re-platform is how we structure our teams and structure our communication levels. So top up the leadership stack, to be fair, we’re quite a flat structure at Dunelm. We look at everybody as peers rather than managers. We very much focus on leadership rather than management, so just to make that clear to start with. But in terms of reporting to the exec, we work very closely with them to determine what you need from a communication perspective. What are the details that we get with the teams on the ground for those teams, what they capture as part of their outputs from their iterations, and their velocity and stuff, like that is for your team, it’s not for a reporting metric and so.

There were a lot more of these exciting Q&As in our webinar.

• How have you enabled a culture of quality through your engineering delivery and product teams? (46:21)
• QAops- is that something Dunelm believes in? (48:56)
• Are your dev and product teams all ambassed? We have challenges due to the teams being based in different countries, so the time zone affects us. (50:16)
• Do you have any advice on getting a product on board with Shift Left? (51:52)
• Are you happy with the way you’re using Scrum and Kanban now? What were your key learning points, and what was the most important improvement there? (55:01)
• Being a big e-commerce moving from one platform to ad hoc, it comes with a big set of challenges from a tech point of view. This will inevitably impact SEO from at least two points- page speed and the number of page duplications hence their organic traffic. How is that managed? (1:02:45)
• How is Dunelm approaching PWA- Progressive Web Apps? (1:11:11)
• Do you believe in the buzzword Shift Left Testing? (1:12:25)
• My experience is that team culture is generally not where the problem lies. How about we talk about leadership? Do you ever have to justify the investment in quality? Do you put a cost on quality issues? (1:15:17)

Wrapping Up!

I hope you enjoyed reading about Dunelm’s journey to rebuild and redesign their e-commerce platform for faster digital delivery and how it positively impacted their online growth. It was a mind-opening session to have the entire panel share their experience with us. Whilst Dunelm may have already put a new platform out; they are still looking to innovate in newer ways and build faster & better.

Hopefully, this will give you some ideas of how this can work despite the challenges you face along the way. Shoot up your questions our way if you have any questions about the webinar. We have more exciting stories coming your way. Make sure to register the next time!

Happy testing!