Work Like a Unicorn: Understanding the Real Value of Agile Sprints

This was originally posted in HackerNoon on May 22, 2019.

I want to share my thoughts on a topic that has been a real pain point for teams trying to practice true Agile software development in a business that isn’t necessarily on the same page with everything which it entails.If you’ve been working with an Agile framework, or even if you haven’t, you’re probably familiar with the concept of a “sprint,” a push to deliver working software in time-boxed iterations, typically one or two weeks. But what often gets the focus about sprints is something different, as pointed out by the insightful John Cutler (@johncutlefish) on Twitter.

The value of “sprints” is largely misunderstood / glossed over.

Sprints are meant to be a *healthy* (and effective) forcing function / enabling constraint ... not a way to drive teams/individuals...not a hamster wheel ... not “breaking up a project” (1/n)— John Cutler (@johncutlefish) April 20, 2019

As John points out, if your organization misunderstands the purpose and value of a sprint, then you’re left trapped on a hamster wheel, endlessly spinning out feature after feature according to some pre-determined roadmap and with the feeling that you're never going fast enough. Teams in these environments often feel like the beginning and end of sprints are meaningless, procedural steps, and they rarely feel a sense of accomplishment at what they've achieved.The tell-tale sign of an organization that misunderstands the value of sprints is a team using language around “failed” sprints. As John puts it, he often hears from teams something along the lines of, “Yeah, we keep missing our story point goal, it is so frustrating. And there are always loose end stories. Our morale is super low.” If this sounds familiar, the solution is not to work harder.

Why There’s No Such Thing as a “Failed” Sprint

When we talk about “failed sprints,” the key thing to realize is that the sprint actually still did its job, even if it didn’t give you the results you were looking for. It sent the team a signal that something about what they were doing was not working. This idea of a failed sprint is a key indicator that the organization is approaching sprints as a vessel for delivery, instead of for discovery, inspection, and adaptation. [caption id="attachment_3771" align="aligncenter" width="768"]

Sprints are a forcing function for re-evaluating what's most important.[/caption]Instead, it’s important to understand that the real value of a sprint is the frequent integration of all aspects of the product work.

The Real Problem With Sprints

The problem here is really how sprints fit into the patterns and habits that an organization has developed over time. As humans, and especially as groups of humans, we really hate unknowns. Rather than wait to see what we learn from each sprint and then adjusting accordingly, it makes us feel much more comfortable to chunk out work into “sprints” while sticking to an overall, longer-term plan that we've agreed on ahead of time. We want to feel like we know where we’re headed, even though the very heart of Agile is admitting that probably don't know the best way to do things yet.Well-meaning teams that are trying to fit their agile development plans into an organization that is still managing with a project mindset often give up the very principles that the Agile framework was built around. They might call what they are doing Agile, but it is something else entirely.

Working at a Unicorn

I'd first read the theory behind the Agile software development principles while I was working in a startup for the first time in the late 2000s. For me, the key has always been about the frequency of “inspection and adaptation.” As a former chemical engineer, it made intuitive sense to me as a process control system: a process for making sure things don't spiral out of control, with the worst case scenario (in chemical engineering) being a plant blowing up.So I did my best to implement and advocate for Agile development over my years in early-stage startup teams. Since the whole company was so small that it was only one team, I got to practice first in an environment without a lot of the factors outside of a team that can make agile hard to do. So when I was hired by MediaMath in 2012, I was excited to join a company that was already practicing Agile during a high-growth phase with many teams of engineers. I wanted to see how it worked at that scale.[caption id="attachment_3772" align="aligncenter" width="768"]

I wanted to see how Agile worked on a team of hundreds.[/caption]And when command-and-control-minded leaders asked me to do non-Agile things, like push the team to commit to more each sprint, or plan out which stories we'd do several sprints in advance, I explained that their request went against the core principles of Agile. To their credit, they accepted that and didn't ask me again. Because I'd worked in government before tech, I attributed this adaptive response and openness to new ways of working to the culture of tech startups.During the three amazing high-growth years that I worked at MediaMath, my product teams practiced continuous product discovery and Agile software development while redesigning the user experience, beginning to codify our design systems, executing a tech platform migration, and launching new capabilities for our core users. It was only after I left MediaMath, when I started working with more people who came to tech startups from larger companies and more traditional backgrounds, that I realized just how unique the trust to practice agile at MediaMath was, even within the tech world. Last year when MediaMath raised a new round of funding that put its valuation north of $1 Billion, I understood it to be a long overdue recognition of MediaMath as the unicorn that I'd long known it was.

The Challenges of Truly Practicing Agile

The truth about Agile is that it's not an easy way to work. Nearly the entirety of our educational and professional systems are built around teaching people to follow clear paths, with lots of planning, assumptions of certainty, and standardization. The world today, with its rapid technological change and hyper-connected population, changes extremely fast. The infrastructure of software development changes incredibly fast too. As a profession, we're just beginning to develop repeatable processes that work in this context.For most people, that makes for an extremely uncomfortable situation at work. They feel like they’re flying blind, so they fall back on what they know. They focus on shipping features, pushing for longer hours, assuming more is better, fitting sprints into a bigger schedule without taking the time to consider what they’re learning and how that might change things down the road.This leaves an incredible opportunity for those who are curious and willing to get uncomfortable. If you can learn how to work like the unicorns, regardless of what pressures you feel from everyone around you to revert to comfort, you can create unique products and find untapped market opportunities. It's uncomfortable work. But the results are incredible.[caption id="attachment_3776" align="aligncenter" width="768"]

The truth about Agile is that it's not an easy way to work.[/caption][bctt tweet="If you can learn how to work like the unicorns, regardless of what pressures you feel from everyone around you to revert to comfort, you can create unique products and find untapped market opportunities." username="h2rproductsci"]At H2R Product Science, I’m here to help people who want to make that journey. I've got a workshop coming up on June 13-14 in NYC that will help practitioners up their game: Data-Driven Product Decisions: How to Kill a Bad Idea or Advocate for a Great One.You can also connect with me by subscribing to the Product Science Journal or listening to the Product Science Podcast. Really, please reach out if you want to work with someone who understands not just what Agile is, but why we do it. Let's build an army of people who want to build great tech products that do good for the world, no matter how hard and uncomfortable the journey is.