“We have 10 Million USD in cash, but we are burning one million a month. We better find how to make this business profitable, or we are out of business in less than a year. Are you up for this challenge?” Asked the CEO.
That’s the question I had to answer during my interview. The fear of the unknown tried to hold me back. However, my curiosity spoke louder, and I didn’t hesitate to take the offer. We were small, a development team of 7 members, the Scrum Master, and me.
But what is a Startup? Let’s look at the definition from Wikipedia. In bold, you can read the most relevant aspects.
A startup or start-up is a company or project initiated by an entrepreneur to seek, effectively develop, and validate a scalable business model. While entrepreneurship refers to all new businesses, including self-employment and businesses that never intend to become registered, startups refer to the new businesses that intend to grow large beyond the solo founder. Startups face high uncertainty and have high rates of failure, but a minority of them do go on to be successful and influential. Some startups become unicorns, i.e. privately held startup companies valued at over US$1 billion.
As you can see, Startups have a high rate of failure due to their complexity. But why is it complex? Startups innovate by implementing new business models and disrupting markets. For example, the Startup I worked in 2016 had the mission to help people to sell their car in less than an hour, removing bureaucracy and insecurity. It looks impossible. It wasn’t, yet, it was complex.
In the beginning, Startups have no more than an idea, so the question is, how to validate the assumptions and prove its validity? Beyond the uncertainty, Startups have the time pressure, because there’s not enough money, which means every minute counts. How fast can we learn? How quickly can we adapt? Such questions are vital for any Startups, which want to succeed.
How can we handle so many challenges with such high pressure? Scrum.
A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
COO: Last month, many dealers joined our auction platform, but the engagement is too low. Why is this happening?
The Startup I’m talking about is called Instacarro.com, and it is located in Brazil. The value proposition is, “We sell your car in 60 minutes. You visit us, and we inspect your car. Your car goes to an auction, where dealers all over Brazil place bids. You receive an offer, if you take it, we pay you immediately, and you go home by cab, if you turn it down, no problem, you don’t pay anything.”
Our assumption was, the more dealers we acquire, the more competitive our auction will be. Therefore, we put considerable effort into acquiring new dealers. Surprisingly our auctions didn’t become any better; on the contrary, the dealers were not engaging.
But why did it happen? I wondered about this question for a while, so I realized that we failed to involve the dealers more in-depth. The biggest failure was to develop something without involving the end-users. So why not take the dealers to a Sprint Review? Let’s look at what the Scrum Guide says.
A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.
— Scrum Guide, Sprint Review
Once we had some dealers participating in the Sprint Review, we got valuable feedback, which was revealing. We understood the reasons why they were not engaging with the solution. Unfortunately, we fell into the pitfall of focusing on the solution instead of the problem. We focused on building a state of the art app, while our audience wanted a web-platform instead.
“There is only one boss. The customer. And he can fire everybody in the company from the chairman on down, simply by spending his money somewhere else.”
— Sam Walton, Walmart founder
The revealing moment happened on a Friday afternoon. During the Sprint Review, the team presented the new Auction App. One Dealer raised his hand and said, “The idea behind this app is nice. I can find cars easier and place bids. But, don’t you think a smartphone is too small to watch the car pictures? It’d be perfect if I could use it on my desktop with my 27 inches screen.”
It was clear we had an opportunity to explore, the dealers were interested in our service, but our solution was not delivering the best experience. In this case, what could we do? Pivot! Our assumption was valid. However, the implementation didn’t match with the audience’s expectations. In the startup world, we say, the fast we fail, the faster we succeed.
“Ideas are commodity. Execution of them is not.” –Michael Dell, Dell Chairman and CEO
Scrum was perfect for this scenario, and we adapted our Product Backlog in this direction. One of the fundamentals I learned during this experience is that we should not fall in love with ideas. We should always be open to change our plans if needed. We had a plan for the app, indeed. However, we understood the need for an abrupt change. The only certainty we have at Startups is the constant need for changes.
Responding to change over following a plan
It was Monday morning when I came to the office expecting a typical day. The CEO asked me to talk, and he said, “We are not moving as fast as we should, we learned some important facts. However, now we have only eight more months of cash. We need to be bold. We will triple the size of the development team. Can you handle this scenario?”
That question caught me short. In a traditional company, there would be a Product Owner for each team, which is unproductive. For the first time, I would have the chance to be a Product Owner for multiple teams. However, I had no experience with that. Again my fear wanted to hold me, while my curiosity pushed me to accept the challenge.
In a month, we tripled the Development Team, so we had 21 developers. They were located in the Dominican Republic, while I was in Brazil. I flew there to meet the new team members and define how we could organize our work.
It was complex to come up with a structure of how to scale. Some questions brought a lot of back and forth discussions:
- Should we split our Product Backlog?
- How should we define our Development Teams?
Despite not being experienced in scaling with Scrum, I knew what I wanted to avoid. I tried to remove any chance of creating silos and diminishing the likelihood of collaboration. So we decided to keep one single Product Backlog. The teams were organized in a way that they had all the skills required to work in any challenge we may face.
Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product. A Product Backlog attribute that groups items may then be employed.
I have to say it was challenging. However, I have never learned so much in so little time. We found a way of working together as a Scrum Team. I was the only Product Owner, and we could focus on validating our hypothesis so that we could find a market fit.
In less than a year, we:
- Developed four new apps from scratch for both iOS and Android
- Pivoted three times within our solutions
- Build two new platforms
- Designed seven new web-sites
When I look into that, I ask how could we reach that? By living the principles of Scrum, being transparent, inspecting, and adapting, we could thrive. Without that, I cannot see how we would do it.