This week at Primal Fusion we decided not to release an update to our thought networking service.
We had a completed update ready to go, but as we reviewed our work prior to release it was clear that there were design issues that we were just not comfortable with, and we didn’t have an obvious solution. How did we end up in that situation? To be honest, we made design decisions in haste without fully thinking them through. That became obvious during the review.
The decision to not release was tough because we had gotten into a great rhythm of regular releases. It was also easy, though, because we knew that we had another release in the very near future and correcting the issues was the right thing to do. In fact we have since corrected the issues and we’ll deliver our next update soon.
In my last post I wrote about the challenges of integrating UX with Scrum. I have to say, though, that once you get into the habit of regular releases after each sprint, it’s a great feeling to see a new one go out the door. A new release is a great motivator.
The flip side of that great feeling is the less-than-great feeling that comes with deciding not to push a release out. We’ve learned, though, that it’s not fatal to decide to not release the work that we do in a sprint. A course correction is acceptable once in a while.