The Tienda Nube team has been growing rapidly in the last months, especially since the second half of 2017, in which we received a big investment to continue accelerating e-commerce in the region.
This injection of capital allowed us to almost double the team, and at the same time be able to serve more and more customers, with increasingly diverse needs.
All this growth added a layer of complexity when planning, executing and communicating. And it was in the middle of that change that we realized something was wrong.
Although we modified our way of working several times, we always did things in a very “traditional” way (for the universe of startups).
On the one hand, each Product team listened to the different stakeholders in real time (that is, all the time), and added to their backlog the problems to solve and / or proposed solutions.
Once we gathered all that information on the table, we built a roadmap in the short term (next weeks), one medium term (per quarter), and one long term (per semester).
But in order to build this roadmap, the team had to estimate how long it would take to complete each task …
We noticed that there was a big difference between our estimates and the reality. The first feeling that invaded us was frustration, and the first thought we had was: “we suck at estimating”.
This lack of ability to estimate made us very unpredictable for the rest of the company (Growth, Customer Success, Talent, Branding, etc.) and for our customers. It was very difficult to trust a Product date.
As if that were not enough, the roadmap changed constantly and the farther the target was, the fewer chances it had to occur. Also, by the time we realized that we did not arrive with the promised date, it was too late to make a correction.
That’s when we stopped and asked ourselves the following question:
Are we lousy estimating or is it impossible to estimate how much it takes to solve a problem, if we still did not do anything about it?
Luckily, we were not the only ones with this problem. The phenomenal Basecamp team had met with the same challenge, and had solved it in a great way.
Basically the problem lies in estimating in a linear way jobs that are not at all linear, since they have a very large portion of uncertainty.
Software development is not like moving a pile of rocks:
The work that requires solving problems is more like a hill, where there is an uphill phase in which one is discovering what it is and, just when you reach the top of that hill, you can look down and estimate how much is missing to end.
In our adaptation, we have cycles of 6 weeks, with 2 weeks of separation between one and the other to plan. In addition, we have an internal Product demo in week 4, and a demo for the entire company in week 6.
On the other hand, in those 2 weeks of planning, our team has two weeks of free roaming, so they have the freedom to choose which battles to attack and in what order. Usually those days are used to make code refactors, fix a secondary bug or include some extra functionality.
In those weeks of planning, the Product Owners team works side-by-side with customers, the Customer Success team, and the Research team. This Research team is in direct contact with clients and uses tools of Jobs To Be Done to understand the needs of the clients, or in terms of JTBD, the Jobs. This gives us valuable insights to the Product team.
At Tienda Nube we take the needs of our clients very seriously, and that is why they are our main allies when it comes to understanding and creating.
Once we have clear which are the most important problems that we should solve in the short term, we ask ourselves the following question:
What is the six week version of this solution?
And once we have all these solutions clear, we compile them in a document in which we explain in detail all the problems we are going to solve and how we are going to do it, and we share it with the whole company. But this time with a very clear horizon: six weeks.
Then, during the execution of that cycle, we abandoned the traditional way of reporting the status of projects like “46% progress”, and we started using Basecamp’s hill charts.
We have already had three six weeks cycles, and within the Product team we could see improvements of all kinds:
- The team feels less pressured (happier). There are no more self-imposed deadline commitments as they are pre-established and fixed for everyone. This took away an enormous pressure from our individual contributors (developers and designers mostly).
- We stopped discussing dates and went on to discuss scopes. Suddenly the talk focused on defining the MVP or “what is the best six-week version of this”.
- This separation in fixed cycles forced us to split complex solutions in different releases, and thus we managed to deliver value much faster.
- By separating the tasks of a project within the hill chart, we realize in time when a correction has to be made. Since we can differentiate between the tasks that belong to the critical path of a project and see which segment of the hill they are on. If in week two a critical task is on the left (“Figuring things out”): Houston, we have a problem.
- The task of our Product Owners was immensely simplified. We go from estimating and planning every day, to doing it only every 6 weeks.
Also, outside Product team we also saw several improvements. We became more predictable, the rest of the company has a much clearer vision of what we’re going to do and why, and especially when it’s going to be ready.
The prose of the document that describes what is going to be done in the cycle communicates much better than any Gantt. To get an idea, here you can see an example of Basecamp.
So, are you telling me that you solved all the planning and execution problems?
No way! But almost. We still have many challenges to untangle, but every day we are closer to having a healthier, more predictable team that delivers as much value as possible to our clients.