I referenced a blog post by Sinclair Schuller in my last post, where he says there are at least four key questions when transitioning to SaaS:
- How often do we release?
- Do we offer a preview release?
- Do we support multiple versions?
- Do we have a parallel release environment, or are we constantly merging new features straight into the existing production world?
I can answer those questions for our current model: 2-3 months, no, yes, and parallel. My company makes several distinct but dependent products: basically we provide a server, the APIs, and a few clients. Right now, we have a release model where all of these release in lock step. (In theory. Reality has been different for some time.) In the shiny new SaaS world, each of those (server, API, clients) will release differently. Each client can release separately as well, on its own cadence.
Bottom line, the amount of variation and differing schedules here is potentially huge. Which is fine – as long as we have a standard meta-process that makes the end result uniform for all products. Right now, that process is highly dependent on branches and build numbers: devs build, QA tests, POs accept, and then POs give me the accepted build numbers and that’s what goes on to the release directory for safe keeping. Those build numbers are gospel, but my understanding of where we’re headed is that the build numbers are nearly irrelevant.
So. Don’t really know what to do there, assuming that I’m actually understanding things properly. This goes back to my previous question list – are we hiding new features via if/else statements or something, where is that done (api? client?) etc. I have a meeting with one of our architects early next week, and I’ll start throwing these questions his way (as well as the four questions at the beginning of this post) and that should be instructive.
Once the whole meta process is figured out, I’m not entirely sure how I’ll managed all of these schedules and releases while still running two scrum teams. Handling the releases now is a fair chunk of work, and I’m not looking to expand that part of my job. My long-term vision is to have scrummasters on each team in charge of managing the release of that team’s product, but we’re not there yet. Right now all of our scrummasters are also developers or managers, and I don’t want to put more on their plates. But… maybe we’ll get there sooner than I thought!