The S Curve
The worst question in software is, "When will it be done?" because it never correlates with, "When should we ship?"
These questions involve guesswork, but a little science goes a long way. We'll define Done as, "When outstanding tickets reach zero." Graph the ticket count over time, and we have burndown charts.
Ideally, they looks something like this:
By halfway through the project, we know exactly when it'll be done! That's assuming you work somewhere where, "It's done when it's done."
Real projects have time constraints, and charts look more like this:
That cliff is a sign of so many problems.
When it's clear a release won't make a deadline, teams enter "crunch mode." They work long hours, leading to fatigue and poor judgement. They cut corners, accumulating technical debt and leaving things unpolished.
When code thrashes in the days before submission, there isn't enough time to really observe the effects of your changes. The worst bugs arrive at eleventh hour, preceded with, "This is totally safe!"
Long term, this is unsustainable. It burns out people, and in my experience, the best people only want to work on things they're proud of.
This can be fixed. Instead of using burndown charts as a visualization after-the-fact, make them a target. Instead of using a linear slope, make it an S-Curve.
To get here, we take a more thoughtful approach than just clearing a queue of tickets. Partway through the release, we survey our progress and shift focus to Convergence. As we wrap up our release, we prioritize quality during Bake.
Convergence
Maybe a feature takes longer to build than you expected, or it's tangled in an API dependency. You can charge ahead, but you'll run over that cliff.
The longer you work on features that aren't ready, the more likely you'll fall victim to the Sunk Cost Fallacy, shipping something half-baked just because you worked so hard on it. You prevent this by shifting toward convergence.
When you're knee deep into a release, you have a good idea what features will and won't make it. Designs aren't ready? The service API isn't staged? Kick them to the next release. Focus all your resources on finishing features you're confident about. When you kick off convergence, the most important job of a product manager is saying "No."
Bake
As you approach the submission date, create a release branch. All changes to that branch require approval.
The goal is to decrease code churn. With QA focused on metrics like crashes and bug reports, you target critical bugs. A measured approach to change reduces the risk of new, unknown bugs.
In the real world, you make concessions. Really, cutting the release branch is about drawing a line in the sand. The default is no longer, "Sure, merge it in." There is a bar for accepting changes, and your job shifts to risk assessment.
"Is it worth fixing this bug, even if it could introduce a worse one?" Every day you get closer to submission, raise the bar, until you only accept fixes for critical bugs that block the release.
That doesn't mean your developers twiddle their thumbs for the next few weeks. They're still investigating open tickets, and fixing bugs on feature branches. It's your call whether patches land on the release branch, or they're moved to the mainline branch for the next release.
The burndown chart continues to shrink after cutting the release branch, not because you're actually closing the bugs, but you're pushing them to the next release.
Websites often roll out features to 1%. Ops use these "canaries" to measure the stability of systems. If everything looks good, they make the call to ramp up to 100%. In an app, QA acts like ops; during bake, their metrics include crash logs and bug reports.
Every app nowadays has a backend to dynamically enable features, so can't you do this via rollout while in the App Store? Yes, you should do that too, but by the time you're in the App Store, it's too late. If you run into any sort of problem, it'll take a week to push out an update. The purpose of Bake is to fix critical bugs on a shorter feedback loop.
And Now The Hard Part
The challenge of this system is culture. You need to kill the notion, "We haven't submitted to the App Store, so the codebase is fair game!" The goalpost has to move from Submission to Bake Week.
Punting features terrifies stakeholders. The worst case scenario comes to mind: "The feature is days away, but we have to wait a whole month to ship?!"
The paradox is that by cutting features, they'll probably ship sooner. When you acquiesce, and include features that aren't ready, you hit critical bugs. If you ship too early, you waste all your time putting out fires. If you delay submissions, you learn there's always just one more feature you need to get in.
Look at you releases as a "release train." It's leaving on time, with or without you. The beauty of this system is that if you miss the train, it isn't a problem. The next one is leaving shortly, and it's always on-time.
