Tag: best practice

  • Best DevOps Practices for 2017

    Best DevOps Practices for 2017

    Because the idea of DevOps is still so new, we’re continually having to hone what we view as best practices. At the start of the new year, many people make their own personal goals clear for the year (regardless of whether they intend to keep them), but we tend to head back to our work desks without reassessing how our projects are going. We just jump back in unquestioningly and continue down the path we were on before the holiday.

    Mindless plodding away at a goal that had been set too far in the past is perhaps the biggest business mistake we can make. Re-evaluating our approach is often the difference between stagnation and real innovation. A willingness to change tacks and the agility to do so speaks volumes about an organization—that flexibility is rewarded by a market that demands responsiveness from its providers, and it can be a big differentiator between a company and its competition. With that in mind, there are six big goals that we can adopt as DevOps practitioners that will have enormous results on our ability to answer the demands of our users.

    Make paying off debt a priority

    Most companies are so saddled with technical debt that they hire more people just to cope with it. This is like putting more hoses on a forest fire. When fighting a forest fire, a portion of the team creates a firebreak to deprive the fire of fuel. Likewise, organizations need to dedicate a portion of their workforce to do nothing but eliminate the technical debt that is fueling their operational fires.

    Set ambitious goals, but don’t sweat the details

    Have goals and objectives, but allow the minutiae to be developed over the course of short intervals. We need to set business-level objectives for our DevOps teams, but we have to be careful to not overprescribe the details. There are many DevOps tools and methods and more arrive every day. Plan to work in two- to four-week sprints with measurable outcomes, instead of six-month project plans. Use the feedback and lessons learned from those short sprints to inform the next sprint’s work.

    Don’t leap, but get moving

    DevOps is meant to be about quickly moving product from left to right. A common mistake is for companies to wait for “the perfect moment” and then jump headlong into DevOps, creating a lot of disruption at once. This is a recipe for disaster. Identify workstreams that are ripe for improvement from DevOps and start by moving one new benefit from concept to production. Remember, single-piece flow is your friend.

    Identify the ‘credit hawks’ and neutralize them

    I once heard the saying, “Just because you run out in front of a parade doesn’t mean they are actually following you.” One of the critical pieces that makes DevOps work is a culture of sharing. That means sharing in knowledge, work, credit and blame. A “credit hawk” is someone who likes to jump in front of work already being done and claim he or she is orchestrating it. This seems to be commonplace in situations where DevOps teams exist under mid-to-upper managers with “old guard” mentality. If they take the credit, that leaves the DevOps team with the blame. Neutralize the credit hawks at all cost; they will undermine your culture.

    Plan for failure, success through learning

    Planning for failure does not equate to “expect failure,” but because we want to move faster so we can try more things, the law of averages tell us that we will also fail more, too. Planning to fail means we know how to conduct a blameless post-mortem, understand lessons learned and incorporate that feedback cycle to increase the likelihood of success.

    Promise to break the rules

    Your DevOps team needs to be trusted to find the best path, even if that means ignoring a 70-year-old process. This statement might invoke a knee-jerk reaction, but this does not imply “anything goes.” Your objective is to find more productive ways to get product to market and to create safe systems of work. Part of your lease to your DevOps teams also should be to explore new processes that eliminate red tape, bureaucracy and waste. What has worked for the last 70 years may be what is holding you back today.

    2016 rewarded those who were able to move fast, and 2017 promises to require us to move even faster. By resolving to make these changes in your company or organization, you are making a commitment to shed the shackles of yesteryear. When freed of these fetters, your application teams will be able to focus and deliver on the one thing we are all trying to do: deliver value directly into the hands of our customers. Is 2017 the year your company will triple its release cadence? Is this the year you deliver every new product into all markets simultaneously? Or perhaps this is the year when your applications suffer zero outages. The goals and the stories are yours to tell, but one thing is for sure: Resolutions without action are just wishes.

    About the Author / Adam Bowen

    Adam Bowen is an information technology leader with more than 15 years of experience in technical, sales and senior leadership roles. As the Worldwide Innovation Lead at Delphix, Adam works with thought leaders of the Global Fortune 100 to eliminate key business constraints through innovative new  processes, offerings, and technologies. Connect with him on Twitter and LinkedIn.

  • What is a DevOps ‘Best Practice’?

    What is a DevOps ‘Best Practice’?

    In IT, we love our frameworks. Whether agile, ITIL, lean, cobit, six sigma or others, our thirst for “best practice” guidance seems to be unquenchable.

    The concept of a “best practice” is an enigma. Who decides if a practice is actually the best? And best for whom? While an “adopt and adapt” mentality is advocated in most frameworks, there is still a tendency to benchmark efforts against and conform to published best practices. Whether promoting “best in breed,” “world-class,” or “best practices,” many organizations swing these terms around as some form of competitive advantage.

    Is it really? Shouldn’t business outcomes be the real competitive advantage and measure whether IT’s practices are really the “best” to meet customer requirements?

    The DevOps Institute was founded in 2015 as a global learning community for emerging DevOps practices. Since our launch, we have intentionally avoided any reference to DevOps “best practices.”

    We believe that DevOps practices are constantly emerging and, in many cases, being proven in the wild.

    Through research, interviews, conferences and the experience of our Regents and partners, DOI’s goal is to identify, capture and share emerging DevOps practices through knowledge, education and certification models that best serve the learning community and enterprise IT. We feel it is premature to certify an individual as an “Expert” or “Master” when the expertise and mastery needed for successful DevOps is not clear and may not be appropriate in a single person.

    DevOps is fairly young. It does not have a single body of knowledge. There is disagreement on whether it is a philosophy, movement or framework. Despite that, DevOps is crossing the chasm from innovators to the early majority faster than any other IT framework. Why? Perhaps it is because DevOps speaks to many of the cultural and technical challenges that IT has been amassing for years.

    So instead of focusing on best practices, let’s agree on DevOps’ core principles:

    • Go faster
    • Shorten feedback loops
    • Experiment and learn
    • Cultural transformation
    • Deliver business and customer value constantly and consistently

    No doubt, some practices have clearly risen as being critical to the realization of DevOps’ core principles:

    • Agile software development
    • Continuous integration
    • Continuous delivery pipelines
    • Automated and continuous testing
    • Proactive monitoring
    • Improved communication and collaboration

    Still, over the past year, DOI has seen additional practices gain interest

    • DevSecOps/rugged DevOps
    • ChatOps
    • Agile service management
    • Lean
    • Immersion practices (Garage, Lofts, Dojos)
    • DevOps teams

    What will emerge next year? Who knows—but that’s the exciting part of DevOps. As time passes, there is less contradiction and more supplementation. Each emerging practice seems to complement and fine tune what came before.

    Even without a standard definition, DevOps is already encouraging organizations to examine their proprietary practices, identify gaps, assess their automation and, most importantly, engage in collaborative discussions. Transformations have taken seed without defined best practices. That’s awesome! Let’s not quell the momentum by attaching a static set of best practices.

    Will DevOps’ best practices eventually be agreed? Maybe. DevOps touches almost every aspect of IT management—people, practices and automation. That’s a tall order for a set best practices. Certainly some will try to publish their version of a “definitive” DevOps body of knowledge. Even “The DevOps Handbook,” an important book publishing later this year, was built as a collaborative effort between many of the early founders of the DevOps movement. Their perspective and insight will be awesome but not finite.

    I understand the frustration by the lack of a single body of knowledge and prescribed best practices. In past frameworks, the body of knowledge was both a enabling tool and constraining limitation. Bodies of knowledge are difficult to keep current. For DevOps, let’s embrace the concepts of spirit of sharing, collaboration and continuous innovation by promoting an inclusive and collective body of knowledge of emerging practices.

    If we settle on a set of DevOps best practices, are we actually inhibiting the very values that we are trying to instill? I hope not.