Seven Ideas to Make Scrum More Effective for Your Team
Seven Ideas to Make Scrum More Effective for Your Team
Looking to make your team more effective at delivering value each sprint? Here are some ideas to contemplate that have worked for teams I've been a part of.
I've been practicing the agile methodology for over a decade and across several teams. The best part is that each team enjoyed its own implementation. It’s one of the beauties of scrum. It’s ripe for alteration. I took some time to sift through some of the mechanical process changes we made. A portion of changes didn’t work but here are seven that did … and might work for you.
“Sprint vision” meetings. At my last company, we hosted a half hour call one week before the next sprint was scheduled to start. It was with Product and Engineering leads. We’d discuss candidate “headlines” for the next product release at the end of the sprint. Sometimes these headlines would be exciting for customers. Sometimes they were exciting for us. Having a list of headlines (versus individual tickets) would give us guidance into how we might plan the next sprint. It worked because we needed to ensure we were bringing stories that told a cohesive story for the customer, not disparate tickets based on a prioritized backlog.
Toggle to waterfall. Wait, what? Surely, this sounds sacreligious but, in the right circumstances, it is the right thing to do. For example, we once had a project to swap out our underlying data layer. It was a huge project but there wasn’t a whole lot of variability in how we’d do it. Why have the team meet every day or do grooming every week against dev tickets we could just front load? Ultimately, the team moved much faster with just weekly check-ins. In three months, we swapped out a database system and greatly improved performance for our customers.
Pick one retro commitment. The sprint retro is possibly my favorite scrum ceremony because it is where camaraderie and culture are formed. It is also an opportunity to fine tune how we work. Most sprints, there is at least one change to our scrum process that is worth doing. However, we wouldn’t commit to all of these ideas, just one, voted upon by the team. Like your product, your team and working style should evolve each sprint.
Rename (and possibly reorganize) teams. This one is a bit silly. At one company I worked we had four teams under a lot of pressure. So, each quarter we’d have a little fun. First, we’d see what the next quarter looked like from a roadmap perspective and evaluate whether we’d perform better by reconfiguring the teams. (I wouldn’t suggest doing this hastily because you lose team camaraderie when you shuffle the teams.) Even when the team makeup remained the same, we asked the teams to come up with a new name under a new theme. Once, we used famous warriors. Another time, it was famous musical acts. It’s fun and might inject a little levity into the day-to-day.
Create an “alpha testing group”. I can’t imagine not having this construct having done it for a couple of years. Organize a group of trusted, internal users to bang on the product during the code freeze period before going out to the customers. (Ideally you’d have customers test too but this can be difficult to organize in 2-3 week sprints.) Deploy your code to a testing environment as part of the QA effort and see if your internal teammates find things you hadn’t. I had created a slack channel for the alpha testers to communicate what they would be asked to test and to track their feedback. Scrappy yet effective.
Invest in a scrappy scrum master. The scrum master role is often underestimated. While other members of the scrum team can have diverse personality traits that make them successful, you’ll want to hire/assign a scrum master who can only be described as “dogged”. Why? A hard-nosed scrum master ask tough questions to the team. A hard-nosed scrum master will leave the daily standup and knock down all the team’s blockers before the next meeting. This results in better velocity, which results in better product, which results in happier customers.
Host design kickoffs. For larger initiatives (and perhaps for atomic UX changes), host a scrum team meeting to review the overarching design for the product initiative. Design should mean two things: UX design and systems design. Ask engineering leadership to describe the systems design and ask Design to host the UX team to host the guided tour of the product mockups. While these plans may change (it’s agile after all), the larger context for the initiative will help lay out how each user story comes together to deliver something bigger and better.
These are just a few of the mechanics I’ve seen work. I imagine each scrum team has their own list like this. So, what are yours?