We’ve been collectively following a few practices over the past few years, like SCORP, our agile way of doing well-architected work in every sprint with teams. We have the whole idea of engineering excellence, looking at what you’re doing and constantly improving, and HP (high-performing engineering) to capture key metrics to define good engineering or architecture and then discuss it as a team. Even though the practices are out there, it’s just a mindset.
One of our first ideas came from Matt Wynne, whom we met many years ago. He introduced us to the Four Disciplines of Execution: have a goal, gamify it, and meet to improve it. It’s a mindset of continuous improvement; no matter how small the progress is, it should be celebrated, discussed, and championed.
What is SCORP?
The well-architected framework came out in 2013/2014. Initially, some people saw it as an audit. AWS asked you a bunch of questions that used to take a week. We’ve been through a few of them. It’s a brilliant framework, but Mike thought, how could we make it into a regular event per sprint? Mike developed the magic acronym of SCORP: Security, Cost, Operational Excellence, Reliability and Performance, and Sustainability. So it became SCORPS. Mike pioneered it in his squads.
At the time, the name was deliberate to make it stick in your head. The idea was to do well-architected reviews and milestones. However, we found that teams and squads circled back with well-architected, revisiting each milestone. So, we needed to gain ground between the milestones and action. The new idea was to do well-architected reviews that made it onto the team’s backlog. And challenge squads to make good decisions and work towards reviewing and addressing outcomes. Over time, the small wins led to continuous improvement, which is at the heart of SCORP.
So we decided to meet regularly, with well-architected as the foundation, and have all teams get together in SCORP sessions for an hour. Each team would get 15 minutes, or if you had a lot of squads, the session would run over an hour and a half. The idea is that we don’t solve the same problem multiple times. Can we instead help each other and mobilise the community? It’s an incredible process, and we’ve stuck with it.
Cloud Providers are constantly releasing improvements.
Cloud Providers are constantly releasing a firehose of improvements, new features, and capabilities. So, if you’re only meeting to do well-architected reviews once a quarter or every six months, there’s an evolution in the ecosystem that you will not be able to take advantage of. Because you do SCORP regularly and continuously, it’s a great way to incorporate new service updates, security features or cost optimisations. It is continuous learning. Typically, somebody on the squad or team will see and share the latest update so another team can adopt it. It’s invaluable, continuous improvement. There are no small victories or wins because they compound over time.
It was similar when we started threat modelling and Wardley mapping. Once you learn the basic technique, get a few people together in the community to discuss it and co-create it. Classroom-based learning doesn’t work because everything changes so fast. Get together and discuss what’s happening. And have a focus, whether it is well-architected or engineering excellence.
How do we run our SCORP sessions?
In SCORP sessions, we have representation from each squad so they can tell their story through their dashboard. They organise their dashboard around SCORP with a security, cost, operational excellence, reliability and performance perspective. We share what’s working well and what’s not. Because even when things fail, we’re interested in what happened to prevent it in future. We want to be open, share and collaborate. As well as incrementally improve our engineering, ways of working, workload and business outcomes. It’s baked into the narrative.
Value is compounding. The initial sessions can be awkward and challenging, and teams might need help understanding our goals. But once they get into the cadence, the good things build on each other. Similarly, bad things build up if you don’t do the SCORP sessions, and your software will decay. Your solution will also decay if you don’t do SCORP sessions regularly because you’re not maintaining or seeing what you can improve. It’s about trends. Our SCORP dashboards have score trend data for teams that support several workloads over extended periods. At some point, you must sit down, examine the trends to spot degradations over time and drive action. For example, cost tends to creep over periods. SCORP is a powerful way to maintain your operation and ensure everything is as expected.
Is it easier to provide empirical data and dashboards than when we first started doing SCORP?
It used to be a big blocker. Collecting data was complicated, and we had to push back against that. We meet the teams where they are. In any organisation, there will be different levels of experience and maturity, and some teams will be more evolved than others. Setting up a Confluence page to manually collect certain information is a good start.
I remember being at an XP conference a few years ago and trying to find the best way to do dashboards for this. I had it in my head that we would put them on TVs and ask a graphic designer to help. However, the graphic designer advised me to do it on a whiteboard to make it easy to change. Because the more fancy it is, the harder it is to change. Instead, make it a lo-fi dashboard and permit people to change it.
The atmosphere in SCORP sessions is essential. You need to have good craic!. People ask if a metric is good or bad. I respond by saying I don’t care if it’s good or bad. Are you happy with it? And is it better than the last one? What way is the trend going on? It’s not about holding a mirror up as it is their workload. What do they want to happen here? If it is a useless measure, take it away and get rid of it.
Don’t compare Teams.
Psychological safety is a big thing. Meet teams where they are, in their context. Don’t compare teams to one another or anybody else’s dashboards. It is about their journey. If they’re making marginal improvement or gains in every SCORP session, then celebrate it. It shouldn’t be, ‘Why haven’t you done what this other squad has done? ‘ The other squad may have started three years ago. They may have a different workload.
There are several vital mechanisms. Firstly, having a dashboard is essential. Keep it simple. Talk about numbers and empirical evidence. Look at numbers and trends to see which way the team are going. Secondly, psychological safety is essential. I always say, ‘This is for you, let’s just have a good conversation’. Thirdly, meet the team where they are. If a team is busy with production defects, it’s okay not to do this today. Figure out what the vibe is. Don’t beat up teams with engineering excellence. You need to encourage them. Bias for action is essential. You want teams to try, and you must appreciate or give credit to engineers thinking about stuff.
Multiple teams together demystify the issues.
Having multiple teams together in the session helps demystify the issues. One team will have done something, and it will encourage the other team to try to do the same. It removes the mystery or the mist so they can adopt the new thing.
When a team starts with SCORP, as SCORP champions, we facilitate and help the team set up. But it’s their process. And they, you know, we’ll get them into a position where it’s self-sustained, and they’ll run it. The first handful of sessions are hard. But once one squad starts to run with it, you get positive peer pressure. One team adds a wee bit to their dashboard and talks to it, and then you see other teams follow suit. And then, before you know it, it’s an enjoyable session, and so much good stuff is happening.
A sign of healthy SCORP is that the dashboards are all different. Although they have similar goals, they’re different because teams decide to measure in different ways. It’s one thing to watch for. We don’t like it when people come in with pre-cooked data and start a session with a pre-prepared dashboard. Ask the team what their story is and what they want to tell. However, we do have starter templates. So start people off, but permit them to change it. Encourage them to change.
Summary of SCORP
Let’s boil it all down. We discussed SCORP, engineering excellence, or HP and why we do these things. It’s about atomic habits. There are software factories or feature factories with people knocking stuff out at a rate of knots. But there’s no ticket to improve. You must have an atomic habit of looking at your work because it should be about craftsmanship, looking at your work, making something better, and being a better engineer. That’s what we’re all trying to do anyway.
Serverless Craic from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on X @ServerlessEdge
Follow us on LinkedIn
Subscribe on YouTube and Spotify