Technical Literacy for Scrum Masters - Part 1

Making sense of your team's technical conversation during Kickoff discussions 1 and 2.

Oct 29, 2023

👋 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.

First Comes the Right Mindset

I want you to adopt the right mindset from the get-go.

You will need this mindset after you become aware of the common tech lingo your team employs. This will make sure you stay true to the value “you” bring to your team as a “Scrum Master.”

Remember! You are NOT supposed to:

Advise your team on technical details.
Help them write code
Make Architectural Decisions
Dictate Technical Practices
Take Ownership of Technical Problems
Act as a Go-Between for Technical Communication

Your expertise as a Scrum Master lies in facilitation, coaching, and process improvement. Understanding the technical side is beneficial, no doubt, but for you, it’s crucial to maintain “your role” and let the developers handle the technicalities.

This balance is what will make you an exceptional Scrum Master.

Let’s use an example to understand this better.

Suppose your development team uses Git, a widely used version control system, for their project. During meetings, they frequently discuss terms like:

"merge conflicts,"
"branches," and
"pull requests"

Without Technical Understanding, these discussions might seem confusing. You notice that when someone mentions a “merge conflict,” the mood in the room changes, but you’re not sure why or how to help.

With Technical Understanding, you know that:

"branches" are separate lines of code development,
"merge conflicts" happen when “code” changes can't be automatically combined, and
"pull requests" are used to propose “code” changes and have them reviewed by team members before they are merged into the main branch of code.

How to use this knowledge as a Scrum Master?

By having a basic understanding of these terms, you will be able to:

ensure everyone understands the issue. You’re not explaining the technical details, but you’re making sure everyone is on the same page.
recognize that merge conflicts can cause delays and frustration. So, you may encourage practices to minimize them. You’re not solving the merge conflicts yourself, but you’re helping the team address this challenge proactively.
organize sessions for developers where they share Git best practices. You’re not teaching Git, but you’re facilitating an opportunity for the team to learn from each other.
use your understanding of Git challenges to guide retrospectives, helping the team reflect on their practices and find ways to improve.
promote the use of pull requests and code reviews as learning and collaboration opportunities without dictating how these should be conducted.

This way, your technical knowledge enhances your ability to facilitate, coach, and support the team while you still maintain your role as a Scrum Master and let the team handle the technical details.

Alright!

With the right mindset in place, let me give you a quick introduction to the case study we will be using throughout this newsletter series.

Case Study - “iFoodTruck”

Disclaimer: This case study is inspired by a real app development project I was a part of. All the names and actual functionality are changed to maintain confidentiality.

Introduction to iFoodTruck:

We will follow the journey of a team as they work on launching “iFoodTruck,” a mobile app that will help connect hungry users with local food trucks. The app simplifies the process of finding street food and also provides an easy-to-use platform for ordering.

Team interactions and meetings:

My aim is to keep it simple enough for everyone to understand.

We will follow a common (used by most teams) but a major sequence of meetings and team interactions listed below.

iFoodTruck app team uses these interactions/meetings to discuss various technical details throughout the project from Kickoff to their first Release.

The Kickoff meeting
Initial backlog creation meeting
First Sprint Planning meeting
Daily Scrums
Review
Retrospective
Release

The newsletter series is divided into several different posts.

Each post will cover one single team interaction (or parts of it if longer), explaining in detail the technical conversations that take place during these meetings.

This post covers the first 2 discussions in the “Kickoff” meeting as described below.

The Kickoff

At the very beginning, the team gathers for a Kickoff meeting. Here, they discuss the big picture of what the "iFoodTruck" app should be.

In this meeting, the team sets the stage for the,

project's direction,
aligning stakeholders and
making important foundational decisions.

A typical kickoff meeting is divided into 6 major discussions:

Vision & Objective Alignment Discussion → covered in this post
Technical Deep Dive → covered in this post
Preliminary Design Discussion
Tech Stack Discussion
Risk Assessment
Process (Scrum, Agile) Discussion

Note: Your team may not follow the exact same sequence with the same tools, but the conversations that happen during these discussions are more or less the same.

Let’s explore these discussions one at a time.

