As with a lot of software startups, Charli uses an iterative agile approach to development. But what if that isn’t fast enough for a fast-growing startup? 🚀
Many folks have signalled the death of Agile…and mercilessly berated it before. There are plenty of online discussions around the relevancy of agile (see just a small excerpt of this via r/programming)
Despite the title of this newsletter, this is not an indictment of Agile. Just some thoughts on why and how to toss it out 🤾♀️ (at least momentarily) to achieve some big goals.
We discovered that our Agile process wasn’t able to keep up with the fast pace we found ourselves in while trying to build on our market opportunity. Agile is a nicely structured process for software development and we’ve been highly disciplined and successful in using it for our own software here at Charli. We managed to get into a very comfortable 😌 2-week cadence of building and releasing functionality. And enjoying the structure that the team put in place.
But, and this is a big but, it wasn’t even close to keeping up with the fast learning and quick-turns our growth, product, and marketing teams were making based on user feedback, market movements, and new research.
We needed a way to experiment with new features and turn them around almost instantly. 🧐
When I say instant, I really do mean immediately. In some cases, we needed to get new capabilities out the very same day we received feedback. In most cases, we needed to show updates every other day or at least within the week.
Some people reading this might raise a number of questions and concerns. How can you turn features around that quickly? What about testing and quality? How do you keep to a long term plan with such rapid changes? How does this affect the attitude and motivation of the team?
In a startup world, there is a rude awakening and reality check from the market you’re going after. And as I’ve said before, “what you think will work; doesn’t work.”
This means you have to stay embedded in the market you’re going after. Read its pulse and react quickly to feedback and changes. You don’t have time for extended storyboarding or even “white coat” design sessions behind closed doors. And to top it off, 2 weeks is not that fast. With a 2-week sprint and release cycle, you are in reality setting your feedback loop back 6 or more weeks. 😲⛑
💎 Be precious about your vision but throw away any other attachments, they won’t serve you well in a high growth early-stage startup.
At Charli, we talk to users every single day and get feedback. Just yesterday, we were on the phone with users for over 3 hours. We debriefed for another 3 hours and we made immediate changes to our priorities along with mockups and prototypes the very same day.
Some tricks to make this successful:
Create processes and be disciplined. This isn’t a free-for-all, throw stuff at the wall and see what sticks. We look at our target personas, we evaluate feedback, we determine what is relevant, we assess the situation and we capture the feedback in our product and software tools. It is extremely disciplined. And we do it every single day. In a startup, that can mean 7 days a week.
Know the product, engineering, and marketing teams extremely well. We communicate continuously and religiously with one another every day. It’s more of a single team than departments, we all have the same goal. Engineers want to hear the feedback and love getting it realtime. We know the capacity of the team and we’re diligent about changing priorities to match capacity. We have tense moments, frustration and disappointments but as a team we get through it and get great results.
Empower the team to share, experiment, and implement their ideas. We’re a small team (about 15 people) and we’ve done a good job keeping everyone on the same page when it comes to defining our vision, understanding the go-to-market, and our north start metrics. This makes it easier to give each member of the team more autonomy to go solve problems, build new things, and experiment with existing features for better user experiences. We love the surprises and the easter eggs.
Automate everything you can with your software. I’m extremely proud of how the team spent time to automate everything throughout the “design-to-release” steps in our development. It’s actually very cool to watch the team work as they discuss, parse out the work, come together and push a button to release. The team kept the technology choices simple and streamlined all the steps—even the choices on tracking feature requests and bugs. Aron is our VP of Engineering and has been a fantastic influence in making sure we’re structured, automated and simple.
Contrary to what I’ve heard from folks that are not familiar with Agile, it is a very disciplined process for software development. And one that I generally recommend. However, during our product-market fit exercise, we had to throw it out 🗑 for something that was aligned better with our near term goals and needs.
So if you feel like you’re moving too fast for agile…just throw it out [for a while] and see what magic might happen.
A word of caution, this really only works when you have a tightly aligned team where communication is not an issue. If there are any doubts over vision or strategy you might risk derailing your progress, frustrating your team, and generally causing some chaos.
Tread lightly and have some fun. 🤟
Kevin, just to emphasis your point on the importance of communications, teamwork, and alignment (and highlight just how well the Charli team does this!), folks should also realize that the team is globally dispersed and remote (particularly relevant in this Covid year)! Aron is on another continent, key engineers on a third continent, and even here in North America the team stretches across multiple countries and coasts! And yet, I feel closer to the Charli team sometimes then I do my colleagues in the office down the hall or my neighbors next door!