I mentioned recently that it’s time to shift your focus from getting things “done” to being “ready”. What follows is a more specific, actionable post about what that means for your team (assuming your team, like mine, is responsible for delivering software solutions)…

Another Devops Definition

If you are in a technology industry today, you are talking about “Devops” (or “devops” or “DevOps”). Business leaders are gravitating toward that term in droves. Before the genie gets out of the bottle, though, and you’re asked to spin up a devops team, I felt it best to set the table for a valuable conversation. I’d argue that devops, done properly, is about being ready for success. Let’s break down what devops means:

• Devops is not a tool, a team, a process or a technology. It is a culture. At it’s heart, it is about an organization focused on a single definition of success. I can’t begin to prescribe what success means for your organization, but it is generally about making customers happy with outstanding products or services. By bridging the gap between the software development lifecycle, IT service management, and business process management, devops establishes a unifying purpose and quantifiable behaviors for every individual to contribute collaboratively to the success of the organization.

Why Does it Matter?

The one thing we can count on in technology is change. In order to be responsive without being reactive, we need to agree on the some fundamentals. With the pace of change in our lives, we must be capable of truly letting go of the notion of getting “done” with our work. We are never “done”, but we must always be “ready”.

Since I tend to think in lists, I’ve built one here to help communicate what it means to be ready. I think it goes a long way to helping an organization adopt a devops culture. Unlike a traditional “checklist”, though, this post should serve as a roadmap throughout the lifecycle of an application/product/solution. Your team can then assess each stage of the lifecycle with full transparency, staying honest with themselves and their stakeholders as they travel the feedback loop together.

Even if adoption doesn’t make sense in all cases, or one team’s definition varies from another’s, the goal remains the same: Begin with the end in mind. Communicate, collaborate and commit to shared accountability for a successful solution. If you decide that a piece of this list doesn’t or shouldn’t apply to your solution, at least you’re making that decision in full light of day. Do what makes sense, and keep expectations clear with absolutely everyone. That is the mark of a technology professional.

Caveat: Don’t use this list as a project plan. Use it as a reference. Go off and prove concepts. Write code. Exploratory work is critical when you kick-off a project. Just be prepared along the way. If you think the launch is the finish line, you’ve already failed.

The Definition of Ready

1. Success is defined. However your team defines success, there must be a single definition. Everyone who has a stake in your project has to be clear what it means to succeed. Without this building block, all the best developers or ops teams or salesman can never be enough.
2. A solution is developed, reviewed, and tested. Whatever set of standards and best practices you decide to adopt (or create), follow them when you develop software. Hold each other accountable to them when you conduct peer reviews. Use them to help the whole team find and fix bugs in testing.
3. The solution is documented. People understand pictures. It doesn’t matter if your team is full of ninjas or rock stars or gurus or whatever other term is en vogue. A solution is not just for developers, or even technical folks. Just draw a picture of the solution and its integration points. If you ever need to consult an outside expert or vendor, or hire a new employee, you’ll be glad you have it.
4. The solution is deployed and accessible. Ideally, you have a handle on continuous delivery. Ultimately, though, you simply need to understand how and where your solution gets deployed. That includes the stages through testing and staging and production. Does the team understand how changes make it to a customer? Is everyone responsible for supporting the solution capable of accessing it?
5. The solution is monitored. Every production solution needs monitoring. I can’t begin to tell you how detailed yours must be. Just be sure that your solution issues relevant, clear and identifiable information when a fault occurs and is being monitored for both faults and performance. Keep in mind, too, as it relates to operations: faults must be actionable. If they aren’t, get comfy with the pager.
6. The solution has clear diagnostics, escalation and remediation. Your solution should be capable of being “smoke tested” with clear red/green results. Those results, just like any faults caught by monitoring, need to be clearly understood by all parties. That includes troubleshooting steps, known workarounds, automated tooling, etc. The point here is to be planning for what can break, how to fix it, and when to call in the experts.
7. The solution is built for high availability and disaster recovery. Are you prepared for a catastrophic outage? Are your customers? Simply checking this box because you deploy to the cloud isn’t going to cut it. Is you solution capable of being completely redeployed to a different environment in a minimally invasive manner? Get rid of secret sauce and tight coupling to environments.
8. The solution provides adequate reporting capabilities. You will be asked for data. Big or small, performance, usage, financials, outages… There are many interested parties. Be sure you are setup to provide answers. If you solution is not capable of providing data for analysis by stakeholders, you’ll be on the spot more often than not. Be ready to answer the questions you’ll get.
9. The solution is staffed. Technology gives us tremendous scale, but there are still people charged with keeping it alive. When there are enough people and they understand how to do what is required, customers never know they exist. That’s a good thing. Remove the people (or try to get by with too few), and the customers will know one person: You.
10. The solution has been communicated. Ultimately, your solution is not yours at all. The product or service you provide and this entire checklist is designed to be shared with the people who are staking their time, money or brain power on the success of the project. I hope you use this checklist as a point of reference to keep everyone on the same page. They need to know if you’re ready. So tell them.
11. Repeat. Iterate. Work hard. Play hard. End of the list. Thought you were done? You’re not done. You’re ready. Ready to do it again and again and again… That’s what success looks like. Congratulations!

There you have it. That’s what I’ve learned in my career at many companies, small and large, new and old. Another thing I’ve learned is that there is much more to be learned from the perspectives of everyone else who’s breathing right now. So, leave a comment or a question. I’m ready to keep learning!