1. Product Vision and Goals Discussion

We all know this one.

This is where the Product Owner or Product Manager paints the picture of what they want to achieve with the 'iFoodTruck' app.

Let’s say their Vision is:

'To revolutionize the street food experience, making it accessible, enjoyable, and convenient for foodies, while empowering local food truck owners to grow their business and reach more customers.'

This Vision “triggers” the initial conversations to make 7 crucial technology-based decisions:

Target Platforms: Product Owner introduces "iFoodTruck" as a mobile-first application. The team discusses whether the app will be developed for iOS, Android, or both. This decision impacts the technical stack (discussed later in the series) and the skills required from the development team.
User Personas: The team discusses different user personas to tailor the app's design and features. Product Owner says the app is aimed at urban millennials.
UX and Design: The vision emphasizes an ‘accessible, enjoyable, and convenient’ experience. The team discusses the need for a user-centric design approach, possibly involving user research and prototyping.
Scalability: Given the goal to empower ‘local food truck owners to grow their business,’ the team talks about designing a scalable system that can handle growth in both user base and features.
Integration with External Services: The app might need to integrate with mapping services, payment gateways, or other third-party APIs. The team explores potential technical partnerships and integrations required to fulfill the vision.
Data Security and Privacy: As the app involves user data and possibly payment information, the team highlights the importance of robust data security and privacy measures.
Accessibility: Ensuring the app is accessible to users with disabilities is a key part of making it ‘accessible’ in the true sense of the word. The team plans to adhere to accessibility standards and best practices.

This discussion is not about dictating technical decisions but about understanding how technical considerations support the overarching Vision of the product.

2. Technical Deep Dive

This is usually the 2nd conversation, followed by the conversation on Product Vision. This is really important because it ensures that every team member understands the technology and architecture that will be used during the development process.

Your team also uses this discussion to identify any potential roadblocks early on.

People needed for this discussion:

Lead Developers: They bring in-depth knowledge of different technologies and architectures to write the code.
Architects: If available, they provide a high-level view of how different components should interact, more like an outline for the overall code.
DevOps Engineers: Share insights on deployment, continuous integration, and infrastructure.
QA Leads: Highlight testing requirements and potential challenges from a quality perspective.
Product Owner: Provides context on how technical decisions impact the product vision and user experience.
Scrum Master: Facilitates the discussion and ensures everyone is heard.

Let’s go a little deeper into definitions.

2.1 Architects vs Software Developer

To understand this difference, let’s use the example of building a house. These two roles map directly to the roles of a House Architect and a Builder.

Just like how a House Architect designs a beautiful and structurally sound house, a Software Architect ensures that the app's architecture is

scalable,
maintainable, and
aligns with the business goals.

The Builder brings the House Architect’s design to life. The builder builds the house, similar to a Software Developer who implements the app’s features by writing the actual code according to the Software Architect’s design.

Further reading: Software Architect vs Software Engineer

2.2 What are the “different components” that the Architect provides the high-level view of?

By “different components,” your team means “different independent parts of the code” written for the app. Also called different modules, these parts together make up the entire app.

Each of these “components” has a specific role or function, and they interact with each other to deliver the full functionality of the application.

For example, in “iFoodTruck” app, we have the following components or parts:

