Every Team’s a Snowflake

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:

1. How often do we release?
2. Do we offer a preview release?
3. Do we support multiple versions?
4. 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!

The Internet Confessional: Why SaaS is Scary

Forgive me, Lords of Cobol, for I have sinned.

Why am I putting this out here? Mainly because, as this blog post by Sinclair Schuller notes, there is almost NO discussion of release management in SaaS. It was a relief to find Sinclair’s post, if for no other reason than to validate my  sense that yes, transitioning to SaaS does indeed have a significant affect on releases and versioning. In light of how little is written on this, I’m going to document my company’s transition here in the hopes that it helps others in my shoes.

My company is careening/dragging its feet (depending on your perspective) towards adopting an actual SaaS deployment model. This is, on the whole, an awesome development and one that we absolutely need to succeed. I’m in full support of it. It’ll be good for everyone in the company:

• Developers and QA can keep delivering value with fewer interruptions
• Easier prioritization on Product (no need to fit things into monolithic chunks of code and time)
• Tech support can get bug fixes to customers faster
• Client managers won’t have clients waiting for months on a new release
• etc.

There’s a fair bit of evangelism needed around all of this, but I’m confident we’ll get there, and fast.

But.

SaaS, right now, is stressing me out because I’m the release manager. I don’t know how to transition away from a versioned monolithic model, I’m still trying to get my head around GitFlow, and I have some major shifts in practice coming at me fast with a lot of stakeholders to satisfy. I’m not even sure that my concerns are coherent, but I’ve gotta start somewhere, so here are a few things that come to mind when teams say “we’re going to release every sprint” or “we don’t actually have builds like SVN anymore…”

1. We have bugs. Yeah, all software has bugs, but seriously? Production? Right away?!
2. How am I supposed to track this every single sprint? Just a list of new features? Version number? Documentation?
3. Are we enabling the new features every single sprint or are we hiding them?
4. If we’re hiding them, how?
5. What does that mean when we actually make these features available to customers? and…
6. How is this different than what we do now?
7. If we’re hiding them, why are you rolling to master and not release anyway?
8. If we’re not hiding them, what are you thinking?! New features every sprint would require a fundamental change in how we deploy to customers and how we educate them – which is definitely possible, but…
9. Did we forget that we have customers still using IE6? These are not people who upgrade quickly and may not accept a SaaS/rapid release model.
10. Did we think about how we would educate Tech Support, our Sales team, our client managers, and our Marketing team?
11. Did we think about how we would have to do that EVERY sprint if you roll to production with enabled new features?
12. Or did we decide that we want to work this way because it’s developer-friendly?

Enough for now. That was productive, I put words to some worries. But what can I do about it?

Well, I’ve started having hardcore conversations with our architects about their vision for how our products and releases work now, and how they’ll work in the future. I’m a visual person, so I’ve also started creating my own diagrams to show the Before and After. From that, I’m hoping to start drawing out the differences between the two models, and use that to figure out how what affects the nitty-gritty details of the release process. I’ve watched the CodeSherpa’s video on GitFlow, just to try to get my head around the tool most teams are or will be using, and understood about 25% of it. But it’s a start. Right?

So please, if you have advice, let me know.

Release Management Perceptions

As tends to be typical at smaller companies like mine, people wear a lot of hats. I have two primary hats: I’m the release manager as well as one of the scrummasters. (Depending on your terminology, I may be more of a “release coordinator” than manager, since I’m not actually deploying to production.)

This role has been in the forefront of my mind the last few days. There seem to be a few different attitudes in the company towards the RM role:

1) Arbiter of Production-Quality Code 

This tends to be a high-pressure and not really accurate, not for me at least. I rely on the scrum teams to tell me what is ready to go and what’s releasable. (I’ve been trying to put this responsibility on the Product Owner, actually, since they accept what the teams build.) I put the builds that have been approved for release on the release server and that signifies to the rest of the company that the code can be applied in production.

This attitude is mostly found in the people wholly dependent on the release server and who feel the heat fastest if something goes wrong. Not surprising – that release server is pretty much gospel to them.

2) Air Traffic Controller

Maybe bouncer is a better description – I might not know everything about every detail, but if it’s not on the list it’s not getting into the party on the release server. I know enough to throw a flag if something doesn’t feel right, and I know the questions to ask. I can’t do everyone’s job for them, but I can be the final sanity check.

Maybe I’m the only one with this perception of the role. : )

3) Formality

Here, the release manager and the release process is basically irrelevant except for the t-crossing and i-dotting. This attitude tends to go hand in hand with “dammit we need to get that customer up NOW whether you’ve approved it or not.”

This tends to come from the developers and technical managers, or from anyone who self-identifies as “not a process guy.”

Different attitudes, different needs across the company. Always the challenge.