We are a small team: 4 developers, 1 data engineer, 1 UX designer, and me. So we try to focus all our attention on one big project at the time. The idea is to try to get each project to completion, or close to it, before starting another big one. Of course there are other things happening on the side as we do this: bug fixes, maintenance of other features, etc.
The first topic to touch on is skill distribution. We want all our engineers to work as full-stack as possible, even our data engineer has made changes in our front-end repository!. But that doesn’t mean that everyone is equally strong across the stack. Two of our developers are stronger in the front-end, one more so in the back-end, and the last is more balanced but still more towards the back-end. This is important to consider when trying to divide the work that we need to do, since all work requires a varied amount of effort across the stack, we can’t statically split our small team into “fixed” squads.
Now to the challenges that led to writing this post. Like I mention at the beginning, we try to all swarm together to get projects completed, or near so, before starting a new one. However, we often find that there is a good amount of “stepping on each other’s toes” when doing so. And we are always fighting the knee-jerk reaction of making “bigger stories” to cover everything that is related to each other.
We obviously want to keep slicing our work as thin as possible. To make it more manageable and reduce the risk on each change. But that requires better skills at coordinating that work.
We also make use of pair programming quite often. And that helps in multiple fronts. But we seem to reach to it more often than not to deal with these coordination issues. Rather than as a tool to learn from each other and make steady progress by having multiple brains work together.
So, I’ve been thinking about taking another page from Shape Up and get the team to work in pairs throughout a given project. That way we can reduce the coordination problem, while still have more than one person working on the problem.
They would not be “alone” the whole time. We would still support each-other, and have other team members pitch in when needed with their particular skill-set. Specially in the data space. But it could mean we run two projects in parallel, as well as the regular BAU work (bug fixes and unplanned requests).
We are still too small and too early in our journey to try to have “fixed” cycles. We need to remain more nimble than that, and be able to react to changes. Also, we are not in a space where we can simply set an “appetite” for a piece of work and call it the day when the time limit finishes. We want to continue working on a problem until we solved enough of it to move to the next one.
Having written all this down, I now have something to go ahead with and propose an experiment. We just happen to be at the tail end of a big project, and we have two smaller ones lined up to go next. No better time to try something like this. Lets see how it goes…