After the Code Freeze. What Next?!

I’ve been asked numerous times to share my thoughts on the best activities for developers to do after a code freeze. So, here goes.

When I first came up with my little list, I applied a few simple guidelines. Would an activity…

  1. harm or disrupt the current iteration;
  2. negatively affect planning or future iterations;
  3. be easy to halt or postpone if necessary;
  4. provide value to the team, the process, or the business?

I found the four activities below a great place to start.

Note, my list is most appropriate for teams engaged in an iterative development process. Although I suppose a waterfall process might apply as well, the fundamental assumption here is that there is a transition, or hand-off, from development to QA.

Four great activities for developers to do after a code freeze:

  • Support the QA Efforts - Software delivery is a team effort. Support the QA team wherever and however possible. I encourage developers to stay as engaged in the testing process as much as possible. I’ve found that QA teams often get overwhelmed by the volume of testing, typically caused by undocumented scope creep or a general lack of upstream visibility, and appreciate the added support of the developers. At the bare minimum I think it’s critical that the developers not start work on the next iteration. [ed. Reminder to self: write about soap ball development, bankruptcy iterations, and context switching.]
  • Focus on Research and Spikes - Tackle necessary research and get prepared for the future. I’m a huge fan of spikes. I think, if done well, they can spotlight uncertainty and provide a simple mechanism for answering larger questions. I’ve found the gap between development cycles to be a natural time box and a natural opportunity for deeper technological exploration. I also encourage teams to schedule spikes for iterations, if the level of uncertainty, and the importance of the research, is great enough.
  • Housekeeping - Focus attention on the development ecosystem: VMs, source control, test runners, continuous integration (CI), information feedback, communication tooling, etc. What better time to maintain the tools of the trade then while ramping up for the next development cycle?!
  • Low-Hanging Fruit - Knock out tiny defects that take less than an hour and have a low QA impact. I often encourage teams to maintain a list of low-hanging fruit (defects) for moments when a developer needs a quick change of pace - or after a code freeze, per the topic at hand. Not all teams can afford the time for context switching and not all QA teams like their iterations front-loaded but, depending on the team dynamics, low-hanging fruit can definitely move the business forward and shrink the backlog. Just like spikes, I encourage teams to schedule defects for iterations, especially if they don’t qualify as low-hanging fruit.

Like most things in life, I believe in learning from mistakes. I encourage teams to experiment and be willing to course correct where needed.

Thanks for reading.