Agile @ Storytel
Agile software development is by now a label getting pasted onto anything and everything. It is hard to know what it actually means and what practices and tools an organization calling themselves Agile actually apply. Still, I often get the question of whether we do Agile at Storytel.
While working as an agile coach I encountered many ways to organize and do software development. Some of them worked very well in a specific context, some were repetitions of things that have been tried for many years, but never really worked well. What they had in common was that they were all labeled Agile software development.
After years of experience, I’ve found myself moving away from the label and leaving the idealist camp. I am now firmly in the pragmatic and method agnostic camp looking up to movements like Modern agile. I have even noticed that I shy away from organizations that boast about being Agile.
Instead of labeling methods, I have come to realize that the value is in the experience created for customers. Nobody using your product cares whether you created it during a waterfall project or with a small, fast-moving team.
One of the first things I noticed at Storytel was that unlike many other software organizations we seldom talk about Agile. We don’t use the label, and we don’t argue which method is right, and which is more true to how things should be done. Instead, we follow a number of (so far unwritten) principles.
Work happens in small teams (a.k.a. crews)
Our tech department is divided into teams. The size of a team is between 25 and 6. The larger teams are working in smaller entities, called crews. Each crew is cross-functional, has a clear mission, focus on solving problems and delivering great software. As an additional challenge and benefit, all our teams (and most crews) are distributed over five tech offices in Sweden and Denmark.
Make data-driven, customer-focused decisions
There are many ways we decide which feature to build, but all of them are based on data. We focus on how what we build will benefit our customers. Sometimes we test our hypothesis using A/B testing or launch early prototypes. Finally, we follow our releases up by looking at the data to see if our hypothesis was right and consider what our next step would be. Basing decisions on customer behavior also helps developers understand and connect with our customers.
Teams are autonomous
Each team works independently. They are cross-functional meaning a team has all the competence needed to solve problems in their domain. They are able to make decisions on their own when it comes to tech stack, tools, and ways of working. That means you will find some teams running a version of Scrum, one team running a version of Kanban, and some teams running a kind of dynamic reteaming. The teams keep inspiring each other and adapting the way they work, applying the tools and methods that make sense in their context.
Ship often, discover problems early
We want to make sure that we ship software as frequently as possible to make sure we can get feedback as quickly as possible. Different domains use different tech stacks and that means they face different challenges when trying to solve this problem. Our products are released on a cadence of 1–3 weeks (depending on product and tech stack) and we try to see each release as a train. That means it leaves at a certain date with all the features that are on board at the time of departure. Teams are encouraged to ship partly done features under feature flags and use tools for A/B testing and beta programs to get quick feedback and understand if they are building the right thing.
Always improve
We believe that things always can improve. If an organization becomes stale, with the speed of change happening in the software industry, it means they are falling behind. Therefore we make an emphasis on experimenting and trying new things, learn from what did not work, and use what worked well. We have teams trying new ways of organizing work, experimenting with new technology, testing new approaches with our customers, and leveraging data to define good hypotheses.
These principles remind me of Denning’s three laws to explain what agile is:
- The law of the small team
- The law of the customer
- The law of the network
Is Storytel tech doing Agile? Are you agile? I’d say these are the wrong questions to ask. Can we improve? Can we learn new things and work smarter? YES!
Want to work with us? Storytel is growing and always interested in bringing on board skilled people. Check out our open positions or contact me directly.
