We do short release cycles at Bottle Rocket. Mobile technology has called for smaller code bases, but I don’t think it’s just this industry has this issue. The days of being paid per line of code, or large applications being seen as higher quality, are over. To allow for pivoting product priorities, easier maintenance, and faster refactors, companies worldwide are in the middle of slicing their platforms to allow for more agile development.

At the end of every release, there are a few days of code freeze to solidify the release candidates for our clients. It’s not revolutionary, and every company handles code freeze differently. When my first project hit this stage, I talked to all of the appropriate leads and department heads to understand the entry criteria for the release sprint. I validated, completed feedback loops, and then asked the team to set off and deliver some amazing code.

To say it flopped on me would be an understatement. We finished, but it took longer than originally planned. More importantly, it was shipped with a ton of stress.

There were many factors outside of this conversation that had an effect. Talking to everyone on the team, they felt the main culprit for our challenging few days was highlighted by not understanding if we were ready or not. As a side note, this is the sign of an incredibly mature group of creators to see them quickly come to this realization. They are awesome for seeing this (among other reasons they rock).

My mistake was thinking all we needed to do was ask the right questions. If everyone says they understand what’s expected, I thought, nothing should go wrong. Instead, we should have detailed it together.

The retrospective revealed that even though we all knew what was expected, we looked at entry criteria in generic terms. Instead, we should have looked at our current release. Conversation needed to be had surrounding particular polish items, highly rated bugs, and non-functional pieces missing. So, when we hit the next freeze period, you can bet we had that discussion.

Questions started flying around the validity of certain items and how necessary they were for release. Both Android and iOS platforms had their specific problems that still weren’t solved. In the end, we realized we needed another day or two before we hit our freeze period and entered with a full understanding of how we needed to finish this sucker off.

What resulted was a much shorter frozen period, and instead of looking at each other in frustration, we were joking around and delivered amazing builds to the client that were immediately accepted.

Best part, they aren’t done “defining ready”. The retrospective showed they want to do this every single release, no matter how small. They want to constantly ask each other if they are ready or not. Instead of resting on our laurels, we want to do that with every new feature, API integration, or client review.

Beauty of this conversation is it never gets stale. “Ready” may change for your team as it grows and matures. You may want to start delivering art sooner or later. Testing may want to happen side by side while integration happens. Development may want to perform a research spike before taking a stab at a feature. Process can be added or subtracted, depending on your comfort level.

Regardless of the day or stage in your release or sprint, dare to ask your team to define “ready” for you. Might be surprised at the results.