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?
Team
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.
Kanban
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:
- Everything we’re building is more like an experiment or MVP feature and so very small units of work are better. Building out a sprint plan just doesn’t make sense for us right now.
- Priorities might change daily. It’s easy to see WIP on our card wall and put something on hold while we work out a new experiment
- Developers are trusted team members who should be able to identify what to work on next increase overall velocity by pulling what’s next on their own. I think Kanban encourages this high trust environment.
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:
- Involving the whole team in describing the user stories and their steps is critical to communicate enough information to allow people to then work more independently. They have the goal in mind. We take short enough steps that everyone has the light they need to see the end of the current task.
- The “Lean”-est part (as in Reis’ book) of all this is coming up with the hypotheses about what the customer wants and how you’re going to test and measure that. While one person may want to do that it’s again critical that all departments understand it together so they know their part. It’s also critical to get it written down at least in story form because otherwise what seems like agreement is likely not.
- The no HiPPO rule is hard but worth it. Again, in order to lead by trust and mission rather than individual task management and to gain the insights of everyone - where we really believe all of us is smarter than any one of us - you have to do the work to engage all the people.
References
- Kanban: Successful Evolutionary Change for Your Technology Business
- The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win
- User Story Mapping: Discover the Whole Story, Build the Right Product
- Lean Software Development: An Agile Toolkit
- The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses
