In 2001 when 17 developers met up in the Wasatch mountains of Utah to discuss how to improve the way they build software products, I doubt they imagined that in 20 years' time a community of neither software developers nor product builders would be so passionately debating their work. Yet, here were are, and hardly a week goes by without an article, slack question, or more articles debating the theory and practices of agile analytics.
Whether and how we apply agile ideas to data is perhaps so divisive because it seems to elicit bigger, more existential questions about who we are as data practitioners: What truly is our role — to answer questions or enable others to answer for themselves? Is data a product, a service, or something else? Are business users our partners or our users? And how should we best work with them?
These questions are made all the more urgent with the arrival of technologies and theories (e.g. metric layers, and the last mile of analytics) that promise to change our data stack, and ways of working. As we move into this new era, it’s high time we decided which agile concepts we take with us, and which we leave behind.
In the last 20 years, the reputation of agile has grown from a fringe movement to what one of its founders calls an “industrial complex”. The promise of better organization, collaboration, and results has lured nearly every team across every industry to experiment with agile methodologies.
In 2017, my data team in a large tech company finally joined the fray and transitioned into an “agile analytics” team. Namely, we began using:
Personally, the first two had very little impact on my life besides making me jealous of the cooler projects other people on the team were working on. Ultimately, my work was between me and the business; it would have been more useful for me to talk to them every day.
Ironically, it was the third implementation of agile, requirements gathering, that made that impossible. With a more thorough scoping process, we were front-loading all interactions with the business in an effort to minimize iterations and changes. The clarity made us feel more in control, but really we were just separating ourselves further from our partners.
Largely, this is the way I see data teams embracing agile today. Kanban boards help teams stay organized. User stories give a framework to turn vague questions into fully scoped projects. While these, and other agile methodologies can improve organization and clarity, we must also acknowledge that this comes at a cost: an ever-expanding divide between us and our business partners.
It raises two questions:
Agile is now best identified by its industrialized processes, and corporate jargon, but in the beginning, it had one simple goal: build better software, faster.
The four key values to enable this vision were:
The true spirit of agile is both distinct and far more compelling than the processes we use to interact with it today.
At its core, the agile methodology was about taking something inherently frustrating about the way products were built — rapidly changing requirements — and turning it into a competitive advantage.
You can imagine how easy it would have been for these software developers to say “Hey folks, we’re sick of our work becoming obsolete every month when you tell us we actually need this feature, not that one, so from now on you have to validate requirements and scopes ruthlessly before we do any development.”
But crucially, they recognized that their ability to pivot technology quickly was the key to building great products faster than your competition. So they focused on creating a way of working that enabled them not only to pivot their code, but also to communicate with the product team, and users more quickly.
This is the true spirit of agile, and it has a lot more to teach us about how we use data today, and in the future.
To apply the spirit of agile to the data context, we must first consider how we are similar and different from our software developer cousins.
The most striking difference between what we do and what software developers do is in our end products. In software, the goal is to get to a product that the end-user loves. In data, our goal is to help people make a decision they trust, and the journey the user takes to get there can be just as important as the end result.
Most commonly we see this manifested in how we tell stories with our data. We use notebooks to capture context and process, and presentations to guide users to an understanding. It’s in this process that we establish trust, turn charts into insights, and make our data valuable.
This is also the driver behind one of the greatest pains of our work: the follow-up questions, and ad-hoc requests.
These questions and requests come from a place of curiosity and represent a desire to have that same intimate understanding of data that we get in crafted data stories. And yet, in practice, we try to eliminate these questions with processes that front-load requirements gathering and tools that have made no room for this way of working.
Ignoring this crucial difference between data and software products can (and has) led us down the wrong path to agile analytics.
To apply the spirit of agile to the world of analytics, we should ask ourselves a similar question to that of the 17 agile founders:
What if we took something inherently frustrating about working in analytics today — ever-evolving questions from the business — and turned it into an advantage? And what if we did that in a way that brought us closer to our business partners, not further away?
I certainly don’t pretend to have all of the answers, but in the spirit of Anne Lamott’s Shitty First Draft idea, I’ve made what is hopefully the first of many iterations of what might be required to answer that question:
Much like the original agile 17, I know I cannot hope to solve this on my own, and we as an analytics community must debate this and find a solution together. You can join in the debate here, and I hope to share more thoughts on this topic as ideas evolve on our More than numbers newsletter.
