The Catalyst for Agile Development: Sprint Retrospective

By now, everyone in software has heard of agile software development, and for the most part about scrum. Almost everyone, at some point, has worked on a team who has done agile with varying degrees of success. About half the companies I know have, quite frankly, implemented agile completely wrong and it has made their process even worse. The other half have used it with some varying degrees of success, but rarely to the degree as the “mythical teams” whose productivity elevated to a whole new level.

DDM uses agile and scrum, so when I joined and started managing the Deseret News team we had our agile process: sprints, estimations, standups, planning sessions, etc. It worked well for the most part, but we still struggled as a team to find that next level of productivity. It always felt like we were missing something, so we’d shuffle things around. One week sprints to two week sprints, which day to hold the meetings, who was involved in what, etc. But no matter what we did it felt like we were just shuffling things around. We couldn’t achieve that next level of productivity.

On the same floor as us was another team: the Deseret Connect (DC) team. They were extremely productive with their agile process. Stories were defined, prioritized in their backlog, and finished in a very timely manner. The amount of work they were accomplishing was incredible. I would sit in my office wondering how they pulled it off. They did pretty much the same things we did, so I chalked it up to the differences between the projects and that we just naturally had a more chaotic environment.

As december rolled around, and we were preparing for a new year, we decided to completely revisit our process and revamp our agile process again. Our Product Director used to also be the scrum master, but we found it was very hard to manage the demands of the product as well as manage the process. So Steve Ostermiller, the project manager for the successful Deseret Connect team, joined our team with the sole purpose of helping manage our process. This allowed our product manager Mike to solely focus on our backlog and definition, and Steve focus solely on how the process was working.

Steve brought with him a meeting outline that we would follow for our semi-weekly sprint planning sessions. On it he had an item called “Previous Sprint Retrospective”, which I hadn’t heard of before. It seemed so straight forward it was almost embarrassing to think you needed to spell it out. It asked three simple questions:

• What went well?
• What we’d like to change
• How we’ll implement that change

So in our first new sprint planning meeting, we asked ourselves these three questions and wrote down a summary of our answers:

• What went well:
  • Backlog/Icebox organized!
• What we’d like to change:
  • Coordinating emergencies
  • Better & more timely definition prior to Sprint start
• How we’ll implement that change:
  • Coordinating emergencies
    • Designate point person (product manager) for all requests to come through
    • Proactively coordinate with [Ad Ops] before Sprints start
  • Definitions
    • Give Christian and Mike time over the next couple of weeks to define & prioritize the Icebox

It was nothing earth shattering, our icebox was a mess and we would get interrupted during the week by Ad Operations with last minute requests. So we wanted to work on these things. We continued every two weeks in our sprint planning meeting to reflect on the previous sprint in our retrospective:

What went well:

• Kept Gary & David more focused on daily basis

• SoftServe backlog increased, with fewer late nights for Christian

What we’d like to change:

• Get stories broken down, especially on mobile site

• Chores list should be in Pivotal

• Streamline daily standups

How we’ll implement that change:

• Chris has the task to define mobile stories

• Justin convert “Christian List” to chores in Pivotal

• Justin consider with SoftServe a time for entire team to be at standups (9:00/10:30?)

Again, nothing ground breaking, just a list of things that went well and didn’t go well, and what we wanted to change. We’d look at the previous sprint’s list and see how well we did on the things we set out to change to make sure we did them. Week after week, we’d set aside this time to revise the process and see what we wanted to change.

Heres the thing: it worked.

It worked extremely well.

It has been 10 sprints (so 20 weeks) since we started this new methodology and we’ve seen incredible improvement:

We’ve doubled our velocity as a team. In hindsight, it seems so obvious: we started iterating over our process, not just our code.

We would find more things to change and modify in our process. When we started this process, we were tackling big problems like a backlog and tasks that lacked definition. Once those were fixed, we started to notice other things to help the process go along. However, these things to change would never had been noticed if we weren’t regularly iterating over our process.

It’s not just our velocity that has increased: we’re hitting our deadlines much better. We’re able to make decisions about features much more confidently. When a new feature comes in, we can estimate it’s impact on our deadlines and decide what course of action to take.

What is even more crazy is these last 10 weeks have been extremely disruptive for our team: our senior developer, who had 10 years of legacy knowledge, left our team for another job. Another of our in-house developers had to take extensive time off to help with a family crisis. For several sprints we were running with 60% of our team. However, we had our solid process, and we followed it. We came out releasing a major project on-time. So when our team got back to 100%, our velocity started to take off even more.

I truly believe the Retrospective really unlocked the potential of agile development: We went from shuffling around our process to iterating over our process. What kills me is every time I’ve heard someone talk about the agile process, I’ve never heard anything about doing a “retrospective” before. I’ve heard about estimations, backlogs, sprints, velocity, yet the central principle, the very catalyst that can take whole agile process to the next level, seems to never get any attention.

So if you’re not doing a retrospective, start doing one. If you are, start sharing it with others. It has been the catalyst in our team finding it’s next level of productivity, and has help us solidify our process into a well-oiled machine.