www.balki.io

Engineering Reflections

How We Light weighted Our Agile Development Process

By balki | November 17, 2016 | 0 Comment

This post was originally published by me in April 2016, while I worked as an Engineering Manager at New Relic.

When I first joined the .NET Agent engineering team at New Relic last fall, the rock solid team was already doing great work at a good pace. At the same time, though, we knew we needed to speed the delivery of critical functionality for our customers.

Just as important, we needed to make sure our stakeholders (particularly Product Management and Support) were crystal clear about which features were going to be in what release, and when that release would go live. They needed to know what we were working on at any given time so they could better guide us on what to deliver next for our customers.

We were counting on agile development practices to address these issues. But New Relic and the development team were generally resistant to adopting heavy process requirements. Here’s how we made it work.

Our goals were simple:

  • Ensure the engineering team and our stakeholders clearly understood the goals of specific projects.
  • Involve the entire team in all major decisions.

To accomplish these goals, we structured our lightweight agile process along four key best practices:

1. Continue daily standup meetings (and make sure they don’t go over 10 minutes).

2. Work in two-week sprints: The team had been doing one-week sprints, but that wasn’t long enough to ensure a meaningful release at the end.

3. Ban coding on the last day of the sprint (mostly): On the second Friday of the sprint we start the day with an organized demo for stakeholders, followed by

  • 15 minutes of sprint retrospective.
  • 60-90 minutes of combined grooming and planning. At the end of this session, we all have a pretty clear understanding of what we will work on in the next sprint.
  • A team celebration: We began this tradition with a team lunch on the last day of sprint, but plan to add more fun activities.

4. Institute creative elements to increase transparency: 

  • Declare our Sprint Goals: On the first day of a sprint, I send out a simple one-page document that clearly communicates what we plan to accomplish in the sprint. This makes the entire process more credible. (See a sample Sprint Goals document.)
  • Create Demo Artifacts: To complement the Sprint Goals document, throughout the sprint the team collects all demo-worthy artifacts in a document linked to the corresponding sprint story. This helps make our sprint-end demos more professional and accessible to stakeholders who may not be able to attend. (See a sample Demo Artifacts document.)
TAGS

0 Comments