In October of 2020, Choozle invested in me to go to a Scrum Master Certification course through Mountain Goat Software with Mike Cohn. After taking in strategies and best practices from the course I locked myself in a room for many weeks, developing a plan to implement the concepts presented to optimize our development and provide our build teams with a good process structure going forward. Here is what happened, what I learned, and where we are today.
Jump to:
Assessing Agile Practices
We had always been a Scrum committed organization — we started lean and knew at some point we had to move towards a methodology that would scale as we grew. The agility it offers made for a great development experience, and its flexibility matched up with an AdTech industry that thrives by being flexible. Previously I trained as a Product Owner which helped me gain a valuable understanding of how to write user stories and prioritize them — but what was missing was the Scrum basics. The what, why, when, how, and who’s doing it.
I started with a few questions:
- What slows us down?
- What do we dislike about our current way of working?
- What are we doing that looks like this already?
Too Many Meetings
Like many product development organizations, we typically got a little meeting-heavy, especially around planning. Before our most recent implementation, we would gather every six weeks for a design week. It was three to five days of meetings led by Product where Development would figure out what they were building for the next six weeks. Developers often shared that they felt it was wasteful of their time, and Product Managers and Product Owners were left feeling like they were forcing something on Development that they weren’t buying into.
Our adoption of Scrum found the least amount of meeting possible for us to succeed in this agile way of development. We scheduled planning and work-time to fit our teams’ needs without overloading them with meetings.
We’ve adjusted to it be simple. Unless you’re a Monday person (said no one ever), Mondays aren’t great, and one of my developers put it best — ‘Mondays should not be reserved for critical thinking.‘ As a result, we adjusted to a two-week sprint, starting on Wednesdays instead of Mondays. It was an easy change to extend the current sprint three days, and the results were quite beneficial:
- Developers got four to five full consecutive days during the sprint to run as fast as they wanted.
- The Product team wasn’t required to work over the weekend to prepare for sprint planning on Monday morning, and the whole team was able to boot back up on planning weeks.
Tweak vs. Change
Change can be a tough word to sell people on, period. The team had done things a certain way for a long time and was seeing moderate success. So I didn’t want to come across like a power-hungry noob who just went to scrum school. Instead, I found things we could simply ‘tweak’ instead of ‘change’ — here are some examples:
- Design Week: We continued to use many of the same presentations, organization documents, and exercises in sprint planning, but transitioned some of them into tasks we could work into our sprints. In a sense, we brought the spirit of design week into every sprint.
- Retros: To streamline, we moved to a Start, Stop, Continue template so that feedback was easily translated to action items the team could own in their sprints. This allowed room for us to be honest about the team’s behaviors, rather than sharing non-specific generalizations that took time to discuss and figure out the actions or behaviors we wanted to start, stop, or continue.
- Grooming: We adjusted this activity to be the last Friday of the sprint and allowed time for a check-in. It starts with a question: Are we going to get done all the things we committed to in the sprint? Then it wraps up with traditional grooming, where the Product Owner/Manager presents the new Product Backlog items to developers to ask questions and estimate work. We call this new method Refinement.
The results of these small changes have been quite impressive — the team owns the process independently without extra guidance from me. Applying the principles of what I’ve learned, what works, and what doesn’t, the team is able to focus on answering the important questions of what, when, why, and who. It’s becoming less and less about whether we’re doing it right and much more focused on seeing the framework’s flexibility.
Scrum concepts are easy, but putting them into practice is difficult. Our success comes from the commitment, and from the support that is available from the team. When implementing Scrum you can’t do so half-heartedly, you have to embrace it fully. I’d like to thank the team for being so open to change and owning it every step of the way. And I’d like to acknowledge and thank all of those that came before me at Choozle for building the work practices and culture that allowed us to apply structure to the process and reignite our commitment to Scrum.
About the author:
