There’s a wall in the Cemplicity office behind where the development team sits that is covered in Post-Its. Every post-it represents a new feature, configuration change or, occasionally, bug that has been analysed, built and deployed to our production systems. It’s a monument to the achievements of our small, but mighty, team.
Like many organisations that take an agile approach, we are continually experimenting with new ways of getting the work done. In this series of posts, my co-owner and I will describe the process we currently use, how we got here and why it might work for you too. We’ll even tell you what a co-owner is. Later.
We start with a backlog of things to be done. No two items of work are the same, but we divide the work into several broad categories: pebbles, rocks & boulders and technology platform enhancements.
Pebbles
Pebbles are small work items. These can include client-specific configuration changes, quick investigations, very small code changes or bugs. A pebble should take no more than a couple of weeks to complete and is often considerably smaller. Pebbles are tactical in nature and tend to be tested and deployed to production relatively quickly.
Rocks
Rocks are larger pieces of work. These might take more than two weeks to complete and often represent significant product enhancements that will be available to all clients.
Boulders
Boulders are… well, they’re bigger than rocks. These are usually very large product enhancements, platform or architectural work. Rocks and boulders are more strategic than pebbles and often require significantly more design and testing.
Unfortunately our last category does not map to the Wentworth Scale at all. Like every development team, we’ve picked up technical debt over the years and we know that if we don’t pay attention to it, we’ll find ourselves slowing down. We are serious about addressing technical debt – we try and dedicate 30% of our capacity to it. Some technical debt is addressed as part of normal work on rocks and boulders. But we sometimes we find debt that isn’t as simple as a code change. Sometimes our tools or practices can slow development, or cause problems for other teams. These improvements sit in the technical debt category.
We organise our in-progress board into swim lanes for each category. There seems to be a rhythm to choosing which items to work on: sometimes there’s more of a focus on tactical (pebbles) and sometimes strategic (rocks, boulders and technical debt). But we try and make sure we always have a mixture of items being worked on at any one time.
So how do our items move across the board to the wall of victory? We’ll talk about that in part 2.