Sprints Are For Runners, Not Developers

If you’re like most developers then you’ve likely been in a sprint planning meeting or two. In a traditional Agile/Scrum setup a team will get together every week or two (depending on your sprint intervals) to go through the arduous process of selecting which stories and issues will make it from the never-ending backlog and into the next sprint. This process generally involves rituals such as: prioritizing new items in the backlog, assigning story points to each item, assigning an owner to each ticket, and ensuring that each team member has an appropriate work load for the sprint. Sounds like an effective process, don’t you think? Ya, neither do I.

The Pitfalls of Sprints

Depending on the way your organization operates, there ends up being a lot of extra time spent on Agile/Scrum rituals that don’t engage the team and don’t get everyone excited about what they’re working on. I’ve yet to meet a developer who is excited to participate in a sprint planning meeting and I’ve personally never been excited by the idea. If you’re the one leading the meeting there is a high probability that if you took a look around the room during the meeting you’d be met with a series of blank stares or anxious developers more excited to get out of the room and back to writing code.

Another challenge I’ve found with this approach is that some of the steps involved often don’t provide any real value. Let’s start with story points. In my experience developers aren’t great at estimating how much time a task will take. This leads to estimate systems like “t-shirt sizing” which are simply inaccurate. If something is important enough to the team or organization then the team is going to spend the time working on it regardless, so why add the extra step?

Another piece that can be removed are the arbitrary deadlines introduced by sprints. Imagine you’re implementing a feature in the context of a two week sprint. You’ve spent two weeks developing it and you’ve got a few days worth of work left to complete it. Now what? Do you throw it out because you didn’t finish it in the sprint? Of course not, so you add the remaining work into the next sprint. The reality is organizations don’t operate in two week intervals so your dev team doesn’t need to either.

How To Run Without Sprinting

A key ingredient that has helped us move away from sprint planning on my team at TextNow is quarterly planning. Each quarter the organization sets out goals for itself using an OKR (https://en.wikipedia.org/wiki/OKR) system. Before the start of a quarter each team lists out their of objectives and high level projects they’d like to tackle to help us move towards those objectives. There are two important components to this process.

1. Planning: Every team member is involved in the planning process. This allows for everyone on the team to voice their opinion and shape the road map, which consequentially makes it much easier for them to buy into the team’s mission for the quarter.
2. Roadmap Creation: As we plan, we lay out a roadmap of projects to tackle over the entirety of the quarter. Our roadmap creation allows us to be strategic about the next products and features we will build based on insights and objectives we’ve laid out during our planning sessions.

With our trusty roadmap in hand (metaphorically of course) we set out to start developing each project. This is generally a simple process of assigning project leaders to each project, and ensuring we have the appropriate resources available to contribute to each project. Without the regular rituals of an Agile/Scrum team we introduce a few new ones to compensate.

1. Weekly sync ups: Each Monday our team will gather around a white board that lords over our work area. On this board we have each project plotted out, and simply track high level progress against it. We’ll call out rough high level goals and strive to complete those before the following Monday.
2. Demos: A favourite ritual among developers is demoing what they’ve built. At TextNow we take this beyond the scope of one team and hold a bi-weekly demo day open to the entire organization. This time offers the developers the time to show off the cool things they’ve built, as well as give everyone in the company a sneak preview of the great things coming to our product before they hit production and become available to customers.

Crossing The Finish Line

You may have some questions at this point such as: Where are my daily stand ups? How do we track progress on tickets? How will I know if my team isn’t delivering?

These are all important questions. Depending on your team and organization it may be fitting to continue some of these rituals. For tracking tickets we use Jira with a simple Kanban set up (https://en.wikipedia.org/wiki/Kanban_(development)). Developers create their own tickets and leverage Jira’s epic system to track against projects. Daily stand ups come into play on a per project basis. With a team that’s more than a 3–4 people more often than not there will be updates given by some that are not relevant others, so if you’re leading a project for the team it is up to you if you’d like to take advantage of a daily stand up system to coordinate the project, however this ritual is completely optional.

The last question is simpler than it may seem. A good leader should have a pulse for the team and the ability to differentiate good performance from a lacking performance. This set up simply requires the leader of the team to be in tune with their team’s members, and keep communication open among the team. It’s easier than you might think to identify an issue, and if you have the right people on the team, issues will be few and far between.

I’ve found a lot of success with this process because it helps to empower our developers and stay out of their way. It might be tough to let go of the wheel a little bit at first, but the great thing about great people is that when you give them the opportunity to excel, they often surprise you with what they can achieve.