Tag: DevOps transformation

  • Total DevOps is Needed, Plugins are Not Enough

    Total DevOps is Needed, Plugins are Not Enough

    Trace3 was proud to be a Gold Sponsor, exhibitor, trainer of the DevOps Institute leadership certification course and newest partner of CloudBees at the CloudBees Jenkins World 2017 event in San Francisco last month. Jenkins World 2017 attracted 54 sponsors/exhibitors, an 80 percent increase over 2016.

    The growth of interest and sponsors for this event demonstrates that the number of available tool choices for creating the continuous tool chains to realize continuous delivery and DevOps is growing. One of our top takeaways from Jenkins World 2017 is: Plugins are not enough!

    Indeed XebiaLabs’ “Periodic Table of Tools” is a valiant attempt to illustrate categories of DevOps tools and attributes of specific tools. Version 2 of the Periodic Table is now released, and I heard that version 3 is already on the way. While the table shows an impressive 15 categories of tools, I estimate there are actually 29 categories, if you consider tools for cloud management, test management, test creation, code analysis, code collaboration, ALM systems, dashboards, security and others.

    XebiaLabs’ table shows five attributes for each tool: open source, free, freemium, paid and enterprise. In my opinion, there are at least two additional categories: ecosystem and cloud readiness. While the table indicates 120 tools, my own estimate counts 300+ DevOps tools, including CloudBees, Electric Cloud, Perforce, Scalyr, Service Now, Tricentis. SmartBear, SonarQube, Parasoft, Coverity, Fugue, QA Symphony and many others.

    While the exact number of tool categories, tools and attributes is arguable, there are many tools to choose for a continuous delivery toolchain. The state of practice for integrating tools into a seamless toolchain is the plugin or do-it-yourself scripting. Anyone who has implemented a toolchain knows that the existence of tool plugins, while useful, is not enough. The quality and completeness of each plugin varies significantly. Some off-the-shelf plugins are so basic they are little more than marketecture. Even the best plugins are limited to a pairwise matchup between tools of specific version pairs, and not a universal tool or version. For example, a tool with a plugin for Jenkins version X may not function with Jenkins version Y or CloudBees Enterprise of other tools at any version.

    The DevOps Express collaborative initiative announced by 14 participating vendors at Jenkins World 2016 was an attempt to resolve the plugin problem. One year later, the DevOps Express website has shown a growth to 123 tools across 18 categories. However, just like the XebiaLabs Periodic Table of Tools, it is remarkable that the number of tool categories and tools that are not comprehensive (and lacking plugin compatibility) are not guaranteed for any combination of tools that may be needed for a toolchain for a specific enterprise.

    Each enterprise has unique toolchain requirements and preferences. Selecting and an integrating DevOps tools is not like buying a box of “standard” Lego bricks that are guaranteed by the manufacturer to fit together. Each tool and plugin is different.

    The choice of tools, the combination of tools and the integration of the chosen tools all must be carefully chosen to fit the specific customer requirement. More importantly, the integration must be architected to ensure the chosen combination works well together in a seamless toolchain.

    Until there is an absolute standard plugin architecture that all tool plugins are guaranteed to be compliant with, expert consulting services will be essential to make tools choices and make sure the tool chain works.

    With such a rapidly growing list of tools and vendors, only the most capable consulting teams with deep insight and partnerships with the widest array of tool vendors will be able to address enterprise DevOps solutions properly.

    — Marc Hornbeek

  • Go Big or Go Home: Total DevOps Guarantees Results

    Go Big or Go Home: Total DevOps Guarantees Results

    As revealed by a recent survey, only enterprises that implement an “all-in” approach to DevOps achieve the results of best-in-class enterprises seen in the “2017 State of DevOps Report.” Total DevOps approaches DevOps transformations holistically, integrating the full breadth of your DevOps value chain as well as the many stakeholders across your organization that must be engaged to ensure broad, enduring success.

    Trace3’s Total DevOps transformation approach uses the following steps:

      1. Identify the DevOps Leadership & Core Team. Your Leadership and Core Team members should be open to change, early adopters and innovator-types.
      2. Together as a team, set your true north and determine your big picture business goals for your DevOps journey. End-to-end pipeline lead time, release throughput, release quality, security, satisfaction and productivity are some examples of DevOps goal areas.
      3. Map the end-to-end (E2E) value streams specific to your chosen DevOps goals. Focusing on the goals your organization has for DevOps will ensure your team and organization are aligned and focused on outcomes.
      4. Identify bottlenecks for each value stream that will most affect each goal. During this step, gaps between current state and desired state are made clear.
      5. Dig deeper into the processes and further explore bottlenecks and gaps. Concentrate on deeply understanding how the relevant bottlenecks and gaps affect lead time to define specific improvement opportunities.
      6. Define solution strategies and tactics that align with goals and address improvement opportunities identified during analysis of current state. Total DevOps takes a comprehensive perspective of people, process and technology to define strategies and tactics.
      7. Develop an overall DevOps road map, which includes considerations for people readiness, process improvement and technology-specific implementation plans. Each of these implementation plans should incorporate change management or adoption enablement techniques.
      8. Determine how the existing technical debt will be addressed. Give highest priority to the backlog of technical debt that will most support the goals.
      9. Design metrics including key performance indicators (KPI) and service level agreements (SLA). The use of KPIs and SLAs will enable the ability to tune, track and validate the success of the solution.
      10. Implement! Agile iterations may include detailed design, proof of concept trials, implementation for one viable application environment and team and then deployment to all target application environments and teams using a well thought-out sequence and strategy for onboarding.
      11. Employ continuous feedback. Monitoring the performance of all application environments utilizing the established KPIs and SLAs will provide unbiased measurement of the system performance.
      12. Employ continuous improvement. Feedback is critical for learning and improvement which will fuel each step in your ongoing DevOps journey.

    Summary

    What do you think? Do you agree the Total DevOps steps listed above are important to achieving big picture DevOps goals? Are there others you recommend? For more information about Trace3’s Total DevOps transformation approach, refer to our perspective paper, “Navigating Your Total DevOps Journey.”

    While DevOps implemented using the Total DevOps approach provides a strong foundation for long-term enterprise business improvements, it is important to understand DevOps is not an island. Enterprises implementing DevOps should be aware that DevOps interoperates with other IT systems and practices. Enterprises are well-advised to choose tool-agnostic IT partners that can provide solutions that best suit the needs of each unique enterprise and can integrate and evolve DevOps together with all their IT systems.

    — Marc Hornbeek

  • DevOps Transformations Everywhere; Join Us To Watch, Hear & Learn

    DevOps Transformations Everywhere; Join Us To Watch, Hear & Learn

    For me and many others the best way we learn about DevOps is to hear others who have set about on this journey. For three years Gene Kim’s DevOps Enterprise Summit has been powered by hearing one DevOps Transformation experience after the next. The new DevOps Handbook has over 40 case studies of DevOps transformations. We here at devopsy.kinsta.cloud will be offering some great DevOps transformation stories this month that I wanted to share with you.

    First of all Monday afternoon (2pm eastern time) we will be having a webinar, “Leading Change at DevOps Enterprise Summit San Francisco“.  You can register by clicking the title or clicking here. The webinar will discuss leading DevOps transformation and features a pretty impressive cast:

    nicole-f-headshot

    Dr. Nicole Forsgren

    CEO and Chief Scientist, DevOps Research and Assessment LLC

    Dr. Nicole Forsgren is an IT impacts expert who shows leaders and tech professionals how to unlock the potential of technology change in their organizations.

    sam-g-headshot

    Sam Guckenheimer

    Product Planner, Microsoft

    Sam Guckenheimer is the Product Owner for the Microsoft Visual Studio Cloud Services, including VS Team Services and Team Foundation Server.

    scott-p-headshot

    Scott Prugh

    Chief Architect & VP Software Development, CSG International

    Scott Prugh is chief architect and vice president of software at CSG International and has been with the company for 10 years.

    j-paul-reed-headshot

    J. Paul Reed

    Managing Partner, Release Engineering Approaches

    J. Paul Reed has over fifteen years’ experience in the trenches as a build/release engineer, working with such storied companies as VMware, Mozilla, Postbox, Symantec, and Salesforce.

    screen-shot-2016-10-29-at-6-30-30-pmNext week devopsy.kinsta.cloud will be out at the DevOps Enterprise Summit, where we will once again have a video booth and will be interviewing most of the speakers at DOES, as well as many guests and friends from the DevOps scene. If you are attending and would like to sit for a video interview stop by during Monday or Wednesday of the show.

    Our videos should be up in a few days afterwards, so if you can’t make it to San Francisco be sure to catch our interviews of the speakers and others.

    Later this month we have another webinar that I am really excited about. It is again about DevOps transformation experiences. It features:

    johnhertzJohn LaFreniere is the Vice President of Global IT Architecture for the Hertz Corporation.

    ramanRaghunath Raman, Director, Digital Shared Services, API Delivery & Integrations, Corporate Services & Digital Technologies (CSDT), Kaiser Permanente

    sanjeevSanjeev Sharma, is an internationally known DevOps, and Cloud Transformation thought leader, technology executive, and published author. Sanjeev’s industry experience includes tenures as CTO and Worldwide Technical Sales Leader, Acquisition Integration Technical Leader, and IT Architect. As an IBM Distinguished Engineer, Sanjeev is recognized at the highest levels of IBM’s exclusive core of technical leaders.

    You can register for this webinar here.

    Beyond these there is IBM InterConnect on the horizon, CA World, where I will be speaking as well, also in November and our own DevOps Connect: CD Summits this month and next in Austin, LA and Seattle.

    So yes indeed DevOps Transformations are everywhere. There is much to be learned from hearing these stories. Sometimes more from the mistakes they made then from the success. Check these out if like me you are interested in these tales from the front lines.

    — Alan Shimel

  • DevOps Chat: Michael Olson, Puppet, A Roadmap for DevOps Success

    DevOps Chat: Michael Olson, Puppet, A Roadmap for DevOps Success

    devopsy.kinsta.cloud editor-in-chief Alan Shimel sat down with Michael Olson, senior product marketing manager at Puppet, to discuss a number of topics including the recent DevOps Salary survey that Puppet released. Another topic of discussion was the webinar Puppet is sponsoring and Michael is taking part in Sept, 27 titled, “A Roadmap for DevOps Success.”

    This webinar is a great jumping-off point for those who are looking to set off on their DevOps transformation or even anyone looking for a DevOps reset. Please click the link to register if you are interested. In the meantime, Michael gave us a great amount of information about the topic and DevOps in general. I think you will find it very interesting and useful. This interview is a little longer than our usual (about 20 minutes), but well worth the listen.

    As usual, the streaming audio is embedded below with a written transcript of our conversation below that. Enjoy!

    Shimel: Hi. This is Alan Shimel, editor in chief of devopsy.kinsta.cloud. Here for another DevOps Chat. Very happy to be joined for this episode of DevOps Chat with Michael Olson, senior product marketing manager at Puppet. Hey, Michael. How are you?

    Olson: Alan, I’m doing great. How about yourself?

    Shimel: Great. You know Michael, it’s a very exciting time here for Puppet obviously. A lot going on in the world of DevOps, in the Puppet world and everything else. So before we get started with anything, what I wanted to talk about, our upcoming webinar. Why don’t you give our audience a little bit of background? What’s the latest with Puppet?

    Olson: Sure. Yeah. Happy to address that and also say thanks for having us on the DevOps Chat today. It’s always good to catch up with you.

    Shimel: Thank you.

    Olson: So for folks out there who may not be familiar with Puppet, we provide a software platform that really helps companies and organizations automate the delivery and operation of all of their software. And the idea there being that you know in today’s world, software powers everything around us. More and more companies are recognizing the need to behave like software companies as a competitive differentiator, as technology is perceived as more of a way to improve the customer experience and kind of deliver better value to end users. And so we’re seeing organizations that are looking for automation as a way to ultimately deliver better software to their customers and end-users faster. And that’s really why Puppet exists. So, in terms of what’s new for the company, I would say it’s a great time to be here. We’re growing pretty rapidly. You know we’ve been adding new customers at a pretty astounding rate and really growing the organization and seeing a lot more momentum for organizations that are looking to adopt DevOps practices and more of a DevOps way of working, as well as seeing the role that automation plays in helping them get there faster.

    Shimel: Sure. It’s a great time to be alive in the DevOps space. You know Michael, I wrote an article just this week on the results of your DevOps salary survey, which was just released. You know coming out of the Puppet DevOps State of DevOps Survey. And it’s certainly a good time if you have DevOps skills and you’re looking for a job. It seems to be you know an employee’s market. So no doubt you know what we’re seeing and what you’re describing is playing itself out in that way as well. It’s where the jobs are.

    Olson: Yeah. For sure.

    Shimel: Yeah. Crazy. You know I have friends who aren’t in IT and I posted the article on Facebook and some of them read it and saw kind of what the salaries were. And they were like you know do you have to be a rocket scientist to work in DevOps that you know those are the kinds of salaries. And I was like no, but you know it helps. But honestly you don’t obviously, right. You just gotta be into it. But that brings us actually Michael, to kind of the subject matter of our talk today. Which is this webinar we have happening on I believe it’s September 27th. Correct?

    Olson: Yeah. That’s correct.

    Shimel: And Michael, why don’t you share with our audience a little bit about kind of what the subject matter of our webinar is going to be.

    Olson: Sure. You bet. So you know we spend obviously a lot of time at Puppet consulting with organizations that are either you know at a stage where they’re trying to build the business case if you will for change and for kind of evolving the way that teams work to deliver better software out to their customers and end-users faster. And we also talked to a lot of organizations that are you know looking for guidance on kind of you know how to scale a DevOps practice within their organizations. And you know I think the common thread that we’re seeing is that you know in this day and age in 2016, that DevOps really isn’t just for the unicorn companies out there if you will. You know the Googles and the Apples of the world. We’re seeing a lot more evidence that DevOps practices are really hitting the mainstream as more organizations you know realize they need to behave like software companies and improve the way that they work. And so really the goal of the webinar that we’re gonna be digging into on the 27th is kind of to provide a roadmap based on findings from the 2016 State of DevOps Report.

    Ways of driving adoption of DevOps practices within your organization. And we’ll kind of cover that from a few different points of view. One of which is you know how to sort of build the business case for a DevOps way of working. If you’re maybe sold on the need to change, but trying to get either peers or managers to buy into your point of view. And then we’ll also address some of the cultural changes that we see our customers implementing and share some ideas on ways to align incentives and teams to improve collaboration. And then we’ll dig into you know some of the key technical practices that we see high performing IT teams implementing. And then some guidance on just you know where to get started to start to scale a DevOps practice within you know an enterprise organization. So it’ll be a lot to chew off in an hour Alan, but we’ll do our best to –

    Shimel: I was gonna say Michael—

    Olson:  —hit all those subjects.

    Shimel: —yeah, it sounds like a full hour of webinar right there. But you know Michael, one thing I want to stress and it goes back to what I was saying earlier about my friends who saw the article on the DevOps salary survey. Thinking about my goodness, you know you must need to be uber smart or something you know to be able to do something like DevOps. But so much of what you need to you know make a horse you know have a successful DevOps journey and transformation, I don’t know if it’s really sort of book smart, or intelligence, or you know rocket science. A lot of it is cultural and you know we tend to poo poo it. But a lot of it is about working together as a team. Getting buy-in. Getting buy-in from your boss and his boss. Getting buy-in from your team members. Getting buy-in from other team members. And I don’t know if that’s really you know “intelligence” or you know it’s more of social aspect. Do you agree or what do you think?

    Olson: Yeah. Honestly I think that’s a pretty great point, Alan. And I’m a big believer here that you know DevOps is not something you can buy and it’s not specific technology. And I would be very skeptical of any software company or vendor that claims to be the DevOps tool. Because what we tend to see and hear is DevOps is really more about the cultural changes and the technical practices required to you know help teams improve the way they work. To deliver better value to customers and end-users. And so from a cultural perspective, I think you’re spot on. It’s you know how do we move from a culture of lack of alignment, of low trust, of silo-ed teams, to you know cross functional teams that share incentives, that are aligned around a common set of goals. That have that high trust where you can kind of complete the no look pass so to speak to other groups. And you know the outcome ideally being you know reducing cycle times. Getting software out the door faster that meets the needs of customers. And then being able to iterate and kind of foster an environment of continuous improvement. I see those as some of the key drivers behind you know what’s required for success with DevOps.

    Shimel: Agreed. But you know I don’t want people to think I’m giving them a false sense of it either, Michael. You have to have a good understanding of environments, of tools, of what it takes for a successful software release, of what it takes actually for you know IT to help the business, right. I don’t want people to think that DevOps folks are a bunch of dummies who happen to just be really social, right. There are tools and skill sets that you know are kind of required. And so that being said, why don’t we go in a little bit deeper in terms of things we want to you know kind of peel the onion back a couple layers in this webinar. You’ve kind of given us a high level. But if we can go a little deeper.

    Olson: Sure. Yeah. Let’s do it.

    Shimel: So, let me start with this then. And that is sort of getting the buy-in on you know going forward with DevOps, right. Some people say it’s best to go top down. Some people say no, you gotta have buy-in from the bottom up. Some people say you got go top down and bottom up and meet in the middle. And I’m sure any and all of them can be successful in a particular given situation. But I think the issue then is how do you make that happen, right. I mean we recognize that’s an issue. Just if you can give a little preview, Michael of what we’re gonna do on the webinar. What would be some tips people can follow-up with?

    Olson: Yeah. I think it’s a great question, Alan. And you know my take based on what we tend to see from our customers that have been down this path is its super important to start with the why. And what I mean by that is really focus if you’re trying to you know get buy-in for implementing a DevOps way of working within your organization, it’s really important to start with what are the problems we’re trying to solve and what is kind of the end state or outcome that we’re hoping or looking to achieve. And so one of the ways that we tend to see our customers be more successful at you know getting buy-in for a DevOps initiative is you know by focusing on the benefits that other organizations have seen from implementing you know a DevOps way of working. And we’ve got some pretty awesome research that we’ll share on the webinar next month that you know talks about just how much more agile and how much more fast moving high performing IT organizations that are implementing DevOps practices actually are you know around being able to deploy applications and infrastructure changes much more frequently than their lower performing peers. And doing so with you know much shorter lead times or cycle times.

    But also being much more reliable. Actually seeing kind of a higher change success rate. You know faster meantime to recovery when things do invariably go wrong. And then we’ll also share some data that really shows and correlates kind of IT performance around you know moving faster, doing so more reliably with how that’s actually helping organizations win the  marketplace. You know become more productive, become more profitable and achieve higher company growth at the end of the day.

    Shimel: And that’s really what it’s about, right. I mean and you know what Michael, for those who are listening and it sounds easy because it relatively is rolling off your mouth. The language that you’re using, the terms that you’re using. You know I learned this in many years of security when I used to hear from so many security people. I can’t make the executive team understand why I need this IPS. Why I need this Intrusion Prevention System. And because they were talking to their executives about snort signatures and capturing packets, right. And executives don’t talk that language. I think it’s important to take note of the language you’re using Michael, you know again, not that you have to be a rocket scientist to do DevOps. But there’s a certain language of business. There’s a language of you know what is gonna be important not only to me and my team, but to my boss and his boss as well. So for those of you listening to this on streaming, you should rewind it to hear what Michael said again. Because I think you might understand more of what we’re talking about in hearing how he’s describing these things.

    Olson: Yeah. And I think that’s a good point Alan, if I can interject. I think one of the things that we tend to see is adopting a bit of a chameleon approach if you will actually can be effective. And what I mean by that is you know really knowing your audience and making sure that you’re speaking the language of the people that you’re trying to sell on the value of doing DevOps. And so if you’re talking to folks in IT leadership roles, I think they’re gonna be more attuned to the notion of becoming more agile and improving the frequency of speed of software delivery and improving the reliability and quality of that software. But certainly stakeholders on the business side are probably gonna be more focused on how does this actually impact our ability to deliver value to customers and help the business grow and be successful. And so being able to tailor the message if you will you know to the people you’re speaking with, I think is an important skill and a trait when it comes to you know navigating an organization to build a case.

    Shimel: Absolutely. So Michael, you know I mean obviously to me anyway, this sounds like we’re gonna have a great webinar on the 27th. And I hope people listening in at home will join in. You can find out more information by the way if you’re interested in registering for the webinar on devopsy.kinsta.cloud if you go to our Events section under Webinars. The webinars we’re doing are in chronological order and you can click on the graphic or the link and register from there and of course that’ll set you up to get reminders and everything else. Michael, we’re kind of running a little low on time. I’ve got two last questions for you. For people who maybe they haven’t heard enough yet about the webinar or maybe they have, but they have questions, anything else you want to tell them why this is a good webinar to attend. It’s worth their time.

    Olson: Yeah. Sure. I would say you know the companies and IT professionals you know that certainly I talk to on a daily basis you know frequently fall into one of three camps if you will. The first of which is still trying to figure out what this DevOps thing really is and what it means. You know there’s still a perception at some level that it’s a loose and evolving collection of practices. And you know you walk into a room and you ask a room of 10 people to give their definition of DevOps, you’ll get 10 different responses.

    Shimel: Yeah.

    Olson: So I think if that’s the stage you’re at is still trying to kind of develop a deeper understanding of what it means to bring DevOps practices into your organization, we’ll definitely address that. If you’re sold on the value and just trying to you know get buy-in from peers or from executives within your organization, hopefully you’ll walk out of this with some ammunition in your toolkit to be able to have those conversations within your organization. And then I think the third camp is if you’re you know sold on the value, you’ve got buy-in from the rest of the team and you’ve started to implement more of a DevOps way of working and are looking to kind of scale that across the rest of the organization, hopefully we’ll provide a roadmap for you know ways to do that and ways to kind of take it to the next level. So ambitious agenda but if any of those three kind of current states apply to you, then definitely look forward to seeing you on there.

    Shimel: Perfect.

    Olson: All right. Michael, we’re over time but I’ve got to ask you my last question anyway. So, people listening, if you’re gonna recommend one book that they read, just one, what book do you recommend, Michael?

    Olson: Oh, man. That is the million-dollar question, Alan. It’s a tough one to answer but you know there’s so many good books out there that I think cover kind of this and adjacent topics. I’m sure you know folks who are listening in have either read or heard about the Phoenix Project by Gene Kim. That’s a must-read in my opinion. Another one that I really enjoyed and I found really informative was a book by Jez Humble. It was co-authored by Barry O’Reilly and I think Joanne Molesky. And it’s titled Lean Enterprise.

    Shimel: Yep.

    Olson: And the focus is really kind of how high performing organizations innovate at scale in response to you know evolving customer needs and response to new technology. You know it provides kind of a roadmap for some of the methodologies that organizations need to become more efficient and ultimately deliver better value to their end users. So definitely would recommend that. It’s also you know a nice quick read that you can knock out. You know I’m a pretty slow reader so for me we’re talking a couple weeks. But I’m sure for most folks on the podcast we’re looking at maybe a few days or less.

    Shimel: You know what Michael, it has a treasured place on my bookshelf here in the office and my copy is pretty dog-eared already. I’ve looked at it and referred to it many times. It’s an excellent book. You know a lot of people think you tell a Jez Humble book and they’re thinking the CD book. But the Lean Enterprise book in a lot of ways is a superior book. But anyway, great suggestion. We highly recommend it. And Michael, thank you for being this episodes guest on DevOps Chat. Again, we’re doing this webinar with Puppet on the 27th of September. So a little more than a month from when we’re recording this which is on the 26th of August. So, plenty of time to register. We want to see you there. Michael, continued success at Puppet. Continued success to Puppet. A lot of interest. As we said early on, it’s a great time to be alive. It’s a great time to be in DevOps. It’s a great time to be a Puppet. So you know do keep us posted. We’d love to have you back again in the future.

    Olson: Absolutely. Always a pleasure, Alan. And appreciate the time and we look forward to seeing everybody next month.

    Shimel: Okay. This is Alan Shimel for devopsy.kinsta.cloud on a DevOps Chat. And we’ll see you next time. Bye, bye.

  • Tales Of DevOps Discovery: Q&A from the Field

    Tales Of DevOps Discovery: Q&A from the Field

    DevOps is a buzzed-about industry term, yet many companies are still trying to figure out how to start the journey to a DevOps transformation. Each organization’s journey will be different, but planning and starting the journey always should include assessing the current state of a company’s software delivery process, quantifying the objectives and plotting the “route.” This begins with a discovery process.

    This multipart series will review questions commonly asked during the DevOps discovery process, highlight common answers and provide examples of the resulting guidance. It will show that DevOps is really about optimizing software development and delivery on the planes of process, tools and technology, across multiple stakeholders. Based on experience with a broad cross-section of real-world organizations, the series draws on actual interactions that have led to successful DevOps transformations.

    Starting the Discovery

    Often, organizations embarking on a DevOps transformation want to “pass go” and get straight to, “Tell us how to do it!”  Some initial statements frequently heard are:

    • “We already do and understand [CI, CD, etc.], don’t waste time reviewing that.”
    • “We are practicing [Scrum, ITIL, Six Sigma…]; we are just like everyone else, so there is no need for interview or discovery.”
    • “We don’t need to discuss [process, culture, or technology], just tell us what tools we need.”

    The eagerness to “just go” helps fuel excitement for the transformation; however, it is important to slow the rush to a solution and start with the basics. This includes:

    • Setting a baseline definition of practices: Agile, continuous integration, continuous delivery and DevOps are highly talked-about industry practices that often have multiple definitions and are misunderstood, which fosters resistance or ends up being implemented poorly.
    • Starting with foundational discovery: Ask the most fundamental questions about the current state of the organization’s delivery process and the objectives of the DevOps transformation. These questions must be asked of each stakeholder, including the Business, Development, Quality Assurance (QA), Change Management and Operations.

    Taking these initial steps can be like pulling teeth, yet they spawn insightful discussion, surface key differences in perspective and begin the process of gaining alignment between stakeholders. With alignment among the stakeholders, shared priorities become clear and actionable.

    Once stakeholders align on both the current state and objectives and identify shared priorities, only then is it possible to plot a “route” for the DevOps transformation. At this point a mission statement can be formed, which will act as the North Star or guiding light for the journey. For example, a resulting mission statement may be one of the following:

    • We will increase the stability of our releases while increasing Developer, QA and Operations productivity and job satisfaction. This will improve our ability to retain employees, satisfy customers and be more competitive.
    • We will do this for our existing and new mobile and web products through the use of iterative development, continuous integration, test automation and continuous delivering applications to a production-like environment.
    • We, as Development, QA and Operations, will work as one toward this common objective.
    • We will transform incrementally, empirically establishing best practices and expertise within teams and sharing them across the organization.

    The mission statement may seem like a trivial part of the process, but in reality it is absolutely vital to achieving the cross-fictional buy-in necessary for DevOps. It works to not only outline the strategy, but also gives the teams something to refer back to during the transformation process.

    The other key step to starting the transformation, defining DevOps and related terms, will be discussed in the next post.

    About the Author/Brian Dawson

    BrianDawson-headshot-1200x1200[1]Brian is currently a DevOps evangelist and practitioner at CloudBees, where he helps the community and customers in implementation of Agile, CI, CD and DevOps practices. Prior to CloudBees Brian spent 22-plus years as a software professional in multiple domains including QA, Engineering and Management. Most recently he led an Agile Transformation Consulting practice helping organizations small and large implement CI, CD and DevOps.

    Prior to CloudBees, Brian worked at CollabNet, VA Software, Sony Computer Entertainment, Sega, Namco and Apple. His roots are as a C/C++ developer, but his primary job has always been gathering and distributing knowledge and using shared solutions to solve unique problems.