Changing Our Development Process

This is a post about change management at a start-up.

Kaggle, at just under 20 people, is an interesting size because we are right on the cusp of being able to wing it in terms of process and communication, and needing more formal processes to make sure changes and plans are communicated to everyone who needs to know.

For a while our engineering team was just winging it - we used Asana (a sophisticated to-do list application) to assign and track tasks, but didn't have much estimation rigor, work would get scheduled "just in time", and priorities were constantly changing. While this roughly worked, and product was going out the door, we could have been doing better on a few fronts:

• Productivity. With better prioritization and specification, task-switching time drops, and there are fewer questions to answer while an item is in flight.
• Morale. With an ad-hoc process it's very easy to agree to deliver a new feature without a clear understanding of what's getting traded off. This leads to misset expectations, or poorly communicated changes and stresses everyone out.
• Predictability. People are crummy at estimating how long complex tasks will take. So it's no surprise that, lacking good estimation techniques, we were consistently inaccurate estimating delivery dates for features.
• Transparency. Asana is great for many things, but it was ultimately too flexible and inconsistent for anyone to look to it as a single source of truth for all development activities. So instead, they would ask me or individual engineers when something is going to ship.

We wanted a process that addressed these issues, without creating a bunch of bureaucracy that is anathema to start-ups (or, as one of our engineers put it, "better to manage, but worse"). I'll detail the process itself in a future post, but wanted to discuss here how we managed the change.

There were two basic approaches we could take:

1. Make incremental changes, learning along the way, and evolve a process the whole team was happy with. We could research and try a few different tools, experiment with stand-ups, and ultimately figure out what makes the most sense for our team
2. Make a sudden, larger, opinionated change and tweak from there. Do a big-bang roll-out of an agile development process and incorporate the agile tools I've come to really like over the years.

I went for option 2. Management strong-arming is not likely to go over well with any engineering team, but I thought it actually made sense in this case for a few reasons:

• The developers on the team had either good experiences with agile, or no experience with agile; there was no scar tissue.
• While our company culture is contemplative, flat, and autonomous, we also place a lot of value on just trying stuff quickly.
• I had earned enough political capital as an engineering manager that I the team would give it a fair shake even if I was being a dictatorial jerk. In fact, I had tried to do something like this much earlier in my tenure at Kaggle and the team pushed back because I hadn't earned credibility yet.

And crucially, during the roll-out meeting, I explained that yes, I am being unilateral here, but here's why I think it makes sense anyway, and here is the meeting we are having in 3 weeks to evaluate how you like it, and at that same meeting you can decide to blow it all up if you hate it.

The final piece of the puzzle was to make it feel like a real change. When changing largely invisible things like process there's the risk that, in spite of the change, people roughly go back to doing roughly what they were doing before, just with different window dressing. To make it feel tangible and different, we mounted a big TV on the wall that displayed our current sprint, rearranged the floor plan to give a clear sense of space to the team, and made sure out our tracking tool (Pivotal) was integrated with our company chat room on day one so everyone would seem the stream of activity generated by the new process.

And bang! On Friday we were in ad-hoc winging-it land, and on Monday we were starting our first sprint, sitting in our first sizing meeting, with Fibonacci planning poker cards in front of us.

Like what you read? Join the newsletter and get updated when there's something new.