5 ways to improve distributed agile development in your lean startup
Startups operate in a significantly different environment than what it used to be. We used to know the problem and the main issue was to figure out the right solution. Nowaydays, most startups are acting in a fuzzy reality and can't identidy the problem on the early stage. This requires a lot of pivoting and agile development, iterating quickly, yet trying not to lock yourself into a legacy of your solution.
A startup team has to keep their eyes wide open and absorb loads of external information. Having a diverse skills set in a team helps a lot, yet, unfortunately it often brings the burden of geographic distribution. Proper talent may be rare and far between, and also looking for talent overseas might be a way of cost savings.
The inability of a startup to preserve cash might be the only reason of failure for many. Yes, the run way would not last for ever. We, therefore, need to use lean dev, with heavy emphasis on minimizing waste and maximizing velocity.
This being said, we end up waist deep in distributed lean startup development life.
Skipping 2 years of our ups and downs, here is what we have learned about making such unconventional company setup work:
- Update your statuses like this is all you do. If every single team member is in a separate universe, it has to be a priority for everyone to let others know what he is up to. You are not all in the same room, so you have to emulate water cooler conversations and background noise, which is pretty essential to ad hoc idea generation and spotting of the issues.
- Always screen-cast when discussing requirements. Text is always a bit out of context, and does not work well for distributed teams. Just verbal discussions tend to end up causing “lost in translation” creep. Always visualize when you discuss requirements to avoid assumptions and to set everyone onto the same page for the overall objectives.
- Everyone pitches to everyone. What is the definition of “done” for a lean startup? I suggest “Done=pitched to your peers”. If you did not demo it to your colleagues, consider it never existed. Tons of advantages here, from team morale to spurring idea generation. And yes, nobody is left behind and everyone’s involved.
- Daily Scrums? Forget it! A bit counter-productive, isn’t it? We spotted inefficiency of traditional daily scrums a while ago. My partner and I were closing a day and figured we even did not pay attention to what each other was telling at the earlier daily scrum, not to mention the rest of the team. Quite a surprise for mature project managers. We abandoned the format and pivot until we got a new one. Instead of 3-question exercise, we would run the quick Ignite-like pitching session instead. Works much better so far.
- Resolve the lock-outs as if your livelihood depends on it. Means - Now! Yes, yes, we all know about cross-functional teams. In distributed reality, people would specialize on certain modules and integrate with each other over certain abstraction layer. It causes serious dependencies within the team. If you do not resolve lock-outs - when one member is waiting another - as soon as they are discovered, the snowball will roll quickly until it buries the whole thing.
Taking a look now at these 5 points, I am sensing they all are about “Put everyone into the same room”, even though the team is so much fragmented geographically. Sounds ironic, I know. In our case, we do need to remain heavily distributed as we are developing tools for the bands like us. If we can make it work well for us, it'll work for everyone else as well. So, we ditch the painkillers and pivot again.
