At Sprintly, a good percentage of our customers are startups (or agencies that work closely with startups). I’ve spent the past few weeks talking to many of them about what’s working and not working in their product delivery process. It’s interesting to me how much I see repeating patterns across these teams. Here are 4 of them:
1/ Great startup product teams choose the practices and processes that work best for them – Few of the startup teams I’ve spoken to are rigidly following processes they learned from others. In almost every case the way the teams are working has naturally evolved over the course of months or years and is unique to them. Startups are working in an environment of constant change – their markets are shifting, and their teams are growing and evolving. They are accustomed to change and as a result have adopted loose, flexible practices that are easily adjusted. For many of these teams it means that they are Agile in spirit, even if the way they work doesn’t meet a rigid definition of “agile development”.
2/ Startups are focused on fast delivery but also on learning – Many of the teams I’ve spoken with would describe themselves as both “Lean” and “Agile”, however their definition of both terms isn’t what I’ve seen at larger companies. The focus of these smaller teams isn’t as much on rapid product delivery as it is on quickly delivering things they can learn from. Most tell me they evolved from using a purely Lean approach – creating hypotheses, building, measuring, learning and repeating this cycle – to gradually adopting bits of Agile where it aligned with the maturing goals of the product team. The gradually added things such as an increasing use of customer stories, and tracking and prioritizing a backlog of features and bugs – while retaining the focus on feedback and learning. Not surprisingly, their project management tools also shifted from using nothing (or a spreadsheet) to managing tasks using general task management tools like Trello or Asana before graduating to a more purpose-built tools for agile software project management like Sprintly, Jira or Pivotal Tracker. That said, they don’t want their tools to be complex, even when they have outgrown simple checklists. They want the tool to get out of the way and be streamlined and simple enough that everyone can start quickly with no configuration or training.
3/ The “product” team is everyone – In most startups the lines between development, product, marketing and sales are very blurry. I’ve talked to many where the head of product is also responsible for sales and it isn’t unusual to have development handling support, or to have marketing and product be essentially interchangeable. To make this work, these teams have optimized around team collaboration and communication. Daily standups are still happening at many startups but frequently I’ve seen them somewhat replaced by constant collaboration on Slack and Github (and almost all of our users are integrating Sprintly with at least one of these, most use both). In our user base, startups with less than 20 people tend to have everyone on the team using Sprintly, and anyone in any job function can create and comment on work items. Startups aren’t using rigid Agile definitions of team members and roles (for example I’ve seen few with a person they call “scrum master”) but have adopted the spirit of openness and collaboration across development and business folk.
4/ Collaboration with remote team members is common (and critical) – The high competition for the best talent, an increasing number of startup teams forming outside of traditional startup hubs, and a more global customer base are all reasons why startups are increasingly working with at least some remote team members. There’s also the fact that fundraising and customer activities put key members of the senior team out of the office for periods of time. As I mentioned in the last point – these teams are already becoming experts at digital collaboration, so adding remote team members to the mix isn’t as difficult as it may have been in the past. We are a completely remote team here at Sprinty with team members spread across 3 countries and 5 cities and we’re in good company with InVision, Buffer, Basecamp, Automattic, Baremetrics, Upworthy, Zapier, and others. Our customers are following that trend by having at least some remote members.
Not surprisingly, we operate a lot like our customers inside Sprintly – we are Agile-ish with a some Lean flavor, and our processes are fairly fluid. We are small enough that everyone has input on most things, particularly those related to product and we’re an entirely remote team that relies heavily on tools (including our own) to stay on top of projects and people.
