Approaching a year, my team has been doing Continuous Delivery without Test Automation (or with very little test automation). We've lived a timeframe of quality over schedule, because with the chosen strategy, any feature we're working on gets released when it is done. If quality isn't up to par, the feature stays in development longer. We measure lead times and discuss reasons things start taking longer and have two common causes of delays: 1) not knowing how to to split the item and thus working with too large chunks, 2) skills and lack of pairing/collaboration to even up the gap.
Yesterday we talked about the latest significant feature we're working on: changing the user interface. It's one of these features where we don't do all of it at once, but the chunks we're doing are still quite significant in size. And there's unexpected side affects, throughout the application. But it's approaching ready and while we don't estimate work, we talk about ideas on when it would be in production. And we said to target Wednesday. We talked about the idea of "freezing" user interface look after the release until a major sales-related date about a month from now, and I was under the impression that we would understand it means that we deliver this feature as done without having to go back to it.
A day later, the time of deciding on whether we'd release it was at hand. From the undercurrent of the comments, I could see something had changed: it was "ready for production whenever we feel like putting it there, we can always fix it later". I was puzzled.
We had a discussion again on the basic idea: we work quality over schedule. Mentioning a schedule never means commitment to schedule over quality. For problems, we stop and fix, and then move on.
It's interesting how easily, even with the experiences we have as a team, we were about to slip back to working against schedule. All it takes is a bit of wrong emphasis on a deadline.
