A decade ago, development teams were falling all over themselves trying to implement Scrum. Iterative software development wasn’t a new concept, but Jeff Sutherland and Ken Schwaber had formalized a framework whose main tenet was the rapid development of small-batch features with a concrete feedback loop.
As news spread about the early success of some high velocity Scrum teams, stakeholders on troubled development teams began to see Scrum as a silver-bullet. These folks misinterpreted Scrum’s acceptance of change and lean approach to requirements as an open door for scope creep and a total pass on documentation. Many of those projects failed, forty-five minute daily standup notwithstanding.
Fast-forward to today, and software delivery is in a similar place. Fierce competition is pushing the pace of release cycles. Widespread adoption of the cloud has changed both the shape of software and how infrastructure is managed. An ecosystem of supporting tools continues to evolve in rather spectacular fashion. Stakeholders are taking note.
But before you decide to start deploying to production a hundred times a day or embark on a full-scale devops transformation, it’s critically important to understand where you are now versus where you’re trying to end up. Process for the sake of process is usually a losing proposition, or at the very least will drive away all of your good team members. What you need is a comprehensive roadmap with clearly defined milestones.
It will help to ask yourself three broad questions to get a better sense of where your’re starting and where you actually need to go. The answers to these questions will substantially inform your roadmap, will dictate how (and to whom) you sell your ideas, how you structure your team, what tools you choose, and so on.
What problem are you really trying to solve?
First, ask yourself what you’re really trying to achieve. Use the 5 Whys technique to get to the root cause if necessary. If, for example, you want to use Docker because it’s a super cool technology—and I agree, it is—well, that’s probably not the best motivation. If, on the other hand, your development team is consistently wasting valuable cycles on “it works on my machine” type issues because there’s no development-production environment parity, then Docker might be just the ticket.
Remember, the end goal should always be to provide more value to your customers. This is not about tooling, except in the respect that it can help you achieve that goal. Beware the shiny object syndrome.
The ultimate end goal of devops should always be to provide more value to your customers.
I recommend that you write this down. It should be concise and to the point—a couple sentences at most—and should illustrate the specific business value you expect to bring (e.g. “decrease costs by reducing the time spent debugging production issues” not “migrate the storefront to Docker.”) Post this somewhere that you can see it at all times to help keep you on course.
What are the current capabilities of the team?
Be honest with yourself here.
If your team is releasing buggy software to production now, releasing buggy software faster is probably not going to help your cause much. You may need to get back to basics before you taking on more advanced projects.
At an absolute minimum, you should have an established, automated developer testing standard that is consistently practiced by the entire team. This doesn’t mean that you have to be doing puritanical test-driven development. It simply means that you should have a well-defined process for unit testing code that can be automated.
Version control should also be a core part of your workflow, and you should have an effective branching/merging strategy in place. To wit, if you can’t reproduce an exact duplicate of your current production build from source control right now (yes, literally, right now), things like continuous deployment are on the distant horizon. You have some important work to do on other fronts first. If you’re not using version control at all, have a coworker slap you and then go watch this video.
It’s also important that you promote effective, high-velocity collaboration and provide the tools to support it. Teams that spend all of their time stuck in endless email threads or in meetings with no actionable outcomes are, by definition, low-velocity.
You’ll also want to identify and address any knowledge gaps on the team. In small- and mid-sized organizations, for example, devops doesn’t necessarily require a dedicated team, assuming that development and operations both have a firm grasp on the underlying concepts, fully buy-in to them, and have experience with the tooling that will be required to realize the end goal. Understand that you’ll likely need to make changes to the team or (even better) provide training to existing teammembers.
A comprehensive capabilities assessment will help identify these types of issues and allow you to make specific recommendations on remediation steps. Expect to spend a couple weeks interviewing your team, taking an objective look at your current processes, and compiling the results of your analysis.
Speaking of buy-in…
Is management on board?
Advocates for true, full-scale devops transformations often fail to recognize the gravity of what they are proposing. In most organizations, this is a massive cultural change with effects that reach far outside the IT department. How applications are designed, how they are built, how and where they are hosted, how constituent components are procured, how products are priced and sold, what SLA commitments are made, and countless other facets of the business are to some degree impacted by changes in how technology is delivered. The scale of this impact varies based on the size and type of a business, its product, and who its customers are, but one thing is still profoundly clear: sweeping changes to development processes will fail without management buy-in.
Period. You’re not going to change the way a technology business fundamentally operates or the culture around how it builds its products without some powerful allies and a ton of hard work. The trick is to be highly methodical and sell the concept to your peers and to management by demonstrating clear value.
Before you start selling, however, you had better put your house in order. Review your capabilities assessment, and make any necessary adjustments. Be sure your team is ready to deliver on the promises you’re about to make, before you make them. Have a comprehensive roadmap with clearly defined milestones that spells out exactly how you will get from current state to future state. Plan on moving in small, low-risk iterations that deliver clear value. You want to dogfood the process you are proposing as much as is possible.
Most importantly, focus on selling the value that automation and rapid delivery bring, not on the tools that you’ll use to realize them.
With some careful planning and execution, rapid delivery on a similar scale of sophistication as companies like github and Netflix is in reach for most teams. You have to start at the beginning and that requires that you know exactly where the beginning is (hint: it’s not the same for everyone.) Remember, rapid delivery is a byproduct of a high-functioning team, not the other way around.
How is your team working to provide more value by accelerating your delivery process?