You Must Be This High to Ride the Continuous Bandwagon

There’s a lot of hype when it comes to continuous deployment (CD). The fact is that in large organizations, adopting CD takes changes to process, responsibilities, and culture (both technical and management). The right skills really help, but more often the determining factor to success is having the right attitude and vision across the whole team.

[caption id="attachment_395" align="alignnone" width="600"] (image via Yassal Sundman)[/caption]

At a carnival, you may have seen a sign that says “you must be this tall to ride”, an indication that the attraction is designed in such a way that it is dangerous to ride for those who don’t meet the specification. Similarly, continuous deployment sets the bar of requirement high, and some teams or products aren’t set up to immediately fit into this new methodology.

Mobile Continuous Delivery Requires Micro-climates

Mobile apps go through a validation process in an app store or marketplace before being generally available to customers, so product feedback loops take a hit in delay to market response to the app update. Mobile apps typically rely on back-end infrastructure which may require synchronous roll out of both front-end app and server-side components such as APIs and database schema. This is not trivial and for apps with thousands to millions of users.

Because of this delay, there’s huge emphasis on getting mobile app changes right before submitting them for review. Internal and beta testing platforms like TestFlight for iOS and HockeyApp for Android become vital to a successful app roll out and update strategy. For organizations that are used to 3 month release cycles and who control their whole stack, being prepared to release perfection every week requires a completely different mentality, often a completely different team too.

This is what I call product 'micro-climates', an ecosystem of people, processes, tools, and work that evolves independent of the larger organization. Mobile and API teams are perfect examples. A product needs to go at it's own pace, accelerate and improve based on its own target audience. Only when organizations align product teams to business goals does this really take hold and become effective.

Prove Your Success, Aim for a Shared Vision

I've never seen a Fortune 500 organically evolve to CD without buy-in from a C-level or at least VP. A single group can implement it, but will ultimately run into cultural challenges outside their group (like IT and infrastructure) unless they have the support of someone who controls both groups.

If you're trying to move in that direction but are hitting barriers outside your team, you've may have bitten off too much for now, and need buy-in from above (i.e. an executive sponsor). For that, you need:

• Proof that what you're doing is actually improving your velocity
  'DevOps' is a buzzword, but metrics that show how doing kanban/scrum with both teams in the room every day actually matters. If you aren't already capturing these metrics, I'd suggest you start. The point is to have quantifiable, objective measures that undeniably show success.
• How your success maps to your executive sponsor's goals
  An executive often balances potential opportunities with opportunity costs. If you're changing process, what's the risk to your actual project? How can this be replicated to other teams? What's at risk if you don't do this? Why are other competitors doing it this way too? What strategic objectives does this change enable (i.e. faster releases == competitive advantage)? Take a few moments to think about what your sponsor is measured on, and map your goals to theirs.
• A clear plan and schedule, not just a bunch of activity
  Adding one or two process improvements is one thing, that's actually our responsibility anyway, but to move to a model like continuous delivery/deployment you need a plan that includes objectives, strategy, and then tactics. For instance:
  • Objective: meet demand for new features, obtain competitive advantage in market
  • Strategy: streamline the delivery process to achieve 1-2 week release cycles
  • Tactics:
    • Continuous integration of code, multiple commits per developer per day
    • Minimum 80% automated test coverage
    • Test coverage over 5 key platforms and 3 geographic markets
    • Automated security reviews before each release (i.e. like this)
    • Tractability of code changes to production user impact metrics

If you've been bitten by the CD bug, it's more than just an itch to scratch. It takes some concerted effort, particularly in large organizations, but don't let that hinder you. Get your own team on board, find your velocity metrics, link your proposal to executive goals, get that sponsor, and commit to an implementation plan. Others have done it, and so can you.