How PerfOps revolutionized performance at Marks & Spencer
On 5th April 2016 at as part of How PerfOps revolutionized performance at Marks & Spencer
2014 was the first year that Andy Neilson, performance lead at Marks & Spencer, attended Velocity. It was a watershed event. Inspired by what he learned at Velocity, Andy has used it to help shape performance at M&S. In this talk, Andy shares M&S’s performance journey, what they learned along the way, and where they plan to go from here.
In the spring of 2014, some key things happened after marksandspencer.com launched on a new platform, to be managed in-house after years being hosted on Amazon. After launch, the company began a transition to agile delivery and Andy was asked to lead the performance team with the remit to “shape it."
With no background in performance, Andy focused on what was already in place, focusing on back-end and infrastructure performance… a continuation of the old ways of working. But once that work was completed in September 2014, he had two new questions on his mind:
• What does performance really mean for M&S.com?
• How to move away from traditional performance testing/engineering to align with an agile methodology?
These questions led to Velocity Barcelona, where Andy realised that his ideas aligned with what people were saying at the conference. He came away with the confidence to proceed, knowing that there were huge opportunities for performance wins.
In the following 18 months, his team created a PerfOps framework, and kicked off a number of initiatives to bring it to life. These initiatives included:
• Defining performance (business) transactions — a new way of documenting NFR in a non-technical, business-focused language to educate and to encourage adoption.
• Reviewing the full end-to-end journey — front end and back end — something that was missing because front-end measurements were not being captured.
• Identifying tools for testing page speed and measuring performance budgets in the delivery sprints.
• Automated performance testing of back-end transactions using the DevOps build pipeline within sprints to give early visibility of transaction speed degradation.
• Live monitoring — implementing a RUM tool to provide real-time visibility of our customers’ experience, and better use our synthetic toolset to complement each other.
• Structured forums with product owners and stakeholders to communicate/discuss facts and feedback from live monitoring and tests. This provides the PerfOps team with a means to ensure that performance optimisations get on the backlog for products, and are prioritised.