View on GitHub

Jeff Gabriel

Software development thoughts and findings.


Developing Software at a Startup

Like most people who build software for a living, I think a lot about the ideal process for building software. Or at least those who have some responsibility for delivering on a timeline and within a budget. And like many I have been following along with and reading about XP -> Agile -> Lean processes for nearly a couple decades now. I’ve had opportunities in the past to implement elements of each recommended approach along with some local flavor on small teams, and more recently the (pleasure?) of trying to help large enterprise teams figure out what it looks like with all the attendent enterprise complexities.

Now comes the startup and the definite pleasure of bootstrapping a development team process to build software with only a little information and the tightest of timelines. All the software must be built right now. But you can’t ever build all the softwares - that’s a key understanding for everyone involved (whether you’re at a startup or not) - and certainly not right now. We want to be lean, we want to be agile, we want to win this ill-defined race to build the right thing in time for a market disruption that we can lead. So, what pieces of past learning and experience can I mix with the state of the art to get this done?


First things first, you have to have the right team. This doesn’t mean rockstars, ninjas, gurus, whatever that all is. To me it means curious people you trust to write decent software while aiming at a shared goal. People who will speak up when things don’t make sense, challenge their peers to try harder, and put their heads down and charge the finish line once they know where it is. If you can’t trust your team, your process is doomed. The only good process is one wich people actually follow and lean processes require that team members be trusted. Honestly I think this is the greatest challenge to the enterprise implementation. But, that’s not a problem with my current team - I’ve worked with many of these people for years and the rest are great too. Trusted team - check.


We’re using Kanban, by which I generally mean the methodology spelled out by David Anderson in his excellent book and refined by ideas from the Phoenix Project. Specifically I chose this as our primary work tracking process because:

To put some perspecitve on it from the ‘no’ side; we have no scrum, no sprint review, no estimation, and no project manager. We do have; excellent insight for the whole company into what’s in WIP, strong association of tasks to product goals, reporting on velocity and churn, and an invested development team that understands exactly what to do each day.

Stories on the Roadmap

This post is getting long so let me wrap with one more point about how we’re achieving the results we want. Our product is driven by a roadmap that is made up of user stories. Each user story is broken down using Jeff Patton’s story mapping approach. I didn’t know about this methodology before but I am now totally in love with it. As Jeff points out early in his book it breaks down to an extremely simple explanation - a story map communicates a big picture that a pile of stories alone can miss. As a team (tech and non-tech alike) our organization has worked through the user-centric activities which we chose for the near term roadmap to identify all the stories and their associated tasks. As we start development we break it down further and identify those tasks which will complete an MVP for the story. Each story which has this level of detail ends up in a swimlane on our Kanban. Everyone understands the target for the roadmap timeline and we are working as fast as we can to deliver the stories. At any point we know how far we are into the overall roadmap item, or any set of stories which have made it onto the board. A few final thoughts on getting this level of organization and investment out of the team: