Agile antipattern: Code freezes during each iteration

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:

  1. What are the developers doing after the code freeze?
  2. What happens if defects are uncovered after the code freeze?
  3. 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:

  1. Product Owner (or similar role) creates stories and some basic acceptance criteria.
  2. During iteration planning more acceptance criteria are created based on conversations between tester, developer and Product Owner.
  3. During iteration the developer and tester collaborate on their understanding so the code can be written and acceptance criteria can be turned into tests.
  4. During development the developer can (and should) access any acceptance tests already written to see how their code is doing.
  5. 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.

About Bob Hartman

Bob is founder of Agile For All and an agile trainer and coach. He never leaves home without his "NO" button.

Comments

  1. Amen!

    I consider this one of the many symptoms of mini-waterfall. I guess kayaking over a 25-foot waterfall every month is better than doing Niagara Falls in a barrel every 18 months, but I agree that it’s not what I’d call Agile.

    A related symptom that makes me crazy is having a “stabilization” period during the iteration. My solution: stop making things unstable all the time, and you won’t need that.

  2. Yes – you make a mockery of velocity calculations if you are adding further critical work to the backlog almost as fast as you burn it down! It’s one form of project “creep”, one of the parameters to my iterative development calculators which you’ll find from the sidebar of my positiveincline.com site. Do please give them a whirl, tell me what you think!

  3. Dear All,

    This post closely relates to one of the questions that I have about scrum (see Q1 below). I’ll post all 3 questions here, if anyone knows the answers, please let me know.

    Thank you for your help!!

    BR,
    Jozsef

    I am a programmer working at a company that uses scrum. I have worked here for 10 months now but I still do not understand some of the rules of scrum. I wonder if anyone here could answer my questions.

    Q1: During every sprint we are supposed to deliver a fully implemented and QA-d features. In theory it means that during the last 3 days of a sprint a developer cannot work because his work would not be tested (we have a large and complex app, testing every feature takes lots of time). Also, during the beginning of a sprint in theory QA does not do anything, before the first new feature is implemented since everything was perfect at the end of the previous sprint. Of course in practice things happen differently, but this is my understanding of what we try to achieve. What is the resolution? Is it a good approach to say that QAing a feature should be done in the next sprint, so no feature should be planned for 1 sprint?

    Q2: Our team is organized around a feature, not around technology, and we have a several layers application built on completely different technologies. Therefore in our team we have an SQL expert, some ASP.NET programmers, some C++ guys, a driver developer and some qa people (we have 11 members). We also have external dependencies, because we implement an add-on into a platform, so of course we depend on everything in the platform. Now when it comes to estimates, you can give 1 estimate (story point) to each PBI. But since we take on work based on priorities, it can happen that from 70 story points, which is our average velocity, 55 would have to be be implemented by the single SQL guy and e.g. the C++ guys do not do anything. In this situation, is there a problem with how the teams are organized, or should the PBIs be separated into “horizontal slices”? Or where is the mistake?

    Q3: What is the usual way to manage team dependencies? As I have said, we are developing an add-on into a large platform. Is it something usual that every team changes code until the last minute and then there is a hardening sprint and that’s it for testing? Or is it usual that we turn to dependencies/gantt charts: PBIxxx has to be implemented before PBIyyy can be picked up. In this case of course PBIxxx and PBIyyy are not vertical slices.

Trackbacks

  1. [...] is basically a version of the code freeze during an iteration antipattern.  It is all too common for an organization which switches from waterfall to agile to continue to [...]

Speak Your Mind

*