devopsy.kinsta.cloud

Tag: collaboration

  • Security and Speed: Why DevOps and Security Need to Play Nicely

    Security and Speed: Why DevOps and Security Need to Play Nicely

    It isn’t news that DevOps and IT security teams often struggle to align their departments and maintain a coherent balance between keeping a business secure and developing new applications to maintain customer interest. While security processes are a necessity, they can be deemed by DevOps teams to be manual and cumbersome, blocking the agility that makes them so effective in bringing their solutions to market. IT teams conversely feel their counterparts are prepared to sacrifice security in the name of innovation and revenue.

    Even if both teams do respect the other’s intentions, any conflict could lead to delays in both of their processes. For example, an IT team may need to make crucial updates to the network security and warn different teams they may experience some downtime during this crucial implementation. However, DevOps have typically been given more leeway in how they operate as they are so important in today’s software-driven world, and may ask for the update to be delayed so they can complete tasks or meet deadlines, leaving the IT team waiting and losing time rescheduling their own work.

    This has, unfortunately, led to a myth that DevOps teams choose to ignore security. In reality, developers are keen to know that their apps and the environment they work in are secure—but at the same time, they don’t want security to get in the way of them quickly delivering valuable new products and software features.

    So, is there a way for DevOps teams—one of the most important resources in many modern businesses—to embrace security without impacting agility? Can the integration of DevOps and security be done in a way that alleviates tensions and promotes collaboration, while actually improving both security and agility in the process?

    Yes. The secret is automation.

    Reconciliation Through Automation

    As C-suite executives are now more likely to focus on security, due to the obvious financial and reputational consequences of a breach, DevOps teams should define how they protect and secure their multiple projects and production environments. Automating security as part of the CI/CD process allows DevOps teams to easily follow company security policies because they will be embedded into the automation pipeline.

    This process can remain running with little concern, effectively minimizing stress about security. This still automates policy changes and activities so that there is a significantly reduced chance of error. Although the automation solution remains hidden, it can still be utilized at any point to view data on the vulnerabilities, compliance requirements, security policies and network connectivity, via its continuous scanning abilities.

    Additionally, DevOps teams are already familiar with automated tools in their daily operations and communications—and they are likely to be accepting of switching to a security solution that integrates with their existing processes.

    Automation is the key to creating reliable, effective and connected “DevSecOps” teams, as it makes the secure option the easy option. It combines DevOps’ existing use of automated tools to achieve their ultimate goal of continuous, on-time and on-budget deployments with security’s focus of reducing human error and maintaining continuous visibility into potential vulnerabilities.

    Encouraging Adoption

    A guiding principle of DevOps is collaboration, which is often equated with the idea of shared responsibility. To successfully embed security into the DevOps process, security teams and developers must work together and establish shared responsibility. But how?

    Some organizations may assign a security representative in each development team. This person acts as a pivotal link between the two teams, improving communication and building a balanced process that considers everyone’s mutual interests. A continuous flow of knowledge-sharing among both teams ensures a level of maturity that allows a business to secure applications and services with an automated solution.

    Security teams can begin to define “guardrail policies” that allow development teams to deploy continuously, with the caveat of having to obey security and compliance policies. This is critical for both teams. This new way of working means developers will be able to test their security posture at every step in the CI/CD pipeline and correct things when necessary, and security teams can comprehensively ensure security and compliance throughout the development process.

    Embracing Collaboration

    Any belief that there is common discord between DevOps and IT security teams is unfounded. While it cannot be denied that both teams affect each other, this is not due to conflict—it’s due to business needs. If the two teams work together, they can both achieve their goals and be part of a secure, innovative and profitable organization. The first step is to accept collaboration is a necessity and by embracing security instead of being concerned by it, DevOps teams can stay in control of how their needs work around IT teams’ processes. Then, an automated security solution can be deployed to improve the efficiency and outcomes of both departments—and, in turn, the entire organization. It’s time for DevOps to embrace DevSecOps.

    — Reuven Harrison

  • DevOps: The Ultimate Way to Break Down Silos

    DevOps: The Ultimate Way to Break Down Silos

     Let’s imagine Jim works on the development team for a food company and his colleague, Julie, works on the operations team. On a daily basis, Jim focuses on analyzing users’ needs, testing and developing software, while Judy manages IT infrastructure and policies.

    Although they share the responsibility of software deployments and application support, Judy and Jim rarely interact with each other. In other words, they operate in siloed functions that do not encourage teamwork.

    Many organizations recognize these silos. So, to enhance cross-team collaboration and reduce repetitive work, they are implementing the DevOps mindset. This methodology facilitates constant feedback and creates an environment where the building and testing of software occur simultaneously. But to successfully implement DevOps, business leaders first need to understand what a silo is, how it’s created and its impacts on employee morale.

    What is a Silo?

    Take development and operations teams as an example. Development and operations work with two distinct mindsets. Operations values stability, which can slow down software updates. On the other hand, development values speed and is encouraged to create, innovate and generate as much as possible.

    Silos develop when these departments are structured to work as separate entities with their own visions, goals and responsibilities. If development employees aren’t passing information about software bugs to the operations team, then workflow quickly becomes bottlenecked and productivity suffers.

    How Silos Impact Employee Morale

    The lack of information-sharing across teams takes a toll on employee morale and transparency, preventing development and operations teams from forming trust and mutual respect. Within silos, the development team might not report a software bug to operations out of fear of being reprimanded. Without an honest and open information sharing system, workflow is not only delayed, but the potential for misinformation increases.

    Silos create a structure in which departments focus on their own goals instead of working toward organizational objectives. Eventually, this mentality can lead to hostile relationships between departments, which negatively impacts efficiency and harms the bottom line.

    How DevOps Can Eliminate Silos

    Implementing DevOps is the natural first step when shifting employee attitudes from departmental focus to organizational goals. This way, employees don’t have to face the daunting task of completely eliminating all silos at once.

    By breaking down silos with DevOps, companies can avoid overspending on departments that may be resistant to change. Employers can create momentum for upcoming changes in other teams with the end goal of cultivating a collaborative mindset within every department of their organization.

    To facilitate this transition, organizations should assign a DevOps administrator to act as a mediator between departments. This administrator works to communicate and apply the DevOps methodology across teams while navigating cultural differences to facilitate cross-team collaboration. To successfully implement a DevOps mindset, the administrator should keep the following strategies in mind:

    • Direct teams toward common organizational goals. Team leaders should set specific goals that align with overall business needs. It’s crucial for leaders to point out how departmental goals directly support common objectives.
    • Design shared metrics. A consistent measurement tool holds everyone accountable and encourages stronger teamwork by enabling leaders to track progress and assign workloads accordingly. For instance, organizations can set up delivery cycle metrics for both development and operations teams to measure how much workflow speed increases for both teams while maintaining continuous delivery.
    • Organize regular meetings. Inviting team representatives to participate in recurring meetings creates an opportunity for everyone to give updates on project statuses.

    How DevOps Impacts Organizations 

    Today, IT is no longer an isolated function but an essential department within organizations. It’s important that future leaders invest in technology that drives business success while keeping its employees in mind. For example, enterprise, or employee, service management is popular among businesses for its ability to deliver automated insights and support. Many organizations are turning to a modern IT service management platform to bring their employees fast and quality service—two central qualities of the DevOps mindset.

    DevOps’ culture of continuous delivery helps shorten resolution time and encourages collaboration among development and operations teams. At first, businesses can struggle with continuous delivery due to siloed IT functions because these established support structures often come with lengthy and outdated processes that slow down delivery speed. However, a DevOps-focused culture supported by an IT service desk empowers developers and operators to deliver configuration changes and resolve issues at a faster pace.

    In today’s competitive environment, a silo mentality is a detriment to the innovation required for companies to stay ahead of the curve. Through effective management strategies, the integration of the DevOps mindset will eventually break down silos, increasing collaboration and productivity.

    — Michael Mazyar

  • DevOps and Collaboration: Fraternizing with the Enemy?

    DevOps and Collaboration: Fraternizing with the Enemy?

    DevOps is all about collaboration, we hear.
    “You must collaborate,” say managers initiating DevOps adoption programs.
    HR make new posters declaring the corporate values “We value Collaboration & Teamwork.”
    Can’t fail!
    Then when it appears not to be as effective as we had hoped we tell teams they are “Empowered” to collaborate.
    Blank stares!
    When things still don’t appear to be working we tell teams they are “self-steering,” “self-organizing, collaborative teams”….
    Still, we don’t get what we were hoping for.
    Luckily the tool vendors come to the rescue and tell us why it is failing. We need “collaboration tools and software” – Throw some “Slack” at it.
    Can’t fail!

    This is when we usually get frustrated managers knocking on our door asking about the Phoenix Project DevOps simulation. They are moaning about communication and collaboration! When we talk to the teams they are frustrated and moaning about “empowerment” and managers not “walking the talk.”

    In my mind these lack of collaboration skills is not really surprising. Why?

    Impression: Well, it doesn’t help when the word has also historically been connected to global conflict situations. “He faces charges of collaboration,” “fraternizing with the enemy.” Dev & Ops. Traditional adversaries?

    Interpretation: The interpretation of the word itself is also part of the problem. I googled an English Language Help Desk:

    Collaboration: “To work together with somebody in order to achieve a single shared goal.”
    Cooperation: “Work with other people by achieving one”s own goals as part of a common goal.”

    In an HBR article titled, “There’s a difference between cooperation and collaboration,” it was argued  “… Managers mistake cooperativeness for being collaborative,” adding, “… most managers are cooperative, friendly, willing to share information – but lack the ability and flexibility to align their goals and resources with others in real time.” If managers don’t get it then what chance do the teams have when told – “You must collaborate”!

    Induction: Part of our failure to be able to effectively collaborate could come from our schooling. We are chastised at school for asking others for help, for looking to see how somebody else is doing it—”That is cheating”—things are changing with more “collaborative assignments.” Yet, my children (now in their early 20s) were not taught what effective collaboration is, other than discovering for themselves. As my daughter explained about her school assignment, “You have to do it yourself if you want it done because others will slink off and not do it, then my individual grade may suffer.” They are told they need to collaborate but individual performance grades are scored. My daughter once came home stressed and almost in tears, declaring “Oh no! I have been given another collaborative assignment for my most important subject!” Children leave schools distrustful of collaborating.

    Indoctrination and Imperative: There is also the historical perspective. When we, the current workforce entered our chosen profession we had decades of functional silos that created a “them” and “us” attitude. This stimulates a sort of “territorial imperative” or “tribalism,” not helped by our own “technology” languages and tribal cultures. We have learned over time that other teams “dump things on us” or other teams “stop us from getting stuff done.” In other words, Other teams frustrate work.  (Territorial imperative—”the drive in animals and man to take, hold and defend a particular area, zone, turf,” —e.g. defending their best practice framework! And attacking others that come near!).

    Inconsistency: We then built walls between these teams and if they wanted something from each other they needed to escalate it to their manager. Managers would collaborate or not, especially when they were given conflicting, inconsistent goals and KPIs. Development teams are given goals to release as fast and as often as possible. Operations are given goals to make sure everything is as reliable as possible and available at all times.

    I had an example of this “them and us attitude,” once with a board of directors. I split them into two teams and gave each team a pack of ABC cards (Attitude, Behavior and Culture) and within 10 seconds heard, “Oh good, our team will win this!” automatically creating an atmosphere of competition and winning and losing, I hadn’t even explained the task yet! Teams compete.

    ‘It’ factor: A study by Google (2012) called Project Aristotle, named in tribute to Aristotle’s quote, “The whole is greater than the sum of its parts,” looked into why some teams work and others don’t. One of the key conclusions was that “psychological safety” was the “it” factor, “… a sense of confidence that the team will not embarrass, reject or punish someone for speaking up.” Because we have not learned to collaborate and because we have a “them and us” history often accompanied by blame, there is fear, uncertainty and doubt (FUD) about speaking up, sharing ideas or giving feedback.

    In the dark: However, there is another significant reason for poor collaboration, as I have discovered from running hundreds of Phoenix Project simulations with teams globally. It is the fact that nobody has defined the “behaviors” that demonstrate effective collaboration. We assume everybody knows what we mean when we say, “You must collaborate.” Fact: We don’t!

    Below are the results of a series of recent Phoenix Project simulations. One of the goals was to learn DevOps practices such as CALMS and the Three Ways, while another goal was to learn effective team-working and collaboration.

    I asked the teams at the start of the sessions, “What is effective collaboration? What behaviors will I see today that demonstrate this”?  The teams came up with a list of behaviors (each team came up with a top five or six behaviors; this is the consolidated list from seven teams).

    • Transparent communication – “open and honest” and “frequent.”
    • Calm and constructive dialogue (no blame, accusations and shouting).
    • Feedback “asking for and giving feedback.” Constructive feedback.
    • Shared team goals (and cross team). What are we aiming for? Impact on others and their goals. Maybe conflicts that need managing.
    • Listen – is it clear and understood? Show that you listen.
    • Being open for dialogue, being approachable –not closing the door or hiding behind.
    • Giving and taking responsibility.
    • Sticking to agreements.
    • Central moment to get together (e-2-e).
    • Knowing the roles and responsibilities, sticking to responsibilities.
    • Mistakes are OK.
    • Be proactive to get information needed.
    • Equal treatment: “Respect” ideas from ALL
    • Don’t HOPE, confirm.
    • “Willingness.” Confirm and agree.
    • Ownership of responsibilities.
    • Clear agenda and purpose of meetings.
    • Pleasure – celebrating success.

    “Are these behaviors you want to see more of in your daily work?” I asked.

    Yes! Was the answer.

    “Do we now all commit to sticking to these behaviors today, in this simulation?

    Yes! Was the answer. Easy! See there’s nothing to this collaboration stuff.

    However …

    During the simulation it soon became evident that roles and responsibilities were not clear or not being carried out; it was not agreed which information was needed by the business nor when; goals were unclear, meaning that priorities were arbitrary; people did not understand procedures and did not ask for help; assumptions were made (“I told you …,” “I thought you meant …”); people taking responsibility were not respected (“Let’s stop and try and sort this out …”)— everybody just carried on running around! “Headless chickens,” said one delegate; people were not listening to each other; there was a lot of “assumicide”; mistakes were made and people blamed—there was no exploration as to why and what can be done to stop these  mistakes. Mistakes were often corrected by somebody else but without giving any feedback to correct future mistakes; agreements were unclear across the team; there was no end-to-end flow—work and information was ping-ponging back and forward.

    “All in all, just like reality!” declared the teams.

    See how easy collaboration is. Within one hour of making a list of desirable behaviors, they were totally, utterly and universally ignored. Nobody appeared to own these behaviors or to confront each other on them.

    After the Experiences in Simulation

    At the end of the simulation round we looked at the team scores (number of releases, number of successful releases, business value realized). It wasn’t a pretty sight. The CEO wasn’t happy. The team felt stressed, unhappy, frustrated and powerless.

    We explored what this had to do with “effective collaboration.” Had anybody used the list of behaviors? No.
    Had anybody consciously practiced these behaviors?
    No.
    Did anybody give feedback on these behaviors when they were clearly not done?
    No.
    “Giving feedback feels strange, it feels like we are criticizing and blaming,” said one delegate. Another assumption!

    “It’s hard,” said one delegate. “The manager needs to manage this,” said another.
    “It was YOUR list and YOU all agreed this, why is this a manager’s job to get you to do what you said you wanted to do?”
    There was silence. “It’s not easy, we fall back into old ways of doing things, we need help!”

    Is it a Bird, Is it a Plane, Is it a Bus? No, it’s a coach!

    As the simulation progressed, the team refined their list of desirable behaviors based upon their experiences. They were coached for two rounds and consciously practiced and experimented with the behaviors. The coach role became a critical catalyst.

    In the final round the team owned, and were executing on these behaviors without coaching.
    Why were they suddenly executing?
    They felt less stressed; they were trusting each other; they felt the positive impact on their work; they saw, felt and shared the value gained by these behaviors. They felt immediate positive consequences from these behaviors.
    Why no more coaching?
    The team were taking it in turns to lead their own stand-ups; they were giving feedback and correcting their own behaviors. These were the additions the teams made to the behaviors as they practiced them.

    • Transparent communication – “open and honest” and “frequent” (Relevant, and timely as agreed with the various stakeholders).
    • Feedback “asking for and giving feedback.” Constructive feedback. (Related to agreed behaviors and responsibilities, calling stop, then swarming to solve an impediment, constraint, or remove waste; immediate fact based feedback).
    • Shared team goals (and cross team). What are we aiming for? Impact on others and their goals. Maybe conflicts that need managing. Understanding strategic portfolio and how we contribute to strategy, show you understand and agree common goals and prioritize accordingly. Goals for both value creation (features and benefits) and value leakage (risks, debt).
    • Leadership within team – team members took turns in facilitating the stand-up and retrospective. This role was respected.
    • Listen – is it clear and understood? Show that you listen, sender: Ask for clarification, ask to confirm understanding, listener: summarize what was understood and agreed. Avoid assumptions.
    • Being open for dialogue, being approachable—not closing the door or hiding behind. All were engaged and equal in the stand-up and retrospective. All were asked for feedback, ideas, suggestions.
    • Giving and taking responsibility. Respecting team behaviors; e.g if somebody calls “stop,” or “respect somebody taking responsibility for an improvement stand-up.”
    • Sticking to agreements. Confront people to understand why agreement not met and what can be done about it in the future (e.g conflicting priorities, lack of understanding).
    • Central moment to get together (e-2-e). Scheduled stand-ups, retrospectives, and improvement prioritization.
    • Knowing the roles and responsibilities, sticking to responsibilities, confirming your responsibilities, confronting people on responsibilities (feedback). Showing that you take ownership.
    • Mistakes are OK – no blame, so long as it is used as an opportunity to learn and improve.
    • Be proactive to get information needed (or ensure information is available, e.g. visible management board, avoid unnecessary “disruptions).
    • Equal treatment: “Respect” ideas from ALL. Ask people for input, engage ALL in ideas generation and decision-making.
    • Don’t HOPE, confirm.
    • “Willingness.” Confirm and agree – “Willingness” and “ability,” empower to be able. Share knowledge, cross train, coach, help.
    • Ownership of responsibilities. Confronting people on responsibilities.
    • Clear agenda and purpose of meetings. My role, what is expected from me? What is in it for me? avoid “wasting” time in meetings.
    • Team coaching to give feedback on behaviors.
    • Create trust by demonstrating team behaviors.
    • Check understanding and commitment to “agreements” and confront people (feedback) on agreements.
    • Improving own work as a team.
    • Asking for and offering help.
    • Having insight, overview, visibility.
    • Limit WIP (reserve WIP for learning, improving, technical debt).
    • Pleasure – celebrating success. Product owner shared results including customer feedback. Team complemented each other.

    The teams were then asked to make a list of behaviors and actions they wanted to take away and apply. Their line managers and assigned team coaches were there when the list was made and gave commitment to help guide, coach and empower teams to experiment and practice these new behaviors in their daily work.

    The team would prioritize one or two behaviors to start with and consistently practice in the coming weeks. When the new behavior becomes the accepted norm and a “habit” they would focus on more behaviors.  This fits in with the Third Way of DevOps: Continuous experimentation and learning. “Understanding that repetition and practice is the prerequisite to mastery.” And to tie this back to Aristotle the philosopher (not the Google project): “Excellence is an art won by training and habituation … We are what we repeatedly do. Excellence, then, is not an act but a habit.”

    Meetings, Including Training Sessions!

    And finally, one of our industry’s most popular, and wasteful, examples of collaboration are poorly run meetings, which are the biggest time-sink in organizations and a source of frustration. I include some training classes as forms of meetings.

    In more than 100 training sessions in the last year, less than 10 percent have started on time.
    Nine minutes late is the average. Delegates say this is normal in their organizations. When I ask people what their own personal learning goals are for sitting eight hours in this “training meeting,” more than 25 percent had not defined this and more than 70 percent had not agreed this with the “sponsor” of the training.

    We need to manage our overload of wasted meeting effort. How? One way is the ask for goal and agenda in advance, asking what value you need to bring in and what value you need to get from the meeting; also to limit your time to the agenda items relevant for you or your team.

    Efficient collaborators decide when they do, or don’t, have unique value to add—“maintaining focus on what matters.”

    The same applies to training, asking, “Why am I going on the training?” “What am I expected to learn?” “What problem is this training expected to help solve?”  “What will I be expected to do differently after the training?” “How will the learning be transferred back to the workplace?” “Will I be mentored and coached?” “Will I be given opportunities to experiment?” “Will I get constructive feedback?” “How can we demonstrate that the new knowledge delivers expected benefits?” This is better than the most common answer, “I don’t know I was told to come to this training!”

    A training is also a form of collaboration between you, the trainer and the person sponsoring the training.

    There is an “I” in Team, after all. “I” am responsible for my effective contribution to team performance.

    — Paul Wilkinson

  • How DevOps Can Nurture the IoT Brownfield For Results

    How DevOps Can Nurture the IoT Brownfield For Results

    Your latest IoT project sailed through proof-of-concept but started running into problems during rollout. Fortunately, your DevOps superhumans got things running. Now, perhaps a year or more later, you’re seeing more and more issues crop up as the project grows. If this scenario sounds vaguely familiar, or you’re worried you may be headed there, you’re not alone. Welcome to the IoT brownfield.

    “Nah, can’t be. We selected and evaluated all-new hardware and software during the PoC. This has been a greenfield project from the start.” Be careful of this trap. Many IoT projects indeed start off as greenfield efforts, free of the constraints of integrating legacy hardware and software. Your team developed requirements with collaboration between IT and line-of-business folks. You introduced these new tools, and got results on a small scale. According to Cisco’s 2017 IoT survey of 1,845 IT and line-of-business decision makers, 60 percent of IoT projects stall at PoC, so you’re ahead of the game.

    Or so it would seem. Now comes the escalating commitment. Management assumes that if it worked on a small scale, it should just work when rolled out across the enterprise. Data and insight will just come pouring in, and everyone will have visibility to what’s happening everywhere in real-time. They write a big check for the rollout, and away you go.

    First Signs of Trouble

    At the first rollout project review, folks start splitting hairs over the definition of “complete success.” You rolled out X locations, Y of them are working, X-Y of them are in various states of triage. How can that be? You took the “same” configuration and scaled it. As the team investigates the non-working population, you’re finding little things that aren’t the same, calling for tweaks here and there.

    Tossing out the trivial, over scale and time there is no such thing as an IoT greenfield project. Every IoT project with an extended life cycle becomes a brownfield, with a mix of new and old hardware and software. Rigorously controlling a configuration, à la defense or medical applications, is prohibitively expensive and unnecessary for most IoT applications. Your vendors won’t sell you the exact same hardware or software two years from now, five years from now, 10 years from now. Unless, that is, you pay them for things such as lifetime buys of electronic components or freezing open source code releases.

    Ideally, we should send DevOps teams into IoT projects. With a big tool stack acquiring data, the line-of-business types figure out more things to do as the picture develops. The whole point is gaining insight and adjusting for optimized results. Cycles of learning and security enhancements are part of the game.

    Coping with an IoT Brownfield

    Here’s the paradox: the longer your IoT application survives, the more complex this situation gets. How can you improve your chance of success by applying IoT brownfield thinking? Technical requirements vary, but some core philosophical tenets can help.

    Roll with the changes. Your team is already skilled at quickly rolling application software releases. Get more aggressive with ongoing changes at the firmware and network level. Incorporate over-the-air (OTA) technology for updating code on any wireless devices. Deploy multi-protocol gateways that can deal with revised protocol stacks (or entirely new ones) as IoT specifications continue evolving. Update security vulnerabilities relentlessly.

    Abstract everything. You’ll read tons about IoT interoperability, and what people typically mean is wire-level interoperability of protocols. Those multi-protocol gateways have one job—getting real-time data onto an IP network and into the cloud. What keeps me up at night is data-level interoperability. Use edge or fog computing for pre-processing streams so the cloud isn’t stuck sorting out various formats of the same class of data. Abstract your data using JSON or other lightweight techniques so that if a next-generation sensor outputs data in a slightly different format, pre-processing can be revised close to the source. Consider a publish-subscribe protocol for easier routing between nodes.

    Optimize the cloud. Scale can bite hard in the cloud tier. Heterogenous, distributed architectures usually win. Deploy a hybrid cloud solution where there is real-time data. Let the public cloud do what it’s good at: presentation, business intelligence and archiving. In a private cloud instance for heavier analytics lifting, use a framework such as Apache Spark to minimize data movement, with faster nodes sprinkled in for critical algorithms. Try dedicating a small processing core to each data stream for predictable deadlines, or using FPGAs in workflow optimized nodes for boosting compute performance.

    After All, It’s Just Business

    Ultimately, the evaluation of complete success of an IoT application will be up to the line-of-business decision-makers who wrote that big rollout check. A DevOps model is ideal for nurturing the IoT brownfield over scale and time, featuring ongoing strong collaboration between technologists and line-of-business types. Early in the project, reach out for some external IoT expertise until you have a few cycles of learning under your belt.

    As that Cisco 2017 IoT survey alluded to, 61 percent of practitioners believe we’re barely scratching the surface of IoT transformation for businesses. Avoiding the greenfield trap and incorporating these IoT brownfield coping strategies sets you up for the best possible chance of success in the long run.

    — Don Dingee

  • ‘Yehbut’: Communication in the Age of DevOps

    ‘Yehbut’: Communication in the Age of DevOps

    Effective communication is integral to success in DevOps transformations

    Ever since the dawning of mankind, or should I say “humankind,” we, as a species have invented ways to communicate with our fellow men and women and gender-neutral colleagues (and, soon to be included, robots). From grunting and bashing (bashing gets the message across quite effectively, albeit rather limited in scope) to cave paintings, symbol-based languages such as Cuniform and Hieroglyphics to modern complex languages that evolve across cultures.

    Fast forward a few thousand years …

    With the emergence of IT professionals as a species, we took a step back into the caves (data centers) and reinvented our own grunting and technobabble language to fit our own IT culture. Our cave wall images became PowerPoint slides, and we would “bash” users with SLAs. Symbols became replaced by acronyms: SLA, UPC, CI/CD, XML, and our modern languages became the language of the “framework” (e.g for the purpose of this article, DevOps). IT evolved and became embedded and entwined in every aspect of business and society, and we have been forced out of our caves and are now expected to “communicate” with these other alien cultures. Yet, our business colleagues feel we still cling to our technospeak to confuse them. (Read “Communication between IT and Non-It is a state of crises” – it was written in 2015 but business leaders I speak to still recognize this).

    Even within IT we have our own sub-tribe languages, spawned by the frameworks and practices we adopt. The framework becomes the “Word.” Framework fundamentalists and framework dogma rule, as we throw terms at each other “incident,” “problem,” “defect,” “release,” “deployment,” “User … pain in the neck.” Sometimes the framework and language becomes a brick in the invisible wall that divides us into IT silos.

    We defend our language as it becomes part of our identity and what binds us together. In fact even the framework name itself takes on a meaning and life of its own. When we say “ITIL,” some interpret this to mean “Bureaucratic set of control processes that stifle innovation.” When we say “DevOps,” some take this to mean “Cowboy developers trying to push lousy code on to us without any controls.” (More on this framework interpretation shortly, as it is central to my rambling).

    There seems to be one term that is common to all frameworks, something that binds us together. Finally something we can cling to and ALL understand. It is the word “Yehbut!” Whenever anybody from a different silo tries explaining something we say, “Yehbut” (“Yes, but,” meaning in fact “No, because”). In fact, to speed up the flow of communication (as speed and flow are now catchphrases in the age of Agile and DevOps, we even say “yehbut” before the person has finished speaking, thereby eliminating “waste” (wasteful words).

    We in IT do not need to hear everything to know what was going to be said or even the intention, we have our own “artificial intelligence” engine built in—it is called “assumption intellect (AI).” We apply “Assumicide”: assuming that we know what the other meant when communicating to us and assuming the other understood what we said. This is obviously a core IT capability, as we see it consistently applied in just about every team in our latest “Phoenix project” DevOps simulation. It would appear that we don’t listen to understand, we listen to give an answer. Shift left. Give an answer before the question has even been asked.

    It is the same with the word “DevOps.” People assume they know what it means and interpret the term in their own way. In our simulations we strongly urge BizDevOps, the importance of the role of the business. This receives criticism from experts; quite rightly from their perception, interpretation and intention, they declare that DevOps always included business, sec, QA and the rest of the stakeholders. However, that original intention has gone through the “assumption intellect” filter and has come out primarily as Dev and Ops when it comes to adoption, with the business somehow plugged in, on and somewhere in the middle—if we are lucky. Which is why we make it BizDevOpsBiz: to make it explicit. Mark Smalley has written a thought-provoking DASA whitepaper around this topic. Gene Kim, at a recent Executive Connections session, also stated that product owners also need to shift their mindset from “features” to “business outcomes.”

    There also seems to be a common “taboo word” that binds us all together across frameworks. It is a common agreement to avoid asking or answering the question “Why?”—”Why are we doing this framework?” The framework becomes the “goal” in itself. “We are going to implement DevOps, ITIL or any other framework.” We send the different silos onto framework training to learn the latest “terminology” so we can confuse other teams and departments who don’t follow the training.

    It seems that our motto is, “Ours not to reason why, ours but to do and die.” (Alfred Lord Tennyson)

    The Importance of Communication in DevOps

    Why am I ranting on about communication and words?

    Three reasons:

    1. Communication and collaboration seem to be critical enablers or barriers for DevOps success.
    2. The word “DevOps” seems to have taken on a meaning and life of its own, which is limiting the potential value.
    3. Communication issues are very costly (see this article from Forbes).

    I recently played a Phoenix Project DevOps business simulation with a group of senior leaders at the start of a DevOps transformation. These were their key takeaways. I decided to try and analyze their discoveries in terms of communication.

    • Answer the questions “What’s in it for me?” “What if we don’t?” – make this clear to all to ensure the “Why?” (are we adopting DevOps ways of working) is understood and felt. Remove the current FUD (fear, uncertainty and doubt) caused by the latest reorganization.
    • “We noticed in the simulation that poor communication leads to assumptions, assumptions in an environment of FUD are negative, and lead to poor decision making, lack of trust, resistance and lack of buy-in.”
    • We recognized the “yeahbut, yeahbut”! People were not seeking to understand and explore before answering. People were not confirming understanding or soliciting feedback and understanding. “We recognize that people listen to give an answer, not listen to understand.”
    • Coaching for teams in start-up phase. Not “telling teams what you expect and what to DO,” asking teams questions about “behavior” and “impact” (help them to learn to apply continual learning and improvement, to organize effective stand-ups, to apply active listening). Learning new behaviors and letting go of old ways of communicating and behaving requires practice and feedback.
    • Tell teams (including product owner) we support and commit to reserving WIP time for them to learn, create cross-functional teams and improve.
    • Applying “consequence” management—verbally recognizing, rewarding and reinforcing “desirable behaviors.” Directly communicating and giving feedback on “undesirable behaviors” and “falling back into old behaviors.”
    • Fostering open feedback on “undesirable behaviors,” asking questions about feedback and behaviors. (When nobody says something about it, it is implicitly accepted behavior).
    • Foster a culture of active listening, understanding. “Good ideas when not heard or acted upon are ‘waste’, and demotivating when not given recognition or heard.” Not recognizing and giving room to innovative ideas will stifle a culture of experimentation.
    • Have teams develop own visual management systems together with coaches, to aid insight into workloads and priorities, communication and decision making—The MT (Management teams) must communicate guidelines around priority (portfolio, strategic goals). The visual management board became the modern cave wall painting, a new language of post-its, tape and swim-lanes.
    • Start capturing and understanding WIP, WIP limits and constraints to flow. Start capturing and visualizing team pain points and improvements. This will aid communication, open discussion, decision-making and expectations.
    • Foster a culture of “measures to improve” (not measures to punish): measures to show behavior change, measures “DevOps” metrics (releases, time to release, quality of release), agree measures of “value” and “outcomes” with product owners, measure team skills and growth, measure impact of iterative “improvements” (see 8-field model).
    • Introduce FUBAR of the month with rewards for most impactful learning and improvement. (Remove fear and blame associated with failing). Talk about failures, impediments, constraints, waste. MT will start with own!
    • Revisit VSM (value stream mapping) training and make visible value streams with all stakeholders, Pin these up where they are visible to all, ask people to put “pain point” stickers on VSM (allows all to communicate continual learning and improvement needs, focusing on eliminating waste). This also helps recognize the “information” and “communication” flow through the value stream and foster dialogue.
    • Calling “Stop” is a very effective communication tool, if “respected.” Calling “Stop” to discuss and agree to eliminate “waste” and improve “flow” through the value stream.
    • Engage and involve end-to-end stakeholders in these simulation sessions to foster a dialogue, to practice effective communication, reduce assumptions, create buy-in and stop the “yeahbut, yeahbut” responses.

    Although DevOps success clearly relies up technology for the continuous integration, automated testing and continual delivery, it is underpinned by effective communication and collaboration. Communication is not just about terminology or language: Listening is probably more important than talking. It is also about demonstrated behaviors—walking the talk, leading by example. This is what ultimately creates trust. And trust is the foundation for effective collaboration.

    — Paul Wilkinson

  • Using CALMS to Assess an Organization’s DevOps

    Using CALMS to Assess an Organization’s DevOps

    Of the tried-and-tested frameworks that allow enterprises to assess DevOps in their organization and how it can be improved, the CALMS model remains particularly useful.

    CALMS, which stands for Collaboration, Automation, Lean, Measurement and Sharing, is particularly helpful for analyzing an organization’s DevOps structure, and ultimately, its utility in any organization. The CALMS framework covers all stakeholders within DevOps, including business, IT operations, QA, InfoSec and development teams, and how they collectively deliver, deploy and integrate automated processes that make business sense.

    “DevOps as a technique is slowly but steadily maturing, so it’s good to see general assessment methods like the CALMS model,” Holger Mueller, an analyst for Constellation Research, said. “The CALMS model gives a good frame of reference to compare the maturity of a DevOps team, and as such,  is invaluable for assessing the state of teams for the transformational change that goes with it.”

    Applying CALMS

    Here are a few ways CALMS can be applied to DevOps for enterprises either thinking about shifting to a DevOps structure or seek to make improvements to an existing deployment.

    Culture

    It is long-established that technology adoption must be to serve a business need rather than investing in technology for its own sake. This shift in mindset applies to how the “culture” component of CALMS supports how the forecasted ROI associated with automating a process must be championed across the DevOps team. This mindset is especially important for getting the non-technical business teams onboard, Mueller said.

    “DevOps must have the backing from the business executives. That’s a crucial factor in the culture part,” he said. “One thing software teams can do is use successful software deployments to help convince the business executives in DevOps to make the investments. Those are the kinds of tribal events that every DevOps organization needs.“

    Automation

    Netflix is well-known as an exemplary case study for DevOps automation. Among other things, it can deploy code and software updates in a matter of minutes across its entire massive infrastructure, many times throughout the day. But Netflix’s example of automation does not take into account what can go wrong at firms that want to follow Netflix’s example when automating their software deployments and updates, Mueller said.

    “The risk is always deploying too fast and you end up deploying bad code,” Mueller said. “Automation, of course, needs to take this into account and compensate. But not everybody can do that.”

    Lean

    Once completed, it is relatively easy to document cost savings by eliminating resources. Within the CALMS framework, the corresponding “lean” component in DevOps is thus relatively easy to assess, Mueller said.

    The good thing about DevOps, Mueller said, is companies can come to a consensus ahead of time regarding what they consider to be a lean operation.

    However, he added, “There is always the risk of being so lean you begin to err on the QA side.”

    Measurement

    The success of software deployments is relatively easy to measure once completed. However, attempting to measure future deployments as part of a forecast model is, of course, much more challenging.

    “It can be surprisingly tricky to measure how good DevOps is ahead of time,” Mueller said. “Measurements should thus allow errors to be pinpointed  quickly during the post-deployment stage to fix the code if needed very quickly.”

    Sharing

    Sharing, in many ways, overlaps with culture. This is where assessing whether all of the different teams within DevOps are working together and communicating comes into play.

    “Thanks to  DevOps, the days of the lone developer are long gone. But sharing is not always easy,” Mueller said. “Even within separate teams, it is easy to fall into the trap of wanting to get your own work done without necessarily thinking about the team as much as you should.”

    The End Result

    While applying CALMS to assess DevOps never hurts, the framework is still not as important as one of the main objectives of DevOps—namely, using technology to make organizations’ operations more agile and reactive to customer needs, Mueller said.

    “At the end of the day, assessment methods such as CALMS are great, but they are never as important as focusing on implementing next-generation applications,” he said.

    — B. Cameron Gain

  • Can Videoconferencing Solve the DevOps Collaboration Conundrum?

    Can Videoconferencing Solve the DevOps Collaboration Conundrum?

    Every DevOps expert has their own definition of what DevOps really means, but a common thread running through each definition is that it is based on collaboration and evolution of a culture of sharing and communication between IT and operations. How that collaboration is achieved has evolved rapidly, and in today’s most successful digital transformation initiatives, video integration is playing a significant role in improving that teamwork.

    Success tactics in a DevOps initiative depends less on the specific tools and more on that theme of creative collaboration, yet many tools claiming a DevOps heritage actually do very little to facilitate that collaboration. Development platforms, for example, do achieve the goal of faster development, which is a goal of DevOps, but DevOps is less about the deliverable and more about the journey. Tools that facilitate better collaboration between teams, such as videoconferencing, lie at the heart of that DevOps journey.

    How businesses handle issues such as videoconferencing decides, to a large degree, how effective and successful they are in a globally connected marketplace and how well they achieve the twin goals of faster software delivery and a final product that meets the needs of the business. 

    Solving the Essential Development Struggle

    The fundamental development struggle is based on a constant battle between developers and line-of-business managers, who often have different goals and different perspectives on how to achieve those goals. Developers may not have a full grasp of the business goals of their projects, while the managers may fail to recognize the technical challenges being faced in delivering the final product.

    Agile, lean and Scrum development strategies do help to hold the development team accountable to the desired timeline of the business, but beyond these tactics, simply understanding the “big picture” of the project is what makes it work and avoids developers getting bogged down in less important details. How, though, does the development team facilitate this understanding?

    The obvious answer is collaboration, but how is that collaboration achieved? Emails? Nobody pays attention to them. Conference room meetings with whiteboards? People will pay attention half the time and then get bored. Team messaging tools? They do facilitate workflow and communication, but still often lack the real-time interaction necessary for getting a true understanding of the project’s requirements.

    Videoconferencing Integration Meets the DevOps Challenge

    New forms of collaboration have been a major catalyst for new development initiatives over the past year, with cloud-based systems have shown the greatest potential. Simple tools such as Office 365 or Google Docs allow users to share and co-edit documents, while Slack, Zoom and other communication tools allow for easy group communication. However, videoconferencing has been shown to have the greatest potential because of its real-time and highly visual nature, and its use has become much more practical with the ubiquity of 4G and high-quality cameras on smartphones and laptops.

    DevOps is as much about creating a culture of collaboration and sharing as it is about specific development tools and tactics. Videoconferencing facilitates the cultural aspect of DevOps, an especially important factor given that teams are often in different physical locations. Even when those functional teams are in the same building, it is common for those teams to operate in a silo. Creating an inclusive and interdepartmental DevOps team is always the starting point, but getting those teams to communicate requires a cultural change—and a little boost from videoconferencing and other collaboration tools.

    Integrating and Executing Videoconferencing in DevOps Environments

    When it comes to video conferencing in the workplace, businesses have to stop taking a laissez-faire approach to integration and execution. While they may assume it’s as simple as plugging in a solution and getting to work, it often requires much more technical competence and involvement from the appropriate parties. 

    For starters, the IT department needs to be involved in its deployment. There’s a lot to consider from a technical perspective before you can even begin to think about details related to specific software solutions and platforms.

    Cloud-based systems have made deployment of videoconferencing and other tools simple, and there is a growing tendency for departmental managers to source and deploy their own tools in a “shadow IT” approach. But since the goal is inter-departmental communication, in this case IT should play the central role in its deployment and execution.

    One of the issues organizations need to think about is how the integration of video technology will affect current processes. The goal of video is to make things more efficient, not to drag processes down.

    It’s also wise to consider how much videoconferencing will be used and whether it’s better to have multiple small-video equipped rooms or one larger, more expensive boardroom setup.

    While IT involvement is vital for successful implementation and execution, it’s not the only factor involved. Failing to involve outside sources can actually result in an incomplete setup.

    “IT departments are incredibly adept at managing network, servers, processes, and internal applications. They know their business and the needs associated with it,” noted videoconferencing provider IVCi in its blog. “However, in certain circumstances deploying videoconferencing can require an organization to act more like a service provider, rather than an IT department. IT departments are rarely experienced in video conferencing implementations and are forced to learn while doing.”

    This lack of experience has become increasingly evident over the past few years—something that The New York Times recently exposed in a story on the lack of security in many videoconferencing systems in major organizations.

    The article exposed a story in which a security chief assumed the role of “hacker” to find holes in his client’s network security. What he found was alarming. While companies spend millions on securing their networks, he was able to hack into multiple conference rooms relatively and control the cameras with relative ease.

    “Many systems are sold, installed and maintained without any level of access security, with auto-answer enabled by default,” the “hacker” HD Moore said. “It boils down to whether organizations are aware of the risk, and our research indicates that many, even well-heeled venture capital firms, were not aware and do not implement even the most basic of security measures.”

    It’s not just security, though. Many businesses simply don’t know how to use their video conferencing solutions. The IT department might understand how the system works, but individual users don’t even know how to start a video session. This results in cumbersome processes that reflect poorly on the business, especially when video is used in client-facing situations.

    It’s Time to Take Video Seriously

    While business leaders spend a lot of time talking about how to be successful with videoconferencing, in terms of knowing what to wear and how to interact with participants, very few take implementation, security and execution seriously. Until it’s given the priority it deserves, videoconferencing will lag in organizations.

    — Dan Blacharski

  • Inclusion, Collaboration and DevOps: Seeing the Bigger Picture

    Inclusion, Collaboration and DevOps: Seeing the Bigger Picture

    The last half of 2017 was pretty amazing. I wrote a brief post about the Inclusive Collaboration Summit I attended in London last July. Sallyann Freudenberg and Katherine Kirk started this campaign to raise awareness around neuro-diversity in tech. With respect toward the silence experiments I kept my original post very short. It was great to participate in the silence experiment in London and to help Sal and Katherine with their workshop in Orlando after I returned to the United States, but that’s not the whole story. I offered to facilitate a Wardley mapping workshop while in London in an effort to help the Inclusive Collaboration Campaign form a strategy.

    Coincidentally, enough I also ended up helping Simon Wardley organize the first Map Camp in London last year. While I didn’t get a talk accepted into Lean Agile Scotland and wasn’t expected to speak at Map Camp either, I decided to make the trip back to the UK in October to attend both events as a volunteer. It’s great to get a chance to speak at conferences but I think it’s important to occasionally show up in another capacity as well. I’ve even gone so far as to buy a ticket and show up at an event as a garden variety attendee.

    Both of these events were the same week in October, with Map Camp right in the middle of Lean Agile Scotland. In what one might consider a lapse of judgment, I decided to spend that week traveling between Edinburgh and London on planes, trains and automobiles. Due to a speaker cancellation at Map Camp, I was able to give a short presentation on the mapping approach I used for the workshop at the Inclusive Collaboration Summit earlier in 2017. I also helped Sal with a workshop on sensory perception in Edinburgh. Simon was running a mapping workshop on the last day of Lean Agile Scotland as well, so we had a bit of a race from England to Scotland. He left on a sleeper train right after Map Camp while I took a plane out the next morning. Simon ended up beating me there and I owe him yet another cup of tea. Still, I somehow managed to make all my flights and appointments while I was in the UK, but I didn’t have much time to take in any of the scenery while I was out of town.

    At some point I accounted for this and booked a seat in the quiet coach on a train back to London from Edinburgh. I knew I’d be exhausted and would need some down time to decompile before heading back home. As the train left the station, I crossed off my last checkpoint for the trip and tried to relax a bit before flying back to the United States. As with any journey, this last checkpoint was an appropriate time to pull out the maps from the ICC workshop in London to see how we were doing and what might be next.

     

    Diversity and inclusion are a common conversation in tech these days. They remain a priority at Map Camp as well, which is why we had a pool of diversity tickets reserved and did our best to include as many folks from different walks of life at the event as we could. Diversity and inclusion can and should be improved continuously. If you can’t take my word for it, then maybe this compilation of G.I. Joe public service announcements will convince you. Like Gung Ho says, “Don’t judge people until you give them a chance!”

    Simon got right to planning the next Map Camp as soon as he left London for Edinburgh. I wanted to jump right back in to Map Camp, too, but hosting an Inclusive Collaboration conference was a stretch goal that came out of our mapping session in July, and I had devopsdays Atlanta 2018 to think about as well. The least complicated thing I could do was make Inclusive Collaboration the theme for devopsdays 2018, so that’s exactly what I did. I was geeking out about trains at the time, so of course devopsdays Atlanta will have a train theme this year as well.

    The train theme is more relevant than you might think at first glance. Trains, like any technology we have, are part of a larger socio-technical system. If your system doesn’t have any people in it I’d suggest taking a step back and trying to look at the bigger picture. Of course, you can look at just the train from a purely mechanical perspective, but cutting out the societal impact of expanding travel options and connecting people, not to mention the social impact the construction and operation of railroads had on so many communities, really understates the global impact of the technology. I looked for songs about trains to listen to on the way back from Edinburgh and was amazed at not only how many there were, but how many different decades, genres and cultures were represented in the list. I found this list of about 1,000 train songs, but even the article admits the set is incomplete and the total number of songs about locomotives is likely uncountable. The fact that we’re still writing songs about trains today really goes to show the permanence of the impact railroads have had on our human race.

    The DevOps community is adamant that DevOps isn’t about the tools. We’ve also heard time and time again that containers will not fix our broken culture. I had a long chat with Simon while in Edinburgh over his concerns that the community is about to make the same mistake again with serverless technology. No, serverless isn’t going to fix our broken culture, either. Similar to trains, it’s time to zoom out on the technical details so we can bring the social impact of modern computing into our frame of reference.

    This isn’t news, but like the title of the post says, knowing is only half the battle. We have to actually get off of our asses and try to do something about it if we want anything to change. I’m glad to have Sallyann Freudenberg traveling from England to Atlanta this April to deliver a keynote. I’m glad Jamie Knight and his friends, Lion and Mike Southgate, will be in town from London to spend some time with us in Atlanta, too. I’m excited to hear what Atlanta’s own Kim Crayton, a technologist with a background in special education, will bring to this conversation as well.

    I don’t have any silver bullet answers for the social issues we’re facing in tech today and I doubt we’ll get things sorted in Atlanta this April, but I do know we’ve got some very well-qualified individuals showing up and there will be a lot to learn over the course of two days. Cloud computing, CI/CD practices and the typical tech content seem like known, solved problems to me by comparison, but we’ll be sure to have some folks talking about these topics as well. It’s not a question of social or technical, but rather, How do we do a better job of building and operating socio-technical systems?

    In addition to Map Camp 2018 this October, there may be an Inclusive Collaboration Summit in London later this year. The details on both of those events are still getting sorted out. What I do know for sure is you can join us in Atlanta this April and I sincerely hope you can make it. Early bird tickets are still available and our CFP is open until March 1. Please join us.

    — Chris Corriere

  • 6 Must-Haves When Using Chat for Incident Management

    6 Must-Haves When Using Chat for Incident Management

    Over the last few years, teams have realized the benefits of sharing and distributing knowledge in chat applications such as Slack. Today, teams are extending the use of these applications beyond collaboration by embracing ChatOps. ChatOps empowers teams by bringing complex day-to-day operational work into shared chat channels. If done correctly, it drastically reduces context switching and increases the speed at which teams can tackle tough challenges.

    Companies are realizing incredible benefits by incorporating ChatOps into their incident management workflows. Chat channels provide hyper-effective means to alert teams of issues, take immediate action and collaborate with clarity and urgency. It is for this reason that companies including OpsGenie, PagerDuty and VictorOps have invested in integrating their incident management applications into chat applications such as Slack, HipChat and Microsoft Teams.

    ChatOps to the Rescue

    Ideally, users of a modern incident management solution need to have access to a multitude of features so that they can address specific challenges directly within the chat tool. During an incident, switching between applications to access and collaborate on the actionable data is a waste of time. Keeping the conversation and action in one place, where team members already are, is the key to a fast and successful incident resolution process. That is why ChatOps has emerged as an alternative to the war room concept.

    To get the most out of the technology and resolve problems more quickly and easily, here are six tips to consider when using ChatOps for incident management:

    1. Post Messages with Clarity

    The basic requirement for integrating any application within chat tools is to simply have messages posted within chat channels. However, there are three additional needs to consider when integrating an incident management tool into chat when increasing efficiency is the goal.

    • The integration must be able to post chat messages regardless where the incident originates and additional information added (monitoring, ticketing, or collaboration tools).
    • Messages need to be customized based on the specifics or severity of the incident. Often the basic message needs to be appended with tags or additional information fields.
    • If possible, include a button in the message that allow responders to take instant, prescriptive actions.

    2.  Control How Information is Shared

    Posting every alert and comment into a shared channel can quickly become overwhelming and is considered bad practice. A strong integration enables the creation of separate channels for specific responders and have direct control over what types of alert and follow-up messages are shown.

    A seamless integration also provides the flexibility to receive only the incident actions that are decidedly relevant. Low-priority issues that don’t require immediate action can be filtered and not sent to the chat stream, ensuring the team stays focused on what really matters.

    3. Accelerate Actions

    ChatOps transforms chat into a vehicle through which users take actions and deploy solutions. This virtually eliminates the need for operations teams to switch between applications when responding to an incident.

    Most integrations enable users to execute incident actions using text commands. This method is valid and often preferred. However, deeper integrations simplify tasks by providing interactive buttons that enable users to begin working on incidents with just a click.

    The value of responding to an alert by clicking a button extends beyond simple alert acknowledgement. Enabling all common responses (i.e. assigning an alert, taking ownership, adding notes, muting incidents, etc.) to be executed in this manner accelerates resolution and unlocks the real power of ChatOps.

    4. Instantly Retrieve Supporting Information

    A challenge of a long chat thread is that critical information can get lost within the communications or additional information may be needed. A user might have to leave the channel to look up important details and related information, such as looking at other open incidents, for example.

    The integration of an incident management system into the chat environment needs to allow users to access supporting information at any time. The ability to query not only additional details about a specific incident but also general information regarding on-call schedules and alert policies is a requirement. By empowering team members to access this data directly within the chat interface, they stay focused and are able to respond in the most efficient manner possible.

    5. Create New Alerts

    A common task when managing an incident is to create manual alerts. Again, requiring people to switch applications to complete this task is a distraction and slows the progress.

    Creating new alerts for a team or service right within the chat channel is a necessity. The incident management system then notifies the person on-call automatically. Having the ability to create an alert directly within chat empowers individuals that may not have direct access to the incident management system to report problems efficiently.

    6. Control Access

    When an incident occurs, it is important that corrective action is taken by only the people who are authorized to respond. Mapping (or linking) the chat users to the users within the incident management system enables this level of control.

    Linking the user profiles between the chat and incident management has additional benefits. As alerts are acknowledged and responded to within the chat environment, the events are recorded within the incident management solution. A clear history describing who took each action is recorded for future reporting and analysis.

    While there are many things to consider when integrating incident management into a chat application, the benefits are clear. Response time, ability to collaborate, and team access to incident details are crucial factors for incident resolution.

    About the Author / Serhat Can

    Serhat Can is a Technical Evangelist for OpsGenie. He has contributed to different parts of OpsGenie as an engineer and now tries to spread the word by coding, writing and talking about DevOps. He is still a proud member of the on-call schedules. Follow him on Twitter and connect with him on LinkedIn.
  • How to Succeed with DevOps by Outsourcing Software Development

    How to Succeed with DevOps by Outsourcing Software Development

    The DevOps journey can be successful when you use offshore outsourcing software partners, but it requires careful attention from your IT leaders.

    The old saying, “The only constant is change,” has never been more true for software development, whether your company is a SaaS provider or a manufacturer of discrete products that rely heavily on software delivered by your IT department. For the past several years we have seen four key movements:

    1. The continued adoption of outsourced software development. As far back as 2013, it was reported that 2 out of 5 CIOs surveyed planned some sort of outsourced software development for the coming year.
    2. Increased outsourcing options. While outsourcing to India is still a legitimate option today, it’s certainly not the only viable option available. Companies are now able to answer the question: “What country will provide my outsourced programming team?” in multiple ways.
    3. Agile as a mainstream methodology. Software development teams continue to embrace Agile as the preferred methodology for software development projects.   
    4. Interest in—or adoption of—DevOps. Since the term “DevOps” was introduced by Andrew Shafer and Patrick Debois at the 2008 Agile conference in Toronto, large and small companies alike have shown increased interest in embracing DevOps and the promise it holds for rapid software deployment.

    The current state of tools and service provider capabilities should entice IT leaders to adopt (or continue to adopt) DevOps methods for software development. More than ever before, there are capable teams of programmers across the globe that you can tap into for a successful software.

    There is No Substitute for Good Process

    The goals of higher output and greater efficiencies and even “continuous deployment” through DevOps have their roots in elite manufacturing methods such as kanban and lean manufacturing. Like its manufacturing method cousins, DevOps success hinges on good process. To see improvements through the use of DevOps, you must have clear understanding (and description of) your current software development process. You need to communicate your processes clearly in words and pictures with your outsourcing partner. Issues that are birthed out of shortcomings in your DevOps process will be exponential when you add the variable of outsourced development into your work steps.

    Key Takeaway: DevOps is only possible through good process. If you’re not committed to good analysis and continual improvement of your processes, then the use of an outsourced software developer will only allow you to create flawed software and generate chaos more rapidly.

    Tools Create Speed

    If good process is the engine of DevOps, then automation tools are the gasoline that makes the well-designed process run with speed. Automation of good process makes it possible to eliminate bottlenecks in the software development cycle—you can truly “sprint through your sprints.” Perform an inventory of your tools:

    • Are you able to seamlessly (and automatically) promote code?
    • Can you perform test-driven design?
    • Can you perform test-driven development?
    • Can you easily associate features and fixes with promoted code?
    • How do you perform regression testing?

    Key Takeaway: Automation tools must be used with consistency by you and your outsourcing partner. These tools will enable the process that you all follow daily in the development activities of your project.

    Choose Wisely

    Having the right outsourcing partner for software development is important. To outsource successfully in a DevOps approach, you must be very selective in your choice of an outsourced software development team.

    • The best partners employ a programming staff that have achieved the major certifications that are important for your DevOps project needs. Moreover, a good partner invests in its programming staff’s training on a continual basis. We like to see evidence that its programming staff regularly renews their certifications.
    • Experience. Equally important is having a software outsourcing team with demonstrated experience in your business vertical (example: discrete manufacturing, banking, etc.) and expertise in the system functional area (e.g. finance, e-business order processing, warehouse management, etc.). Of course, the software development team also should be versant and have demonstrable experience in the use of Agile and DevOps techniques.
    • The right partner should be neither too large nor too small. The outsourcing company needs a pool of programmers large enough to keep with the intended work pace of your project. Conversely, we caution IT managers to be wary of extremely large outsourcing companies. Your project and company must be “big enough to matter” to the partner you select. If you are seen as too small in terms of the revenue opportunity, the outsourcing company will defer attention and its top talent to larger customers, who are more able to influence decision-making.

    Key Takeaway: To succeed with DevOps outsourcing, you need the right partner, based on attributes of skills, demonstrable experience, and a size that’s proper for your company.

    Metrics Matter

    John Adams, the second U.S. president, once famously said, “Facts are stubborn things.” DevOps presumes a culture of continuous improvement—and our metrics help demonstrate that improvement. We collect metrics so we can accurately measure pace of work, quality of software produced, level of effort and so on. We measure events over time to see if we are improving, worsening or stagnant. Metrics are a critical means of communication and mutual accountability between your company staff (IT and business) and the outsourcing partner who is writing your software. In a DevOps-driven outsourcing relationship, you’ll regularly capture and report on metrics (estimated and actual) such as:

    • Lead Time: In software development, you need to measure the time elapsed from concept to the point delivery of the completed software. From project to project or even epic to epic, you want to see an increase in speed to deliver software.
    • Sprint Time: Teams using Agile will have sprints measured in a few days, instead of months, for the typical time for work grouped in “phases” or “activities,” using traditional development methods. Be sure to track metrics for your sprints.
    • Sprint Volume: How many sprints are needed to complete a story? How many sprints are needed for a version? For each of these metrics, look for consistent volume (i.e. number of sprints produced) over time.
    • Issues and Open/Close Rates: Measure how many production issues are reported AND closed within a specific time frame. Observe and take action on trends rather than establishing a hard and fast number; there’s no “right answer.”

    Key Takeaway: Metrics allow you and your outsourcing partner to objectively assess the pace and quality of rapid work being performed in a DevOps/Agile-driven development project.

    Collaboration is Key

    It almost goes without saying that you and your outsourcing partner will need to have good, regular rhythms of communication. This continuous collaboration is essential because you and your vendor-partner team are:

    • Operating in a common disciplined way using DevOps methods.
    • Performing work through a common set of tools.
    • Progressing through the project goals in a series of rapid sprints.
    • Capturing and analyzing team metrics to ensure project health.

    Honestly assess what barriers might exist to good collaboration. Do you need to ramp up your real-time collaboration tools? Do you have a master calendar of formal meetings where the agenda will drive good information-sharing, decision-making and issue resolution?

    Are time zone differences an issue? This may affect the geographic location from which you will select your outsourced development team. In a recent survey, one-third of U.S. companies that outsourced to India considered the 10-hour (or more) time difference to be a big challenge. Very often the “core team” in an outsourcing software provider will be working hours that are completely opposite of normal U.S. business hours. Some companies find that a “nearshore” outsourcing partner helps optimize collaboration. Because the outsourcing partner is in the same time zone as your IT leadership team, it’s easier to schedule meetings or even have impromptu discussions, which are so important in software-development methodologies such as Agile.

    Key Takeaway: DevOps and Agile require high collaboration. Set yourself up for success by ensuring there will be no reasonable impediments to good collaboration.

    A Perfect Storm – and Opportunity

    The recent evolution in best thinking and adoption of DevOps, and the parallel growth in options for software development outsourcing together create a kind of perfect storm in software development. The potential of DevOps is augmented by the inherent continuous-change nature of Agile. We see the ability to transfer work across the “virtual shop floor” of development without geographic constraints. This new programming paradigm of DevOps, partnered with Agile, is now matched by equally exciting (and relevant) growth in the options for delivering high-quality code from anywhere across the globe.

    About the Author / Steve Mezak

    Steve Mezak is founder and CEO of Accelerance, a leader in global software development outsourcing, as well as the author of “Software Without Borders,” co-author of, “Outsource or Else: How a VP of Software Saved His Company,” and a CIO columnist.