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.