Changing Our Development Process

By Chris Clark, 07/11/2013, in Engineering management

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:

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:

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.