I’ll never forget when I heard the Mary question & how it got me thinking about improving my game as a Scrum Master.
"How long does it take for code to go from a developer's local machine to production?
-Mary Poppendieck
Such a simple and powerful question which will help all Scrum Masters learn what they need to measure for themselves about bringing value to the team.
But what does it actually mean?
How do you actually measure it?
And what do I do if I am not a software person?
Don’t worry, we’ve got you.
How Easily Can We Release Our Work to Customers?
This is kinda the same thing as the Mary question.
How easily can you get your work out to the people who need to see it the most?
I mean, if you think about it….
… Agile, Scrum, or just being adaptive in business – it’s about learning, isn’t it?
Are we building the right thing? How do we know?
And how do we learn about that?
And if we are going to learn about what we build, do we want to learn fast or slow?
Personally, if I have an idea that sucks, I’d like to spend the least amount of money to find out. That means we need the capability to learn faster.
So what determines a team’s ability to learn faster? Quite a few things. But in this mini-blog we are focused on the software capabilities that you need to help your team possess to be able to learn faster.
Another way to ask the question:
How Often Can We Get Our Work, Out To Production?
That’s the question you need to ask as a Scrum Master or anyone supporting teams.
Where are we with this capability?
You may not know how it’s done in terms of the process and tools involved & may think it doesn’t matter - but I can assure you, if you are helping a team improve, helping a team to get what they need to do better - this is a fundamental concept to grasp.
But before the “how,” let’s talk about the “why” - why releasing frequently matters.
Why It Matters
Faster Feedback Loop: If you’re getting work out on a regular basis (high frequency) that means that the things you build reach customers more quickly.
Rapid feedback: Now we have more of a chance to respond to issues, iterate on features, and align more closely with user needs.
Continuous Improvement: It’s a cultural thing. If we get used to frequent deployments, it puts us in continuous improvement mode. We think about how to fine-tune the process to get the work out faster and learn more quickly about what we build.
Reduced Risk: Smaller, more frequent deployments are less risky than big, infrequent releases. With each release, fewer changes are introduced, making it easier to identify and address issues.
Increased Responsiveness: A team capable of deploying frequently can quickly address critical bugs, security vulnerabilities, or other urgent issues. What customer doesn’t want that?
Enhanced Collaboration: High deployment frequency often requires close collaboration between development, operations, and QA teams. This collaboration can break down silos, leading to better communication and a more cohesive team effort. It’s a clever way to spot these structural problems and help us re-organise to do things better.
Market Competitiveness: In fast-moving industries, the ability to release updates and new features rapidly can provide a significant competitive advantage. Companies that can quickly adapt to market changes and customer needs are better positioned to stay ahead of competitors.
How Do We Know We Are “Good” at It?
You know, good at getting stuff out frequently from our local machines to production?
Define "Successful ": Decide on what constitutes a successful release to production. This might include criteria such as passing all automated tests, no critical bugs, and deployment without rollback.
Track Releases: Developers can you use tracking tools or version control systems to log each release. Many CI/CD platforms provide built-in metrics for tracking deployment frequency. You may not be the one to do it, but you can ask the team on if they have what they need to begin that conversation.
Analyse Trends: Regularly review deployment data to identify trends and patterns. Teams can look for periods of high or low deployment frequency and investigate the reasons behind these trends.
Set Goals: Based on your analysis, set realistic and achievable goals for increasing deployment frequency. Consider the capacity of your team and the complexity of your software when setting these goals. One more time, ask for help but at least now you’re aware of the concept.
What Are the “Better” Practices to Help Us Get Better at It?
Ideally we want to consider these things:
Automate Everything: Automation is key to increasing deployment frequency. Automate builds, tests, and deployments to reduce manual effort and minimise errors.
Adopt CI/CD: Implement Continuous Integration and Continuous Delivery (CI/CD) practices to streamline the process of integrating code changes and deploying them to production.
Invest in Testing: Ensure comprehensive automated testing coverage, including unit tests, integration tests, and end-to-end tests. This reduces the risk of deploying faulty code.
Use Feature Flags: Feature flags allow us to deploy code to production without immediately activating new features. This enables safer, more frequent releases and gradual rollouts.
Optimise Pipelines: we can continuously monitor and optimise our CI/CD pipelines for performance. Reduce bottlenecks and improve the speed of builds and deployments.
Foster a DevOps Culture: Encourage collaboration between development, operations, and QA teams. A DevOps culture emphasises shared responsibility for delivering and maintaining software.
Monitor and Respond: Implement robust monitoring and logging to quickly detect and respond to issues in production. This ensures that frequent deployments do not compromise system stability.
Yeah, but How Do I Help the Team Get Better at It if I’m Not a “Techie?”
You have the first part now: a new awareness of why we want to release early and often, what practices we could follow, and how a team could measure its ability to do these things. It’s a great start & perhaps once you digest it, it’s more than enough for this topic to help.
Equipped with this awareness, we can now do the following:
Collaboration with Champions: Work closely with developers who advocate for better deployment practices to understand their needs and support their initiatives.
Data Gathering: Collect and analyse data to build a compelling case for improvement. Maybe the team want to do the above things but aren’t gifted the time, tools or support to do it.
Educating Management: Dove tailing from the last point, present findings to management, explaining the benefits of frequent deployments and the necessity of investing time and energy into building and refining CI/CD pipelines and other practices.
Remember !
Scrum Masters need to help the team do things “better”. A big part of that is helping the team learn faster about what they are building from the people who count the most: the customer!
The team’s capability to deliver value swiftly and reliably is huge. By focusing on helping teams strengthen this capability through automation, CI/CD practices, and a strong DevOps culture, teams can achieve faster feedback, continuous improvement, and a competitive edge in the market. Ask questions, ask for help, capture the data, support the team to get what they need and keep going!
Haters will say this is photoshopped
The Mentor club for Scrum Masters opens back up in July
I love mentoring and have been doing this for a while, helping people from all walks of life get their first job, as well as fine-tuning skills for those who are already experienced.
It’s always a question of creating time, so due to popular demand, I’ll be opening the doors again on July 1st:
Access to Real-Time Experts: You'll have access to real-time experts like myself.
Support for Interviews: Learn how to secure an interview and develop the skills to excel in it.
Situational Questions & Answers: Get guidance on situational questions, from team dynamics to product-related queries.
Extensive Resource Archive: Gain access to a large archive of resources covering methods, frameworks, and techniques for Agile and technology teams.
Career Growth Focus: Learn how to focus on skills rather than roles to ensure your career remains attractive in the industry.
If you’re interested in joining us, you can message me here to reserve your spot.
It’s the cost of buying us lunch once a month—we're a pretty cheap date at $15 :)
