Warming Up to Agile

Warming Up to AgileSuccessful agile development introduces a lot of new things, or at least things that are often new to the people starting to adopt an agile approach.  Working with a backlog, engaging a product owner, and utilizing new techniques for planning and estimation often obscure the fact that in order to work in an agile way you have to be highly proficient at what we might call foundational software engineering. Some agile approaches talk about "sprinting", and perhaps this is a good metaphor.  Before you can sprint, you need to be in reasonable shape and you need to warm up a bit in order to avoid injury. Agile software development, delivering working, tested code in short time increments, requires some pretty solid skills in some specific areas. For the moment I'll focus on a couple of key areas we often find wanting when working with teams just starting their agile journey.

In order to develop in short cycles, let's say 2 weeks, you are going to need to build software quickly - certainly daily, and ideally continuously.  Concretely this means that builds need to be automated and executable anytime someone needs to do a build.  If you have to ask someone to do the build, and if it requires manual effort, you simply won't be able to build effortlessly. You need to be able to run a build without thinking about it, because you will have a lot of other more important things to think about.  If you're thinking about "going agile" and don't yet have an automated build capability, focus on that first.

Once you've got the build automated, you'll need to automate tests as well.  When we say that an agile approach focuses on producing working software, the evidence that it works is provided by tests. If you can't run at least unit tests every time the software is built you will never keep up with the demands on testing.  Realistically speaking, just automating unit tests is not enough; you need to be able to do integration, system and regression testing for every build, at least in theory, but unit testing is a good place to start.  In addition, all tests other than User Acceptance and Usability tests should be automated.  Building up from automated unit tests, you should be able to test everything in the system except the User Interface through programmatically-invoked tests.  If you don't do this, you will never keep ahead of the testing workload and your test coverage will remain weak.  If you don't have automated testing, runnable after every build, you will be able to "play" at being agile but you will never really achieve the kind of quality that you will need. At some point you will suffer from lack of testing and something important will blow up in production and that will be the end of your agile experiment.  As with builds, if you are not automating testing now you really need to get your testing act together before you get very far down the agile path.

While you're working on automating your builds, there is another skill in which you'll want to be proficient: refactoring.  There are a number of good books and web resources about this topic, but knowing is different than doing.  In short, you'll want to be comfortable with making significant changes in the structure of the code from one build to the next, done in concert with changes to the unit tests, so that the build and automated tests don't break from one build to the next.  You won't have the time to step back and do "big design" efforts, so you're going to have to get comfortable with making small changes that, over time, add up to big changes, all while continuing to do other development. This takes time and practice, and once you start sprinting you will either have to have it mastered or get good at it very quickly.

This leads to another foundational skill: source code management (SCM).  First, you need to use a source code control system to keep track of changes so that you can roll back to prior versions in the event you change your mind about an approach.  You need to be able to keep work that you are doing out of the build until everyone is ready for it.  You need to version everything, including unit tests.  Sometimes, when undertaking major refactoring, you may need to branch the code, and then merge it later once the changes have been proven. This is all really basic SCM, but it is essential to being able to achieve reasonable velocity and throughput for the team.  In fact, I've put things a bit out of order, because it's really virtually impossible to automate the build or refactor without solid mastery of SCM.

These are by no means the only things that you'll need to master in order to work in an agile way, but they are the foundations on which the rest of agile development is built. Teams that have not gained proficiency in these foundational skills need to focus on doing so before embarking further down the agile path.  There will be plenty of other new things to learn along the way.


1 Comment
  1. Cornell M. Adkins | August 19, 2013 at 4:14 pm Reply

    avatar

    Do you practice unit and integration testing?I can’t overstate how important unit/integration testing is. Your definition of “Done” should clearly mention this, and the development part of the story cannot be said to be complete unless it is unit tested. Gojko in his book Test Driven Development using Fitnesse mentions the fundamental differences of advantages of TDD and Unit Testing. In teams where acceptance tests drive development, some write fewer unit tests as the acceptance tests test the application functionality. However the issue is, failed acceptance tests indicate a problem but do not locate the source as clearly as the unit tests do. Additionally in unit testing, white box testing techniques like statement coverage, branch coverage and condition coverage etc. identify fundamental problems in code which is mostly not covered by acceptance tests.