Jan 22, 2016

Achieving Continuous Improvement with Scrum

Posted by Aaron Price

In my previous post, we took an academic look at how Kepware’s development teams leverage the Scrum framework to continuously improve their processes. Today, we’re going to take a deeper dive into what that looks like in practical terms, using one specific team called “Coyote” as an example.

Sprint reviews provide the most efficient way for teams Kepware Engineering Team Meetingto get real-time, face-to-face feedback on their work from their project stakeholders and company peers. Our Coyote team noticed that discussions in their sprint reviews were devolving into lengthy, highly-technical conversations between Coyote team members and the Architecture Review Team (who help teams optimize their technical approaches). The questions were primarily about how they approached their work. Feedback is great—it’s the lifeblood of Scrum—but these conversations posed three problems:

  1. They were only relevant to a few attendees
  2. They were time-consuming, and left little time for other topics
  3. The resulting feedback lead to rework

These issues bubbled up during one of Coyote’s sprint retrospectives, with the conversation among the team going something like:

"Most of the attendees aren’t engaged in these in-depth architecture discussions. People are tuning out."
"Yes, but those conversations are crucial!"
"It sure would have been nice if we’d had that conversation before the sprint review."

From this discussion, the following experiment emerged: Team Coyote will hold a weekly meeting with the Architecture Review Team so that they can get their input mid-sprintwhile still doing the work.

This simple experiment allowed Coyote to get feedback when they needed it. At the same time, it made their sprint reviews more efficient and enabled discussions to occur that engaged a larger audience. Furthermore, other teams noticed the benefits of these architecture reviews, and have since adopted the practice. This type of organic cross-pollination between teams is exactly what we hope to see in Scrum!

It's also worth noting that this was one experiment by one team. Every team has an opportunity to create a new experiment after each sprint during their retrospective. We currently have 10 teams using the Agile process at Kepware, but that number is growing. Each team leverages retrospectives and experiments to continuously improve. This amounts to not only our teams iterating on themselves, but on our Engineering department as a whole—enabling us to find the best ways to work together and create the best products as efficiently as we can to continue delighting our customers.

What's Your Process?

Whatever you do, how do you try to improve your process? I'd love to hear your stories in the comments!