User Management Service:
- Role: Handles user registration, authentication, and profile management.
- Interactions: Communicates with the Database to store and retrieve user information; interacts with the Notification Service to send welcome emails or password reset links.
Food Truck Data Service:
- Role: Manages information related to food trucks, including menus, locations, and reviews.
- Interactions: Interacts with the Database to store and fetch food truck data; communicates with the User Management Service to link reviews to specific users.
Order Processing Service:
- Role: Handles the placing of orders, payment transactions, and order history.
- Interactions: Communicates with the Payment Gateway for transactions; interacts with the User Management Service to associate orders with user accounts; interacts with the Food Truck Data Service to fetch menu details for orders.
Notification Service:
- Role: Manages sending notifications, emails, and alerts to users.
- Interactions: Interacts with the User Management Service to fetch user contact information.
Database:
- Role: Stores all data related to users, food trucks, orders, etc.
- Interactions: Interacts with almost all services for data storage and retrieval.
Payment Gateway:
- Role: Handles payment transactions securely.
- Interactions: Communicates with the Order Processing Service to complete transactions.
Search and Recommendation Service:
- Role: Provides search functionality and personalized recommendations to users.
- Interactions: Interacts with the Food Truck Data Service to fetch and index food truck information; communicates with the User Management Service to personalize recommendations based on user preferences.
API Gateway:
- Role: Serves as the entry point for external requests, routing them to the appropriate services.
- Interactions: Communicates with all services to route requests and aggregate responses.
Load Balancer:
- Role: Distributes incoming traffic across multiple servers (computers) to ensure no single server is overwhelmed, improving the application's scalability and reliability.
- Interactions: Works at the network level to distribute requests.
Monitoring and Logging Service:
- Role: Monitors the health of all components, logs errors, and provides alerts for any issues.
- Interactions: Interact with all components to collect logs and performance metrics.

2.3 Software Development vs Deployment

For in-depth information watch the video below:

In simple words:

Software Development is designing and writing the code.

Software Deployment is making that code available to be used as an app by the end user.

The Conversation Between Techies

During the "Technical Deep Dive", the team engages in a detailed conversation as follows.

1. Team starts with Architecture:

The Technical Deep Dive starts with the “Architect” talking about “microservices.”

A microservice is the same as the “components” or “different but independent parts of the overall code” as described above. This independence allows parts of the app to scale individually. The Architect describes how these components will interact with each other (see above).

microservices = components = parts = services

It’s all the same thing, made just to confuse the non-techies.

2. Team talks about Deployment:

The conversation then turns towards “deployment.” How will the team make the code available to the end user?

They discuss various cloud providers like Microsoft Azure or Amazon’s AWS. The developers mention EC2 for computing capacity and S3 for storage. The team also considers serverless architecture using AWS Lambda.

EC2, S3 and AWS Lambda are different features of Amazon’s AWS cloud and help speed up things in a certain way.

3. The team talks about the app’s Scalability:

The backend team brings up load balancing using AWS's Elastic Load Balancer. The term database sharding is mentioned to handle vast amounts of user data.

4. The team talks about the app’s Security:

The team debates using OAuth for authentication. They also discuss SSL/TLS for encrypting data between the app and the server.

Let's investigate some of the tech terms used in this conversation.

Scalability

Scalability is all about the app’s ability to handle growth, whether it's more users, more transactions, or more data.

What is AWS's Elastic Load Balancer?

It is a feature of the AWS cloud.

Imagine you have a team of cashiers in a grocery store. As more customers come in, the manager (Load Balancer) directs them to the cashiers so that no single cashier is overwhelmed, and the lines move quickly. AWS's Elastic Load Balancer does this for "iFoodTruck,” directing user requests to different servers (computers) to ensure quick responses, even during busy times.

What is database sharding?

The word “Shard” means “a small part of a whole. “

Let’s say you have a giant ledger book with customer details. Now, if you have to find a single name in that ledger, it may take a long time. So, you decide to split the ledger into smaller books, each for a specific letter of the alphabet. Now, if you want to find a customer whose last name starts with 'B,’ you only need to look in one small book, not the giant ledger. Database sharding is like creating those smaller books for "iFoodTruck,” making it quicker to find and store user data.

Security

Security is about protecting the app, its data, and its users from any potential harm or unauthorized access.

What is OAuth?

This is the app’s gatekeeper that checks the “password” and allows entry.

Imagine you have a VIP lounge at a club. To enter, you need a special pass. OAuth is like that special pass for "iFoodTruck.” When users want to access their account or perform a secure action, OAuth ensures they are who they say they are, granting them access only if they have the right pass.

What is SSL/TLS for Data Encryption?

This is like a secure, private tunnel between the "iFoodTruck" app on your phone and the AWS servers (computers) where all the data is stored.

When you send a message through this tunnel, it’s scrambled up so that even if someone managed to sneak a peek, all they would see is gibberish. Only the app and the server know how to unscramble the message, ensuring that your data (like passwords or payment information) stays private and secure.

Resource on SSL/TSL