3 ms·
With shorter release cycles, there's also less pressure to ship half-baked features. If you know the next release is just four weeks away, then slipping a featu
by cpeterso 7y ago
With shorter release cycles, there's also less pressure to ship half-baked features. If you know the next release is just four weeks away, then slipping a feature one release is rarely a huge deal. But if the next release is one quarter or one year away, teams rush to ship now and fix bugs in production later. Overall product quality will take a hit at every release.
- zbraniecki 7y agoAnother thing that I observed in our culture since we switched is that it is easier to coordinate cross-team efforts - if I know X will be done in Fx70, I can plan my work on top of it for 71. Such logic is commonly performed without releases until you start depending on multiple features in multiple places. Then it saves you. The same "alignment" works also much better between engineering and non-engineering teams. Once we collect the focus areas and major features planned for release X, security, performance, accessibility, localization, platform integration, UI, UX, design, legal and marketing teams can prioritize their work to aid them. Having no release cycle, or long release cycle, dilutes this effort and reduces visibility. There is, in my opinion, somewhere, a threshold beyond which the release cycle burden outweighs the benefits and/or where the cycle is to short for teams to usefully react, but I don't think we hit it so far.
- wpietri 7y agoTotally. I think of this as the "next bus" effect. If you see your bus pulling up, do you run for it? If the next bus is in 5 minutes, no. If it's once a week, hell yes.