Developer perspective: How we work with the Lean Startup Methodology
If you ask me, developing software in a startup company is a lot of fun. The development process in a startup is very different from the process of established companies that have years of methodology baggage, de facto processes and organizational obstacles. I have been with Queue-it from the beginning as the first developer on the team, and I have seen the product, team and company grow. Here is what I have learned.
There is a lot of pressure when you start up a new SaaS company. You have no product or customers, and only a few resources to get them. I was at this tech talk where the speaker introduced me to the term “Minimal Viable Product”. Basically, any release must only include the minimal feature set that gives value to the users and allows the team to learn.
The speaker illustrated this with a story about a company that had a great idea for a software product. So they developed it and a year later they proudly released it for download on their website. However, no one actually downloaded it. The development team had spent a year learning what they could have learned from a 404 page with Google Analytics.
I remember thinking that it was a stupid, over-simplified story – it turns out that it is really not, and I regret to admit that we too have spent months on features that our customers did not want. In a startup with limited resources, this is a very expensive lesson to learn. Finding the minimal feature set is more difficult than it sounds.
As a team member, you often get carried away with features, architecture, and non-functional requirements. We find it useful to start with a basic user story, then try to vision the feature as part of the solution we expect to end up with, and finally take away complexity until we end up with the least complexity that makes sense to release. Often, we throw away features based on what we learn, and failing fast is really important to make sure that we only spend our limited resources on features that our customers want.
Once we have the minimal feature set, we release it — usually, to a selected set of users, and then we measure it. Measurements can be done in many ways, such as A/B testing, but we rely heavily on both feedback from customers and the data generated by the feature and log files. Based on the information collected, we learn. The learning part may cause us to alter the feature, refactor code, build upon it, or remove it completely in a new Build, Measure, Learn cycle. The cycle continues as we release the feature to more and more users and we make sure to only build exactly what the users want.
Therefore, we keep cycles small in order to learn quickly and fail fast.
Now, this is a statement you are likely to disagree with. Let me try to explain what I mean. On the first page of any Scrum textbook, it will tell you that the initial step is to create your backlog, estimate stories, and prioritize. The first problem is creating your backlog, which basically boils down to sitting with your stakeholders and coming up with user stories. It is really, really easy to come up with stories. Over the years, we have had countless ideas for stories that have never been realized, while others that we could not imagine have actually been implemented. Thus, creating an accurate backlog is next to impossible in a project like ours.
Second, estimating the complexity of stories is fundamentally flawed. What you should be estimating is the potential business value.
The development cost of a feature will in most cases be insignificant to the business value of the feature when offered to thousands of users. Whether it takes one or five weeks to develop the feature, it should not change your priority. So, having a complete estimated and prioritized backlog is a waste, and it will be outdated by the time you complete it.
We have a vision of what we are aiming for and a road-map for the next three months, but be mindful about your vision and make sure it does not cloud your ability to change as you learn.
Any agile development methodology is about removing queues. Queues happens all the time in the form of obstacles in the life cycle of a story, and they reduce the speed of failing and learning. There has been a common misunderstanding that team members must be fully utilized to get maximum throughput of the team.
Imagine your local supermarket. If only a few cash registers are open, they will be fully utilized, but there will be queues. Queues are even longer if one is out of service or if there is a spike in demand. If more registers are opened, queues are reduced, and throughput is higher, but not all are fully utilized. Making sure queues are visible and action is taken to reduce queues is vital to the team and to the project.
We use Kanban, which is an excellent tool to visualize the process and expose queues as well as stand-ups and retrospectives.
I used to work at a major software company that was developing a large SOA-based system with about a dozen services. We would ship the software to the customer with a hundred-something page installation manual. The poor customer operations team would then spend about a week desperately trying to install it, until they finally gave up and asked for help. Eventually the company would send a talented employee (me) to aid the process and after a few weeks their testing could begin. Talk about a queue! Manual processes MUST be automated. The software deployment pipeline in particular must be as easy as a click of a button to facilitate a rapid Build, Measure, Learn cycle.
The Lean Startup Methodology is one of the cornerstones of Queue-it’s success, and I definitely encourage you to try it out.
Written by: Martin Larsen, Director of Product, MScIT