devopsy.kinsta.cloud

Tag: DevOps initiatives

  • Untapping the Potential of DevOps, Part 4: Tips for Launching a DevOps Team

    Untapping the Potential of DevOps, Part 4: Tips for Launching a DevOps Team

    DevOps has become a hot strategy for IT teams across just about every industry—and for good reason. DevOps is built around increasing the velocity of the development pipeline, and in businesses where time to market is a key to success, it’s easy to imagine why DevOps has gained traction. While the tools and processes put in place are certainly essential, building the right team—from top to bottom—is maybe the most important factor for getting the most out of a DevOps strategy.

    To help get the most out of DevOps initiatives—and to set teams up for long-term, sustained success—here are some basic tips for creating the team that will take development pipelines to new heights.

    Change Is Coming

    When kicking off a DevOps strategy, it’s clear that changes will be made. But, the extent of those changes may be underestimated. To get the most out of DevOps, it’s not just about changing up the tool stack or switching up meeting styles. The mindset around DevOps is at least as important as the processes. To squeeze the most juice out of a DevOps initiative, make sure the company and leadership understand what all DevOps entails and create the understanding that it requires a lot of internal changes to the existing culture. Getting leadership on board with the cultural changes that come with DevOps will go a long way toward driving success.

    Talent Talks

    This may go without saying, but it is imperative to build a team with the right skills for the task at hand. It can be easy to try to shoehorn people into roles, especially when trying to move quickly. But make sure to set individual talent up for success—both employees and the company will benefit. This means having DevOps engineers and leadership with the skills—whether they are technical, interpersonal or something else—to perform the work required.

    Get Your Budget Right

    DevOps helps create efficiencies. Leveraging automation, maximizing value delivery and getting products to market faster are all key tenets of a good DevOps strategy. But that doesn’t mean you should skimp on the important items. Like any project worth doing, it’s a lot easier (and more successful) when it is budgeted properly.

    Make sure to have an adequate budget to create a team, perform the work and support the appropriate environments and infrastructure to perform the DevOps tasks and initiatives that need to be done. Doing this in advance will save a lot of headaches down the line and help develop a clear understanding of what is really needed to get from point A to point B—and help keep spending in line while the DevOps train is moving.

    It’s Not Just About IT

    Remember there are two parts to DevOps—dev and ops. It is often easier to get the developer side to buy into the strategy—after all, many of the tenets of DevOps speak to the technical teams. But overall buy-in is necessary for cooperation and involvement of all teams needed to achieve goals. That means development and operations—plus other departments within the organization, such as sales, marketing, the executive team, etc. Getting everyone on board with the process and rowing in the same direction will fundamentally change the mindset around how to design and deliver products. When the whole team is moving in lockstep, that’s when success can really be visualized.

    By keeping the thoughts above in mind when planning a DevOps journey, organizations can help ensure teams are organized and set up for long-term success. But remember, every organization is different and has different requirements. What may work for one organization may not for the next.

    When considering the potential of DevOps for your organization, it can be tempting to dive right in and skip some important considerations for setting up the initiative. But the key points listed above are tried-and-true and carry weight, no matter the size or scope of business. Having a leader who acts as a champion for DevOps efforts is essential, so IT professionals tasked with leading the organization into the DevOps transformation should arm themselves with these tips to be better positioned for success.

    — Jonathan Fries

  • ServiceNow Makes the DevOps Connection

    ServiceNow Makes the DevOps Connection

    ServiceNow today announced it is extending the reach of its IT operations management platform to integrate with a variety of DevOps platforms.

    Richard Hawes, director of product marketing for ServiceNow, said ServiceNow DevOps will provide IT operations teams relying on an ITIL-based framework accessed as a software-as-a-service (SaaS) application visibility into DevOps processes and events occurring in on-premises environments or public clouds.

    At present, ServiceNow DevOps is available for financial services organizations based in the Northeast region of the United States and the UK. The service gradually will be rolled out to additional ServiceNow customers over the course of 2020. ServiceNow DevOps initially integrates with Jira Software, GitHub, BitBucket and Jenkins, with more integrations expected to be rolled out periodically.

    Hawes said ServiceNow recognizes that IT organizations are building and deploying applications at rates that are faster than existing ITIL-based approaches can track. However, ITIL-based frameworks provide the highly structured set of processes around which the bulk of IT environments are managed. ServiceNow DevOps enables IT teams to automate change management tasks such as planning, development, testing, deployment and operations via a single dashboard surfacing a common set of metrics, he said. He added in many cases, those preset rules and policies will eliminate manual processes that often conspire to slow the rate at which applications can be deployed and updated within any IT environment, said Hawes.

    No developers need to be involved in those processes because IT operations teams can set rules and policies, and developers will see their code running in production environments in a matter of minutes regardless of what tools they employ, said Hawes. That approach also will make it easier to scale DevOps across an enterprise IT organization at a time when adoption of DevOps is still uneven at best, he noted.

    At the same time, that level of integration should also make it easier for IT teams to audit DevOps processes using a common framework to capture events such as when code is checked into a DevOps platform, he said. That capability is a critical requirement for any company trying to apply best DevOps processes with the context of a highly regulated industry such as financial services.

    Hawes said the majority of organizations that have adopted ServiceNow to manage IT have also adopted a DevOps platform. Overall, Forrester Research reports 56% of global infrastructure decision-makers now report that their organizations are implementing, have implemented or are actively expanding their DevOps initiatives. ServiceNow doesn’t expect DevOps processes to supplant ITIL-based frameworks as much as it anticipates both approaches co-existing as they continue to evolve, he said.

    With the release of the latest version of the ITIL framework, it’s apparent that the proponents of ITIL have come to recognize that IT needs to become more agile to meet the needs of digital business. The challenge they face is finding ways to enable IT teams to become more agile without sacrificing the gains in stability achieved over the course of the last two decades. With the launch of ServiceNow DevOps, the effort to find a middle ground between those two extremes can now begin in earnest.

    — Mike Vizard

  • Too Many Projects: Breaking Initiative Overload

    Too Many Projects: Breaking Initiative Overload

    Initiative overload. Those words send a chill down the spine of IT leaders everywhere. Not only are overloaded teams juggling too many projects, morale is usually low, with long hours every week and no end in sight. Yet, leaders can’t arbitrarily kill or stall projects without suffering blowback from somewhere. If you’ve been tapped to lead a DevOps team and you see too many projects in play, breaking initiative overload is a top priority. Here’s where to start.

    It’s very common that highly productive DevOps teams suddenly end up with a list of 20 or 30 “priorities” and rapidly developing gridlock. As the team’s newly anointed coach, you get one shot to fix it. What’s your strategy? Addressing these objectives is critical in breaking initiative overload:

    • Prioritize the right initiatives.
    • Shorten the priority list, ideally to five or fewer projects.
    • Allocate resources so priority projects start and finish promptly.
    • Communicate and defend prioritization with a transparent metric.
    • Identify and plan the “next project up” as priority projects finish.
    • Empower the team with “not a priority right now” if approached.
    • Get buy-in and hold all team members accountable.

    Gather the List

    Sounds complicated, right? Keeping it simple is usually good advice. When you’ve got a long list of projects, first recognize they are not all created equal. Some are truly initiatives, such as that mandate from the CEO for tracking widget sales in real-time. Functional departments have their important projects, providing needed cost reduction or efficiency improvement. You’ll probably see a few wish list projects from various sponsors with weaker justification.

    Next, understand that every project carries a couple of hidden costs. One is the opportunity cost of assigning precious resources to it and not to something else. Another is the switching cost teams incur when they are multitasking too heavily. Neither of these costs can be eliminated; however, they can be optimized within the context of what resources are needed.

    So, make a list of every development project on your radar. List the untouchable initiatives with C-level sponsors. Add the functional projects and those pet project requests. Don’t filter the list at all—anything consuming resources or awaiting start needs visibility. Now, you should see what all the initiative overload chatter in the hallways is about. Take a deep breath, call your team leads together and order your preferred brainstorming chow for a meeting.

    Create the Plot

    Seated around you should be a mix of your best technologists and line-of-business experts. Look at the list together. Sponsors may have justified a project request without a real assessment of merit. If you need someone to speak to a project that team leads haven’t seen, bring in a departmental expert. If they can’t explain it or it’s an outdated request they want to revise, put it in a parking lot. When you’re sure your team leads all understand every project on the list, assign a letter designation for each project.

    On your whiteboard or shared screen, plot each project against two dimensions: implementation ease and business impact. Use a relative scale of low, medium or high for each axis. Implementation ease can incorporate many variables including cost of tools, technical difficulty, in-house expertise and more. Business impact can address revenue increase, cost reduction, competitive advantage or regulatory compliance. Don’t worry about absolutes; you’re looking to see how a project compares to all other opportunities. Adjust the pins if necessary after the first few projects are plotted. You’ll get the hang of it in just an hour or two, even if it’s a long list.

    Line Up Priorities

    Few projects are priority no-brainers with high business impact and high implementation ease. More likely, you have several projects in the “priority box,” scoring better than medium/medium. If you have more than five projects there, take another look and jostle pins a bit to get a manageable list. Make sure your available resources match projects identified in the priority box. Allow one exception: That C-level initiative may score as high business impact and low/medium implementation ease. Killing it just because it’s difficult isn’t a good move, but prioritization within context can help address resourcing.

    That’s the priority list you take back to your team. If it’s on that list, work it and finish it. If something isn’t on that list, your team kicks any inquiries on those projects back to you. Push projects with low business impact and low/medium implementation ease back to their sponsors for justification or removal. When one of the priority projects finishes, then and only then start the next best ranking project. Rescore the entire project list after the first group of projects is complete.

    Too easy? Here’s a recent HBR article, “Too Many Projects,” describing a more elaborate approach for bigger initiatives. You may need such in-depth analysis for a C-level initiative requiring more resources. For most projects on your list, more analysis takes substantially more time and likely produces the exact same prioritization as this faster method.

    The key to breaking initiative overload is starting and finishing the right projects. Creating a vetted priority list quickly and getting the team rolling again is well worth the price of an afternoon and some food. Morale will improve rapidly as your team sees progress and the business sees value faster.

    I’d enjoy your feedback on how this process works for you.

    — Don Dingee

  • 5 Biggest Ways to Fail at DevOps

    5 Biggest Ways to Fail at DevOps

     The mission of DevOps is simple: Ship software, do it frequently, do it well and reliably. Repeat. Repeat.

    Every day, more organizations are turning to DevOps to deliver more frequent software releases, with the result that agile software delivery is gaining traction quicker than expected. Just how rapidly it is being adopted was revealed in research by Right Scale in 2016, which found 81 percent of enterprises were using it.

    Failing to Plan, Planning to Fail

    But despite its growing popularity, the overarching concept of DevOps is still new to many organizations and things don’t always go according to plan. Implementations can—and do—go wrong.

    Here are the five biggest reasons why DevOps initiatives go south, and what you can do to fix them.

    Failure No. 1: Not defining what DevOps means to your organization

    The definition of “DevOps” is not always clear, and can have different meanings from one organization to the next. Developers may equate it with a specific approach to software builds, using popular tools such as Chef, Puppet, Jenkins, Git or Docker. Meanwhile, IT management might see it as a continuation of existing processes with an emphasis on faster time-to-market and lightweight release procedures.

    For organizations launching rockets or running economies, “DevOps” means something very different than what it means to a startup. If a software release still involves the use of a change management tool such as BMC’s Remedy, is it really DevOps? If it takes an hour to deploy a QA build, is it really DevOps?

    Without a common definition, teams will argue over what DevOps is and why it’s being used. Before introducing technology and processes under a DevOps initiative, organizations need to agree on a definition, be clear about what they are trying to accomplish and draw boundaries between DevOps and more structured approaches to IT service management.

    Failure No. 2: Focusing on tools and techniques, while forgetting the teams

    The second mistake many enterprises make is to elevate technology as the primary driver of DevOps at the expense of important processes that ensure quality software is meeting customer expectations.

    It isn’t enough to hire a few release engineers, provide them with virtual machines (VMs) and permission to install Jenkins and Puppet. For any initiative, the technology should not be the only consideration, people and processes also need to be taken into account.

    More environments can always be created, but don’t expect teams to scale overnight. Many companies adopt DevOps, moving to faster, more frequent releases driven by the needs of individual projects, before realizing that an increase in the frequency of software delivery can lead to QA and release management burnout.

    If organizations are introducing more automation to accelerate their time to market, the impact of DevOps initiatives on the teams needs to be considered closely.

    Failure No. 3: Ignoring governance entirely

    A lot of the rhetoric in favor of DevOps is rooted in the idea that developers need to take a proactive approach to evade change-averse administrators.

    DevOps in the enterprise often emerges from one or two groups deciding to stage a “revolution” against an ineffective IT organization. When a company has a large system and intractable releases that take months, teams often lose patience with the process and are tempted to break the mold and move quickly.

    The first teams to embrace DevOps were breaking the rules by design. They were comprised of independent teams free to innovate outside centralized IT structures. But while this approach works in smaller startups, it is not effective in many enterprises.

    An organization with dozens of independent teams creating continuous deployment pipelines may sound good in theory, but it doesn’t work so well in practice. DevOps isn’t about reducing the number of governance gates. On the contrary, it enables more effective, more frequent governance gates to shine a light on complex release orchestration challenges.

    Failure No. 4: Failing to account for risk

    Many companies dive head first into DevOps without a full understanding of how it will affect risk associated with software releases.

    When a company transitions from a slower, ITIL-focused process to a more agile, DevOps-focused reality, release managers are often expected to “wing it” toward the end of the release cycle. Many organizations forget to factor in risk for decisions about production. Software can be delivered faster, but the enterprise still requires governance gates.

    Changes to production facing systems require rigorous change management, along with release management function to track conflicts and risk. One way to streamline the process is through continuous delivery management, which allows teams to conduct multiple simultaneous releases while integrating existing tools, that operations expect to have in place, to track and manage risk.

    Failure No. 5: Running DevOps without metrics

    DevOps teams often start out eagerly working to make change to an organization’s infrastructure and release process, but they can also bite off more than they can chew.

    Even though DevOps teams may want to reinvent a release process overnight, IT managers should still define metrics to evaluate whether initiatives are a success. Managing the slow transition to DevOps tools and techniques over several quarters can be difficult while prioritizing ongoing software development and release management.

    It’s good practice to regularly check in with developers and system administrators not on the team and objectively assess the results. When pulling together a DevOps team, organizations should define roles and responsibilities to bring greater efficiency. It is essential to keep track of release and environment metrics to make informed decisions about particular initiatives from the DevOps teams.

    As DevOps continues to grow in adoption and popularity, more organizations will seek to use it to speed software delivery and success. By avoiding these five common mistakes, they can ensure their initiatives have a better chance of success.

    About the Author / Dalibor Siroky

    Dalibor Siroky is the CEO and co-founder of Plutora with 15 years of leadership, consulting, enterprise product and operations experience across Australia, Asia and Europe. Prior to Plutora, Siroky was founder and managing director of Finotaur, provider of independent management consulting services, and CIO of financial advisory software at Macquarie Bank, head of solution architecture at Commonwealth Bank of Australia and management consultant at PricewaterhouseCoopers. Siroky received his MBA from the University of Chicago Booth School of Business. Connect with him on LinkedIn and follow him on Twitter.