Over the past 18 months I’ve encountered a number of teams where it is standard practice to have a code freeze late in the iteration. The reason given for this was “to allow QA to test what we created during the iteration.” I’m sorry, but I have to be blunt here – this isn’t agile! It leads to 3 main questions:
- What are the developers doing after the code freeze?
- What happens if defects are uncovered after the code freeze?
- Why could testing not be done earlier in the iteration?
The answers to these questions are often enlightening. Let’s take them one at a time:
1. What are developers doing after the code freeze?
I’ve heard two primary answers to this. The first is that developers are fixing defects during that time. When pressed, I usually find out these are defects from earlier iterations (although this isn’t always the case – more on that later). If we are fixing defects from previous iterations while QA is working on testing the current iteration, how do we ever get caught up? Maybe I’m being a bit dense, but I just don’t see the math working on this one.
The second most common answer is developers are working ahead on things for the next iteration. Said a different way, developers are creating yet more untested code before the commitment for the current iteration has been met. Let’s think about this model for just a minute. Let’s assume we are in iteration 1 and the team does a code freeze on day 7. Coding occurred for 7 days and testing will go for 3 days. But the developers start stuff from the next iteration on day 7, so for the next iteration they get 3 days from this iteration and 7 from the following iteration for a total of 10 coding days, followed by 3 testing days. This cycle continues until the project completes. Anyone feeling sick yet? Again, being blunt, this is not agile, it is mini-waterfall or what I prefer to call “wagile.”
2. What happens if defects are discovered after the code freeze?
Again, in Family Feud style, the most common answer is the defects are fixed in the following iteration. This is a continuation of the first half of the previous answer. How can the math ever work?
However, this isn’t always the answer. Sometimes the answer is developers fix them as they are found. This answer is MUCH less common, but does exist. The problem with this answer is very simple: if it is possible for developers to fix defects in real time after the code freeze, why could this not be done earlier in the iteration? Which leads to question 3…
3. Why could testing not be done earlier in the iteration?
Two answers here are equally common. The first I’ll cover is the “it takes too much time/effort to move the code to our QA environment so we only do it once per iteration.” I understand the need for a QA environment for testing, but is it necessary for ALL testing? In most of the cases I’ve seen it is possible to do a tremendous amount of testing in a development environment to make sure everything is basically working before promotion to a QA environment. The QA environment should be renamed the Verification environment. Ideally we want to use it to verify everything works in the stable environment and passes all tests just like it did in the development environment. So step one is to do more testing in the development environment. Step two is to use some automation tools to build a stable environment quickly. When pressed, most teams can create an automated process to do a bare-metal environment build within a short period of time. It is worth the effort. If this exists, a new build could be deployed at any time, but at least nightly. Combine it with automated regression testing and really get some value from it!
The second answer I usually hear is “we don’t know what to test until the code is done anyway.” Uh oh, can anyone even count how many ways this statement isn’t agile in nature??? Let’s remember the agile process:
- Product Owner (or similar role) creates stories and some basic acceptance criteria.
- During iteration planning more acceptance criteria are created based on conversations between tester, developer and Product Owner.
- During iteration the developer and tester collaborate on their understanding so the code can be written and acceptance criteria can be turned into tests.
- During development the developer can (and should) access any acceptance tests already written to see how their code is doing.
- The developer isn’t “done” until the code passes all unit tests and acceptance tests. Remember the definition of done!
When things are done in this manner the tester ALWAYS knows what to test because they are in close communication with the developer. Collaboration is vital to agile success. This is just one example driving it home.
The bottom line for me is there is no legitimate reason for having a code freeze during an iteration. Teams need to either invest the time/effort to put together a system which doesn’t require a code freeze, or stop calling themselves agile. This is a nasty antipattern which will cause confusion or worse.
Thank you for reading. Until next time I’ll be Making Agile a Reality™ for my clients by helping them avoid code freezes during iterations.