One metric that I think is most important to look at during an Agile transformation is the frequency of commits that developers make due to the build.
This gives us a huge amount of information about several important things. First and foremost, it indicates the amount of friction in the build and how much work developers have to go through in order to commit their code. For example, without a set of automated regression tests committing our code requires a manual testing process that is often deferred to the end of the iteration, or even to the end of a release. This might make a lot of sense in building construction, but it’s highly inefficient when constructing software.
Building software requires many parallel tasks, but it’s far more efficient to take a task start to finish without interruption, and finding a balance between what to do now and what to defer on is very important.
To me, this speaks to the very essence of Agile, which is all about delivering working software. In Scrum, at the end of every sprint we’re supposed to have working software, not software we hand off to QA for testing.
When we separate development and test, we can introduce major inefficiencies to our system, and we’re also interrupting the flow of development, forcing developers to go back later to fix mistakes and incur massive time delays to reacquaint themselves with code that they wrote just a few days or weeks earlier.
This is what I call Painful Agile and I see many teams doing Painful Agile. Committing every two weeks is less painful than committing every three months, which is less painful than committing every year, but all of these commitment intervals include some degree of pain.
The pain only really goes away when we are committing all the time, whenever we have any little bit of functionality to add to the system. When we can commit frequently, we get working software more frequently as well, which lets us to validate that we’re on track more frequently and gives us a true measure of our progress.
Committing frequently also means that developers are breaking down stories into small, manageable tasks, which has innumerable benefits for Agile development. It not only shows us that our build has low friction so it’s straightforward to use, it also shows us that developers are good at breaking down stories into manageable tasks, which is another set of skills that are very important for an effective Agile development cycle.
In a healthy development environment, we commit several times a day. This may not mean that were writing several features a day but rather that we’re good at breaking out features into manageable chunks and each one is a step in the direction of overall progress.
And when we commit to version control, we are committing to trunk. The whole purpose of committing frequently is to let our newly developed code coexist with the rest of the system. This is what continuous integration is all about, but it can easily be defeated through branching.
I know lots of teams who use version control but each developer works in their own branch and it’s only much later, right before release, that the developers integrate their feature branches back into truck. There is a name for this approach and it’s called Waterfall.
Building software in feature branches really defeats the purpose of version control in the first place. Long live branches may seem like they are a good idea but they are almost always an anti-pattern because it isolates code rather than integrating it.
We want newly integrated code to be part of the whole system so we can validate that it doesn’t affect any other part of the system. Integration is traditionally when the worst bugs show up. When we put off integration we’re basically keeping ourselves from seeing the truth of our build and if we don’t know about problems we can’t fix them. When we integrate toward the end of a release, we can learn about problems and bugs when it’s too late to do anything about them.
But when we commit frequently we can see a true measure of our progress and the problem space is fresh in our heads, so if we discover a bug we can typically fix it right away. This has one of the largest boosts to productivity that we can get in software development.
Previous Post: « Keep Defects from Escaping
Next Post: Thinking with Objects »