A Startup Journey: Evolving from ad-hoc to Agile to Kanban

This case study describes a period of 6 years in two startup companies that I was involved with.

The first part covers the period from 2004 to 2006 when I was working with a startup based out of Singapore. I explain how we moved from doing ad-hoc development to adopting Scrum. Adopting Scrum was a big improvement over our previous ad-hoc approach but Scrum also led us to make some classic mistakes (from a lean point of view).

The second part covers the period from 2007 to 2009 when I started my own company in India. The company was started with Scrum right from the beginning. I explain how we evolved from vanilla Scrum to Lean and Kanban.

Description (60 minute talk)

Introduction

Most of the lean literature is concerned with applying lean in large companies. But can lean be applied in a startup?

This case study covers a period of 6 years in two startup companies that I was involved with.

The first part, in a startup based out of Singapore, describes our evolution from ad-hoc development to adopting Scrum. Scrum was a big improvement over ad-hoc development, but it also led us to make some mistakes.

The second part, as a part of a startup in India, describes the evolution from Scrum to Kanban.

Part 1: From ad-hoc to Agile

Innvo Systems was a startup based out of Singapore. For the first few years Innvo followed an ad- hoc process, doing whatever it took to deliver. The ad-hoc process worked now and then, but the result was often a result of smart people, late nights and luck.

In 2003, post-funding, the company entered the mobile market by acquiring a suite of mobile Internet applications.

In 2004, the company decided to start development on the next version of the mobile Internet suite. We felt that adopting a process would be beneficial at this juncture. I had previously interacted with Thoughtworks employees and was familiar with parts of Extreme Programming. We decided that Agile would be an appropriate process to adopt as it would give some structure without being too bureaucratic.

We researched XP, Scrum, Crystal and FDD before setting on Scrum as it was the most popular. We
first implemented Scrum on the mobile browser project, of which I was a part.

Scrum was a big improvement over the previous ad-hoc process. The whole team would work together to build the application incrementally making releases every 4 weeks. The team readily adopted agile values and culture since it was well aligned with a startup culture.

However, we also made some classic mistakes:

Handling Hand-Offs: Due to constraints in the budget, we were able to have only a single manual testing team for three development teams. When the team was testing one application, they were unable to test any others. This meant manual testing could not be completed within a sprint. Scrum asks to finish testing within the sprint, but it did not offer any alternative solution when it was impossible to do so.

Not limiting WIP: In many sprints, team members would start one story, get blocked and start another. At the end of the sprint there would be many half-complete stories.

Not looking at the whole value stream: Even in pure Scrum, many activities like acceptance and deployment happen outside the sprint. In our case, even manual testing was outside the sprint. These activities tend to get ignored. Everyone was happy at the rate of completing features, but all we were doing was increasing the inventory for testing. But this inventory is not visible because it is not tracked outside the sprint.

Part 2: From Agile to Kanban

I returned to India in 2007 to start Silver Stripe Software, a company focused on building tools for agile teams. We started doing agile right from the start. Agile worked well, but over time we've moved to a more lean process.

Moving to a pull system: We found that we would finish the planned stories early in some sprints, (causing us to pull in more) and we would not finish everything in some sprints, (causing us to move it back to the backlog). It made more sense to just pull from the top of the backlog one by one as we completed stories and release whatever was done at sprint end.

Eliminating iterations: In a startup there is a high amount of variability in the availability of team members. Customer calls, marketing, support take up variable amounts of time, leaving the rest for development. As a result the sprint capacity is variable, making the concept of timebox and velocity useless. It felt natural to eliminate iterations. Whoever was free would just pull the top item from the backlog and start on it.

A pull model without iterations was also more natural in maintenance mode when requests would come in only now and then.

Decoupling release cycles: Once iterations were eliminated release cycles could be decoupled from the sprint. We release once a week, but we may release earlier if there is a critical fix or later if required.

Incorporating WIP limits: After the problems with too much WIP in the previous company, we incorporated limits to WIP.

Team centric model of development: We now have multiple projects in flight, but we still have a single team. Rather than split the team or move from project to project, we felt it is better to move to a team centric model. Under this model, the team has a single backlog into which stories from multiple backlogs are combined and prioritised against each other (Backlog per team vs backlog per project). Team members pull items from the top of this combined backlog and work on it.

Lessons Learned

A startup operates under many constraints. Regular Scrum makes certain assumptions on the team and project: That the team capacity is constant throughout, that one team works full time on one project, that there are no hand-offs, that all activities are completed within the timebox.

Often these assumptions do not hold in a startup, and Scrum makes no suggestions of alternatives, which could lead to the process getting messy. My experience is that a flow process like Kanban handles these situations better. Scrum, and agile in general, has good guidance on values, such as empowered teams and self-organisation. We've found it beneficial to combine the values and engineering practices of regular agile with a Kanban process.

Speaker Profile - Siddharta Govindaraj

My primary interest is in improving the way software is delivered. I take great interest in lean and agile software development methodologies. I am also interested in the social aspects of software development and how it relates to the technical aspects. I started a company, Silver Stripe Software Pvt Ltd, to work further in the area of software process.

I help conduct Lean and Agile software development events and seminars in Chennai, India through the Chennai Agile User Group. I am also a part of the Agile Software Community of India (ASCI) and help organise ASCI events in Chennai.

I'm also one of the organizers of Proto.in, a bi-annual event that showcases startup companies to an audience of venture capitalists, technologists and media, and the co-organizer of the Chennai OpenCoffee Club, a place where entrepreneurs from Chennai meet once a month.