Why we built Sprintlio
Our team has seen it all when it comes to Agile.
Scrum. Modern. Agile-ish. Kanban. Lean. Waterfall. We know you have too. Agile as a concept is well understood and spreading rapidly. From software development to project management to manufacturing to finance to marketing. It makes sense. Continuous process improvement, improved communication, maximum productivity, and enhanced flexibility would benefit any team. Every team has their own nuances about which Agile ceremonies are most important but we’ve always felt that the agile retrospective is critical. It’s our belief that if your team doesn’t take the time between sprints, releases, iterations, or projects to reflect on learnings, identify opportunities to improve, and be accountable for those next steps — it defeats the purpose of being Agile.
There are over 100,000 software and IT companies in the US alone and according to a the 2017 State of Agile Report by VersionOne, 83% of respondents run agile retrospectives with their teams. If you consider that the average team runs biweekly sprints and estimate how many teams run within each company, you get anywhere between 2–100 million agile retrospectives each year for the software and IT industry in the US alone — that’s a lot of missed opportunities.
Like most teams, our previous teams ran agile retrospectives huddled around a whiteboard on a biweekly basis. Every other Thursday we would gather around the whiteboard, spend the first 5–10 minutes frantically populating it with recent topics and +1’s. We were setting ourselves up for failure every time, and we didn’t even know it. Finally, after hundreds of agile retrospectives across our careers and surveying just as many engineering leaders, product managers, scrum masters, developers, and designers, we identified a few key issues that persisted across all agile retrospectives. Big or small. Remote or co-located. Technical or process-oriented. All of them.
1. Weak Conversation Quality 👎
Since the majority of teams use whiteboards, they fall victim to recency bias. You can’t expect your team to remember everything that happened over the course of a couple weeks or several months. Why make it so difficult?
For the velocity-conscious teams, you lose 5–10 minutes waiting for your team to write things down every meeting. In a team of 10, you’re losing about 43 hours of output a year.
If the discussion ever goes beyond what could fit on a sticky note, the facilitator won’t be able to effectively communicate the topic in detail. No attachments, visuals, examples, code snippets, links — nothing.
And if you’re a distributed team, good luck trying to get participation on a whiteboard through a conference call. As soon as you introduce the concept of distributed teams, running agile retrospectives become infinitely more complex.
2. Lack of Accountability 👀
In our initial survey, we found that action items only get completed about 15% — 20% of the time. How do you expect to benefit from retros at that rate?
What was happening was always one of three things:
- The team would unfairly assign a single person to make sure that everyone was held accountable for their next steps (usually the scrum master or product manager — and their job responsibilities don’t include running after people).
- The team would take a photo or copy and paste the text into Slack or Confluence and never see it again (until they organically came back next retro).
- The whiteboard would get erased and the team would immediately forget.
Why carve out time to run the meeting in the first place? Discussion without action doesn’t improve productivity. The effects on team morale of not completing action items compound over time and rip teams apart from the inside by impairing communication, halting collaboration, and stunting effectiveness.
3. Team Health Score 🚨
When we asked product owners, product managers, scrum masters, agile coaches, team leaders, and anyone who facilitated a retrospective, how they determined their team’s participation, accountability, or sentiment, we always drew a blank. Despite the fact that they all were hungry for that kind of information, not one of them was able to provide empirical data surrounding their retros.
This information is key to measuring team health. Agile retrospectives without a balanced perspective are not useful. Everyone needs to be engaged. Everyone needs to be heard. Everyone needs to be accountable. Providing teams with great detail into participation, task completion, and sentiment scores allows them to identify areas of improvement and ultimately solve them quicker.
That’s why we built Sprintlio. We’ve identified a key pain in a process that we highly value, but received little benefit from. It’s a key business process growing rapidly that’s already run millions of times by millions of teams and we felt we were the right team to address the issues.
Sprintlio has been used by more than 50 teams throughout our beta. In this process we have identified exactly what teams like and dislike about running agile retrospectives and how to make that process as effective as possible. But this is just the beginning, we’re looking for more teams to join us in this mission to make agile retrospectives more accountable, more engaging, and more beneficial to every team in the world.
