Today’s post is an instructive story about mixing various good patterns and ideas. They are very useful separately, but when one uses them together, they may lead to problems which nobody wants to deal with at all.
We found several different defects in a certain feature, and in order to reduce handover costs I collapsed them together to make an “umbrella defect” *(defect1+defect2+…defectN) and put it into our *Queue. When my colleague started to work on it, I was quite happy with the result: less handover costs less context switching and more focus on a faulty feature. It was really nice until our deployment day came. Or Kanban board and version tree looked like this:
The mentioned umbrella defect appears as ‘UD’ on the Kanban board, and it covers ‘UD1.1’ and ‘UD1.2’. Based on our Kanban board, there is no impediment to the deployment, but right before the deployment we realized that not everything we wanted to deploy had been tested since we were using one-track. One-track means that we don’t have branches, labels or tags, we just have the trunk where we have our latest version. One-track is an excellent thing, but it seems that it doesn’t work well with collapsing.
So, we have the expand/collapse pattern, and the one-track way of working. In retrospect, the situation could have been solved by keeping the code of ‘UD1.1’ and ‘UD1.2’ locally until the deployment is done, but we have a policy saying that we have to use SVN and we have to commit our code every day so that it’s kept securely and nothing gets lost. Our local version of the iron triangle of project management is complete:
Each corner of the triangle has its purpose and benefit. Expand/collapse is proven to be really helpful. Usually, teams expand a large work item into smaller ones, because it is easier to work with smaller work items than with a large one - small things travel faster and they are easier to handle. When the small items are finished the teams have to collapse them back to the large one. This is the basic idea of expand/collapse - for more information check out the related post on infoq. Fortunately, it works backwards as well. It is wise to collapse very small work items - like defects - into a larger umbrella work item in order to reduce handover costs and context switching. From the version control system perspective, the expand/collapse should happen on a branch and never on the main trunk.
One-track is a brilliant thing. I used to work with branches and tags. In retrospect, every hour of every day spent handling these was a waste of my time. I watched my colleagues and myself merging defects and small features between five or sometimes six feature branches for years - we were using a centralized version control system. It was a one-man’s job, which took days and weeks. Each branch required its own continuous integration project, not to mention the different deliveries. In one-track, we need only one of everything, and the development is fast, I mean really fast. And we want to go fast, because we need the feedback fast. Kent Beck mentioned this topic in his “Software G Forces: The Effects of Acceleration” presentation at SDC2010: ”for faster delivery, teams should stop working in branches and use one-track“. We want to have continuous delivery in the future, so we need the one-track.
The last corner is the policies. We don’t want to lose code, because we cannot afford to reimplement everything in case something gets lost. So we must commit code into SVN as frequently as possible. Until we are able to find a better solution - there is nothing wrong with the actual one -, this policy stays, and so does SVN.
No one can keep every corner of an iron triangle. We don’t want to lose data and we don’t want to create branches, so sorry expand/collapse, you have to go. We can live with the handover costs and context switching. We rather stop what we are doing and shift our focus to the right side of our Kanban board (testing and deployment) when something is finished than work with SVN branches. The Lean thinking starts to emerge.
As usual, judge our decision in its context. Each project is different. This is really important, because you may be tempted to drop a good pattern because it didn’t work for us. Don’t do that. The lesson here is to be ready to drop the pattern which holds you back. It could happen that we’ll be in a situation when we can no longer afford to have only one track. In that case, we won’t hesitate to drop the one-track way of working, which may provide some space for expand/collapse. Maybe.
comments powered by Disqus