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. ๐ค
Is Agile dead? ๐
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!