Team Engineering with SCORP - there are practices we do like SCORP, which is our agile way of doing well-architected in every sprint with teams. Our practices are connected to engineering excellence, looking at what you're doing and constantly improving. And HP (high performing engineering), as a way of capturing key metrics to define good engineering or architecture, and then talk about it as a team.
Even though the practices are out there, it's really just a mindset.
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
Team Engineering with SCORP - there are practices we do like SCORP, which is our agile way of doing well-architected in every sprint with teams. Our practices are connected to engineering excellence, looking at what you're doing and constantly improving. And HP (high performing engineering), as a way of capturing key metrics to define good engineering or architecture, and then talk about it as a team.
Even though the practices are out there, it's really just a mindset.
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
Hey folks. Welcome to the next edition of Serverless Craic. How are we doing? What's the story?
Michael O'Reilly:I've had a day of doing what we're about to talk about! I had a few of these SCORP sessions on the go.
Dave Anderson:SCORPing
Michael O'Reilly:SCORPing away today.
Dave Anderson:I am SCORping myself this week. It's a good segue, because we've been talking about this a wee bit this week. I was at an event earlier in the week, where I was talking about something similar. There's a few practices that we've been collectively doing over the past few years, like SCORP, which is our agile way of doing well-architected 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), as a way of capturing key metrics to define good engineering or architecture, and then talk about it as a team. Even though the practices are out there, it's really just a mindset. One of the first ideas we have to give credit for it to Matt Wynne who we met many years ago. He introduced us to the idea of
Four Disciplines of Execution:have a goal, gamify it and meet to improve it.
Mark McCann:It's a mindset of continuous improvement and no matter how small the improvement, it should be celebrated, talked about and championed. What about people who don't know what SCORP is?
Dave Anderson: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 came up with the magic acronym of SCORP: Security, Cost, Operational Excellence, Reliability and Performance, and then Sustainability. So it became SCORPS. Mike pioneered it in his squads.
Michael O'Reilly:At the time, the name was deliberate to make it stick in your head. The idea was to do well-architected reviews and milestones. But I was finding that teams and squads were circling back with well-architected and revisiting each milestone. So we were losing ground between the milestones in terms of action. So the new idea was to do well architected reviews, that made it onto the teams backlog. And challenge squads to make good decisions and work towards review outcomes and address them. Over time the small wins led to continuous improvement, which is at the heart of SCORP. So we decided to meet on a cadence, 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 help each other instead and mobilise the community. It's an awesome process and we've stuck with it.
Mark McCann:Cloud Providers are releasing a firehose of improvements and new features and capabilities all the time. So, if you're only meeting to do well-architected reviews, once a quarter or once every six months, there's evolution in the ecosystem that you will not be able take advantage of. Because you do SCORP regularly and continuously, it's a great way to incoporate new service updates, security features or cost optimizations. It is continuous learning. And typically there will be somebody on the squad or team who sees the new update, and shares it so another team can adopt it as well. it's invaluable, continuous improvement. There are no small victories or wins because they compound over time.
Dave Anderson: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 sit and co-create. Classroom based learning doesn't work because everything is changing so fast. Get together and discuss what's happening. And have a focus, whether it is well architected or engineering excellence.
Michael O'Reilly:Yeah, no, that's it. In SCORP sessions we have representation from each squad so they can tell their story through their dashboard. And their dashboard is organised 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.
Mark McCann:Value is compounding. The initial
Michael O'Reilly:It's about trends. Our SCORP dashboads have sessions can be awkward and difficult. And teams might not understand what we're trying to achieve. But once they get into the cadence, the good things build on top of each other. score trend data over extended periods for teams that maintain Similarly, if you don't do the SCORP sessions then the bad things build and your software will decay. Your solution will decay if you don't do SCORP sessions regularly. because you're not maintaining or seeing what you can improve. several workloads. At some point you must sit down, examine the
Mark McCann:Do you think it's easier to provide that empirical trends to spot degradations over time and drive action. For example cost has a tendency to creep over periods of time. data and dashboards with real data compared with when we first SCORP is a powerful way to maintaining your operation and
Dave Anderson:It used to be a big blocker. Collecting data was started doing SCORP? complicated and wehad to push back against that.
Michael O'Reilly:We meet the teams where they're at. In any ensure everything is as you expect. organisation, there's going to be different levels of experience and maturity. Teams will be more evolved than others. Setting up a Confluence page to manually collect certain information is a good start.
Dave Anderson:I remember being at an XP conference a few years ago, and I was trying to work out the best way to do dashboards for this. I had it in my head that we would put them in TVs and ask a graphic designer to help. But 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 give people permission to change it.. The atmosphere in SCORP sessions is important. You need to have good craic!. People ask if a metric is good or bad? I respond by saying that 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. This is their workload. What so they want to happen here? If it is a useless measure, take it away and get rid of it.
Mark McCann:Psychological safety is a big thing. Meet teams, where they are, in the context that they're in. Don't compare teams to one another or anybody else's dashboards. It is about the journey that they're on. If they're making marginal improvement or gains in every SCORP session, then celebrate it. It shouldn't be 'Why haven't you done that this other squad has done? The other squad may have started three years ago.
Dave Anderson:They may have a different workload. There a several key mechanisms. Having a dashboard is important. Keep it simple, talk about numbers and empirical evidence. Look at numbers and trends to see which way the team are going. Psychological safety is important. I always start off by saying, '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 to not 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 appreciate or give credit to engineers, who are thinking about stuff.
Mark McCann:Putting multiple teams together in the session helps, because it demystifies the issues. One team will have done someing andit encourages the other team to try todo the same. It removes the mystery or the mist so they can adopt the new thing.
Michael O'Reilly:When a team is starting with SCORP, as SCORP champions, we come in, facilitate and help the team set up. But it's their process. And they, you know, we'll get them into position where it's self sustained, and they'll run it. The first handful of sessions are hard. But as soon as one squad starts to run with it, you get positive peer pressure. One team adds a wee bit to their dashboard and talk to it, and then you start to see other teams follow suit. And then before you know it, it's an enjoyable session and there's so much good stuff happening.
Dave Anderson:A sign of healthy SCORP is the dashboards are all different. They have similar goals, but they're all different because teams decide to measure in different ways.
Michael O'Reilly:It's one thing to watch for. I don't like it when people come in with pre cooked and starting a session with a pre prepared dashboard. Ask our team what there story is and what do they want to tell.
Mark McCann:Although we do have starter templates.
Dave Anderson:Yes start people off, but give them permission to change it. Encourage them to change. Let's boil it all down. We talked about 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 nust 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. So that's the craic. We have been SCORPing like mad this week and it is good fun. So have we look @ServerlessEdge on X and the Serverless Craic podcast. Give us a like or subscribe.