Technical Literacy for Scrum Masters - Part 1
Technical Literacy for Scrum Masters - Part 1
Making sense of your team's technical conversation during Kickoff discussions 1 and 2.
👋 Hello, I’m Vibhor, and welcome to the 🔒 subscriber-only edition 🔒 of my newsletter, the “Winning Strategy.” Every week, I answer one reader question about Agile Products / Processes, Role-based Skills, and anything else that you need answered about your Career Growth. You can send me your questions here.
Note: If you get any value from this post, please show your support by clicking the little gray heart below the title above. It would really mean a lot and help spread the word about this growing newsletter. 😍
Quick Reminder: The price for the paid subscription is going up on 15th November 2023. For more details, read “I Am Bringing My Career Journals to Winning Strategy.”
Also, starting this Thursday, the 2nd of Nov 2023, I am starting a new “Training Series” on "Scaling Agile Practices.”
On to this week’s question!
Q: Hi Vibhor. I got a lot of valuable insights from your technical series on YouTube. Could you break down common technical concepts scrum teams use in their everyday interactions?
Thanks a lot for the question.
For those who are not familiar with the Technical Playlist on YouTube mentioned in the question, here it is:
Your role as a Scrum Master was traditionally non-technical, and it made complete sense.
Why?
Because you, as a Scrum Master, focus on things like:
Helping your teams get along and work together (Team Building)
Making sure everyone's on the same page and knows what to do (Team Facilitation)
Helping teams get stuff done and do it well (Team Productivity)
Figuring out the best path to get things done (Team Process)
Keeping teams quick on their feet and ready to pivot (Team Agility)
You’re all about the “human” side of building the Product.
But…here’s the thing.
This “Product,” in most cases, is not just any kind of product. It is a “Technical” Product. A Product that is a software. And that’s no small thing!
The world of software development is changing, and it’s changing faster than you think. So if you, as a Scrum Master, want to keep up and really make a difference for your teams and your career, you’ve got to get your hands dirty with some of the technical stuff.
The good news is you do not need to be a “Technology Expert.”
You just need to be “Technology Literate.”
You need to be aware of the technology, technical terms and tools that your team is using to build the product.
I’m talking about things like CI/CD, DevOps, microservices, technical debt etc.
These aren’t just fancy buzzwords; they’re the bread and butter of how software gets made these days, and they have a huge impact on your teams.
Why should you, as a Scrum Master, care?
Because these technical challenges, they’re not happening in a vacuum. They’re happening right there, affecting your team’s day-to-day work.
That feature that’s taking forever to finish? It could be because of technical debt piling up.
That app that keeps crashing? It might be a hiccup in the continuous integration pipeline.
To understand it better, I want you to imagine for a moment that you’re a coach for a soccer team. You’ve read all the books, you know all the rules, and you’re great at motivating your team. But you’ve never actually played soccer yourself. So when your players start talking about 'bicycle kicks' or '4-4-2 formations,' you feel slightly alien.
Sure, you can still do your job.
You can still encourage your team, plan practices, and help resolve conflicts. But there’s a whole layer of strategy and technique that you’re missing out on. You can’t offer advice on
timing that bicycle kick, and
you don’t understand why a 4-4-2 formation is the best choice for your team’s next game.
That’s like being a non-technical Scrum Master leading a technical team.
You can coach, facilitate, and motivate, but there’s a whole layer of strategy and technique that you’re missing out on. You can’t fully grasp why a 'legacy system' is dragging the team down or what 'technical debt' really means for the release timeline.
Getting a grip on these concepts means you can
talk the talk with your technical team,
you can pinpoint process-related issues faster and
you can help your team learn and improve like never before.
In this newsletter series, I will help you learn the language your team speaks with the help of a real-life case study of a team building a software product. I will give you a complete walkthrough of a standard communication method employed by most teams to discuss technical details.
Let’s get started.