This week I had a conversation with several coaches at a client on something I consider pretty basic Agile knowledge, actually. To collect my thoughts together, I think it would be good practice to write all of them down for the time being. The topic at hand deals with test automation and enabling release-at-will through a zero-bug policy and how to get there. I think it’s going to be a brief blog entry, but fear my thoughts might run away there. So, stay with me.
Pain points in releases
The discussion started when one coach mentioned that she is trying to piece together how complicated a release will be. There is a release process in place, but releases happen so seldomly and are so painful that no one wants to deal with them (ok, that’s an interpretation on my part).
The first Agile principle I would bring in here:
If something hurts, do more of it.
Since the release process currently hurts, our human tendency is to shy away from that hurtful feeling. However, in order to solve the underlying problems, we need to embrace the pain points and solve them one by one. Elisabeth Hendrickson taught me this, I think, at the first Agile Testing Days in 2009 in Berlin. If we release more often, our releases become more rehearsed over time, since we really need to deal with the pain points in our release process. If we stick with just releasing once per year, we will continue to avoid the pains such a release causes us and the problems will continue to persist. So, contrary to human nature, we need to release more often.
From a business standpoint, we aim with Agile to be able to release more often than we actually do. Whether or not to release a new software package is a business decision where many more factors than just technical considerations come into play. Are our customers ready for a new version? Are we gaining some competitive advantage from our competitors with a new release? Do we need to proactively or reactively deal with changes in laws in our business domain to avoid legal payments? Ideally, from a technical standpoint, we should be able to release more often than we actually do. So, if your market now is fine with one release every three months, make sure, you can technically release at least every month should put you in an advantageous position. That will be one factor less to consider once you actually want to do another release. So, be able to release more often than you actually do.
Dealing with bug fixes
One other factor playing into the “let’s release less often” dynamic there is the number of bugs in each release. I re-cited a potential client visit a couple of years back. They told me, that they appeared to have less and less time. I asked them how many bug fixes they release on average per month. 40. And how many new bugs do you get from your users per month on average? 80. I have a good idea why you may find yourself with less and less time at hand.
Ideally, as a long-term perfection goal, we strive to put ourselves in a position where the final regression test before the release is put together will not find any bugs introduced by any of our changes. That’s an aspirational goal, that should infect and guide our thinking with new features we built in. How could this change break some other part of the product? Do we understand the clients of our component and their usage enough, to confidently change this bit?
Of course, there is a learning curve involved here. So, to get that learning started, start with collecting all the bugs that come back from some point down your value chain. Cluster them into categories, and find the biggest cluster. Now ask yourself: How do we need to change our team process to no longer allow such bug fixes introduced into our product piece? That should give you a starting point. Once you dealt with the biggest cluster of problems and implemented team process changes accordingly that work, take a closer look at the next biggest cluster. And so forth. You potentially want to restart the collection of bugs your process still allows you to build into your product.
Avoid branching in your version control system
Another problem I heard there was the extensive use of branching for every new component version. Based on personal experience, I would avoid branching at all. Instead, tag a released version in your version control system, and continue working on the head of the code repository all the time. ideally, the head of your version control system should be able to provide a working release more than once per day. Again, that might be an aspirational goal for you, depending on where you start. If you need to fix a particular bug in a particular release, branch from the release tag, and create a patch, that can then be merged to other versions as well.
Back in my days, I mostly used subversion for this, and I use the term “branching” in the subversion meaning here. The similarities to git which is widespread today, are not that direct, since git comes with at least one other meaning of branching.
If my old brain recalls correctly I initially got aware of all of these techniques by James Shore in his Art of Agile Development book. It’s out now in its second edition. I haven’t read it. Based on my 1st edition read, though, I wholeheartedly can recommend even the second edition regardless. (i need to catch up with my backlog of books on the shelf.)
