devopsy.kinsta.cloud

Tag: communications

  • JFrog Integrates DevOps Portfolio With Microsoft Teams

    JFrog Integrates DevOps Portfolio With Microsoft Teams

    JFrog this week announced it has integrated its DevOps portfolio with Microsoft Teams to enhance collaboration.

    Deep Datta, a senior product marketing manager for JFrog, said JFrog Artifactory repository and the JFrog Xray software composition analysis (SCA) tool have been integrated via a JFrog App for Microsoft Teams tool that is now available.

    The goal is to make it simpler for DevOps teams to collaborate with other members of an organization that has standardized on Microsoft Teams for collaboration, said Datta.

    In general, as more organizations are realizing how dependent their business is on software, individuals ranging from application owners to cybersecurity professionals are now looking to collaborate with DevOps teams, noted Datta. In fact, in many cases, business process workflows now need to align with DevOps workflows as businesses become more dependent on software, he added.

    While many DevOps teams already use a range of collaboration tools, many of those same teams also need to access Microsoft Teams to engage individuals outside of those teams, said Datta.

    The emerging challenge is the number of communication channels that DevOps teams now find themselves using. Each new communication channel added doesn’t necessarily supplant existing platforms; it’s not uncommon for DevOps teams to use Microsoft Teams alongside Slack as well as traditional email depending on the type of messaging and collaboration required. In some cases, for better or worse, DevOps teams find themselves required to juggle multiple collaboration platforms over the course of any application development project.

    In general, the relationship between DevOps teams and the rest of the business is evolving in the age of digital business transformation. The pace at which applications are delivered and updated now has a material impact on business goals. Organizations are finding they need to align everything from marketing and customer support to financial planning with software development. A delay in one software development project can have a cascading effect that impacts every aspect of the business. The sooner information is shared via a collaboration platform the easier it becomes for the rest of the business to adapt and respond.

    Naturally, not every DevOps team is excited about the level of transparency required. Many issues a software development team would previously have handled internally are now exposed to the agenda of the board of directors. Application delivery and update deadlines are influenced more heavily by revenue goals than the available developer expertise. The key to managing all those expectations is to communicate more frequently. However, all that communication can also take time away from building applications. It’s important to isolate development teams from distractions—like a constant barrage of messages shared with multiple lines of business and across multiple communication channels.

    Of course, the only thing worse than all those messages is a failure to communicate critical information in a timely fashion. The challenge is to find a way to filter out all the noise and get critical information to the right person at the right time.

  • Private and Virtual Private LTE/5G Challenges Network Visibility

    Private and Virtual Private LTE/5G Challenges Network Visibility

    Digital transformation continues to disrupt the entire IT stack by shifting nearly every paradigm, including the new blurring lines between network infrastructure. New mobile network technologies are at the cusp of adaption in the enterprise networks with a growing number of innovations poised to enable expanded and more flexible connectivity with a gradual displacement of traditional Wi-Fi networks.

    The evolution began as new unlicensed radio frequencies become a part of the 3GPP 5G Release 16 mode of operation. This new mobile mode of operation has the ability to offer the necessary technology for mobile network operators (MNOs) to operate the unlicensed spectrum into 5G networks and make some of it available for corporate networking. New standardization will enable the enterprise networks to gradually adopt these new mobile networks to their connectivity framework, in order to leverage the benefits of new modern applications and alignment to their connectivity, scale and quality of service requirements.

    With the benefits of a new mode of connectivity – in a converged fixed or pure mobile infrastructure – there are always measurable risks that require attention. Specifically, the new mode of connectivity brings potentially new security threats and operational challenges that need to be addressed.

    New Operating Modes

    It is likely that incorporating this mobile technology will require starting from new operational modes; these will be imperative to grasp the direction and the adaption of private mobile networks in reality. Industry hype is certainly driving the trend towards the mode in which the corporate IT teams will be capable to deploy and operate the new private mobile network. However, at this point in time, the more realistic option will be that full control of design, deployment and operation will be from the MNOs, as they have strong experience, knowledge and risk mitigation capabilities. This mode of operation is also incentivized through the business aspects of creating a new revenue stream for the MNOs. This higher-margin business can provide more stringent security operations, particularly in light of better understanding the vector of attacks. Such an approach provides carrier-grade operations with the commitment of a service level agreement and correlation to the required corporate business agility and continuity needed by the enterprise.

    Questions like the who, what and where of network traffic need to be answered to prevent security threats and maintain network performance and reliability—in essence, identifying and maintaining the identity of the mobile subscriber in a complex hybrid model of mobile connectivity. A corporate mobile network can be completely private, well isolated from other networks with no roaming into the public network. It can also feature a less stringent traffic policy using a virtual slice of the private network with a segmented perimeter in which certain traffic will roam into a public network and will be tracked with respect to subscriber-aware policy. This latter option is a greater challenge because of the inherent separation of data or user and control planes in mobile network architecture is virtual rather than physical. Additionally, new mobile 5G architecture includes virtualization and network slicing to offer valuable versatility and scale, but it also makes NetOps and SecOps monitoring and control even more challenging. In light of the complexities, we can assume that the favorable and practical mode of new corporate mobile networks will be outsourced to an MNO that will operate in tight synergies with corporate IT teams. Their work will be based on a defined playbook to drive a gradual evolution of architectural reference models and pragmatic learning curve for corporate “do it yourself” operations mode. Complexities multiply in cases related to IoT and manufacturing applications in which the mobile core is required to be closer or co-located with the edge to support low latency and high throughput requirements.

    5G features a separation of data/user and control planes that is an architectural advantage, particularly helpful for large IoT deployments, dynamic scalability and services and higher data rates with greater bandwidth efficiencies. It offers more distributed processing for greater scale and less susceptibility to a single point of failure. It also represents a shift from best-effort networks to ones that can provide better, more differentiated levels of services and prioritization. This separation requires a new approach for network visibility to understand who is doing what. This is an issue for security as well as networking performance.

    The Challenge of Virtualized Network Functions

    Another challenge is that 5G virtualizes in software the higher-level network functions that traditionally have been performed by physical hardware. This virtualized network slicing means a sharing of physical resources that expand the attack surface by offering the potential for a sophisticated attacker to traverse from one virtual instance to another knowing that it will be difficult for security teams to detect this lateral movement. In addition, 5G radio network deployments may include significant expansions of small cells connecting in a campus geographically distributed environment, machine-to-machine communications and dynamic connections to multiple cells. All of these present a new frontier for attackers and new challenges for IT operation teams. Organizations need visibility and understanding of these new infrastructure resources to ensure a clear design and implementation to prevent security breaches and disruption of business continuity.

    The potential for significant expansion of IoT devices on corporate networks using 5G offers important advances for measuring and monitoring devices or making everything connected. At the same time, these lean devices generally have far less endpoint controls—particularly robust access control—than traditional computing devices, and it is difficult to add such controls directly to each unit. The rise of more IoT machine-to-machine communication and away from a hub-and-spoke model adds additional complexity. A proliferation of such devices also intensifies the need for deeper visibility and more automated security to scale with these deployments without the bottleneck of human intervention for each. This adds risks to the internal IT learning curve, making it an unlikely option and again, favors outsourcing to MNO experienced teams to design, deploy and maintain the corporate private mobile networks.

  • AWS Aligns With Slack to Foster Dev Team Collaboration

    AWS Aligns With Slack to Foster Dev Team Collaboration

    Amazon Web Services (AWS) and Slack Technologies have formed an alliance through which they are moving to transform the way development teams collaborate.

    Under the terms of the multi-year agreement, Slack will migrate voice and video calls to the Amazon Chime real-time communications service.

    In addition, AWS and Slack are integrating Amazon AppFlow integration with Slack, which enables data to be transferred securely between Slack and AWS services such as Amazon Simple Storage Service (Amazon S3) and Amazon Redshift. The two companies are also promising to make it possible to transfer data bi-directionally between multiple Slack channels and AWS services in a single flow.

    AWS and Slack have also integrated the AWS Key Management Service with Slack Enterprise Key Management (EKM) to distribute and control cryptographic keys. That capability builds on an instance of EKM for Slack’s Workflow Builder automation tool that was released last month.

    Finally, the two companies are committing to make the AWS Chatbot service accessible from directly within Slack.

    Slack, which already makes extensive use of the AWS cloud, has emerged as a de facto collaboration tool within many organizations that have embraced best DevOps practices. Eron Kelly, head of product marketing for AWS, said this alliance will make it easier for development teams to employ a wide range of communications tools at scale.

    Many DevOps teams already rely on Slack Calls to launch video and voice calls whenever a subject being discussed using text messages requires a deeper level of interaction. As reliance on Slack Calls increases, the software development kit (SDK) for the AWS Chime service that Slack will invoke will ensure the quality of the video and voice calls, said Kelly.

    In many ways, DevOps processes revolve around a mix of asynchronous and synchronous communications. The challenge has been to find a way to enable DevOps teams to use those tools in a way that enhances rather than detracts from productivity. Managing multiple Slack communications channels can easily become overwhelming, especially if developers are working on multiple projects at the same time.

    Ideally, DevOps teams will eventually become more adept at determining, for example, what messages, such as status updates, are best delivered asynchronously versus urgent requests that need to be made via a communications medium such as Slack.

    In the meantime, the COVID-19 pandemic has clearly increased reliance on communications services delivered via the cloud. With most members of DevOps teams working from home, tools such as Slack have become a virtual substitute for walking over to the next cube in an office to resolve an issue. Once development teams return to the office, it will be interesting to see to what degree tools such as Slack have become the default means of communication, even with fellow employees who may be only a few feet away. In fact, such tools may play a critical role in helping organizations adhere to social distancing policies even after employees return to the office.

    As philosopher Marshall McLuhan once observed, the medium is the message. Today, however, those messages increasingly are being delivered within a stream of real-time communications that is becoming more challenging to manage.

  • LaunchNotes Adds Communications Tool for App Release

    LaunchNotes Adds Communications Tool for App Release

    LaunchNotes today launched a namesake software-as-a-service (SaaS) platform for managing the communications surrounding the release of an application.

    Company co-founder Jake Brereton said LaunchNotes streamlines internal and external communications for DevOps teams, eliminating the need to employ a collaboration tool such as Slack or a project management application.

    Each message can be designated as either a private communication for the internal DevOps team or shared publicly with business shareholders. Instead of having to subscribe to yet another Slack channel, business stakeholders now have a dedicated and easier means to track the progress of application releases, said Brereton.

    Communications surrounding application releases have always been problematic. Most applications are developed using multiple platforms, so standardizing the communications tools provided by those platforms isn’t usually practical. LaunchNotes is designed to provide an easy way to manage communications regardless of the platform employed to build and deploy an application, Brereton said.

    DevOps teams can also post things such as articles that might, for example, explain the history of any given application development project, he added.

    Interest in application release timetables has never been higher. In the age of digital business, more organizations than ever have come to equate with revenue the rate at which applications are deployed and updated. However, it’s not always been easy for business leaders to decipher the release notes that DevOps team members routinely share with one another. LaunchNotes is meant to provide a means for DevOps teams to communicate privately with one another while creating a separate channel within the same platform to share frequent updates in plain language in real-time with other members of the organization.

    The issue with Slack and other communications platforms is they have become too noisy, noted Brereton. In the stream of updates being provided about things going on inside the organization and beyond, it can be easy to miss a critical update about an application release.

    LaunchNotes has been available through a private beta involving 60 organizations. The company views its platform as a complement to project management applications rather than a replacement. The sole focus is on streamlining DevOps communications, said Brereton.

    To one degree or another most DevOps teams suffer from a failure to communicate. Most of the time that failure is not because a message wasn’t shared; rather, the medium employed to deliver that message made it easy to miss or be misconstrued. If the medium is the proverbial message, then DevOps teams might be better off employing a medium designed specifically for optimizing application release cycles.

    Of course, many organizations will continue to employ the communications tools that are most readily available. However, those general-purpose communications platforms also make it easy for users to be distracted by everything from messages from human resources about the latest form to be filled out to who won the football pool this week.

  • Twilio Adds DevOps Tool to Invoke Communications Services

    Twilio Adds DevOps Tool to Invoke Communications Services

    At its annual SIGNAL conference, Twilio today launched an initiative intended to make it easier to embed a variety of communication services within an application in the context of a DevOps process.

    Quinton Wall, senior director of developer marketing at Twilio, said the open source Twilio Command Line Interface (CLI) tool, now available in beta, will make it possible to incorporate Twilio cloud services within a larger DevOps toolchain.

    Twilio provides developers will access to a range of SMS, audio and video services that can all be incorporated into applications via application programming interface (API) calls. The pipelines created using those APIs now can be stored and shared via GitHub.

    The CLI tool also makes it possible to extend those services via Plugins, said Wall. In addition, DevOps teams can invoke an existing serverless computing capability from Twilio to invoke the company’s services using functions, added Wall.

    It’s not clear to what degree cloud services such as Twilio will be invoked using serverless computing frameworks going forward. Many of the capabilities that developers once were required to embed in their applications are set to become external services that applications call when needed by launching a function. While that approach makes the application more efficient, it puts additional pressure on IT teams to manage all the calls to various serverless computing frameworks within the context of already complicated DevOps pipeline.

    While serverless computing frameworks are still an emerging IT platform, the rate at which serverless computing frameworks are being adopted suggests the day when they are commonly included with a DevOps toolchain is not very far off.

    In the meantime, Twilio is clearly hoping that by making its communications services easier to invoke within the context of a DevOps toolchain will increase consumption. Twilio has long exposed REST APIs, but the CLI tool will make it easier for organizations to standardize on Twilio communication services across a range of applications. By exposing those services via APIs and a CLI tool, Twilio is betting that the days when end users opened a separate application to communicate are numbered. Instead, most users will invoke communications services within the context of, for example, a business intelligence application that is already open. That approach also eliminates the need to invest in dedicated network hardware to run unified communications applications that, from an API perspective, are often more difficult to invoke programmatically.

    As DevOps processes become more widespread, it will be interesting to see how many other providers of cloud services start to routinely make available CLI tools. Arguably, any provider of a cloud service that doesn’t make a CLI tool available will find themselves on the outside of a DevOps process looking in. Service providers that provide a CLI tool will be preferred among organizations that embrace best DevOps practices. In fact, the challenge DevOps teams soon may face is not whether there is a CLI tool available, but rather determining which of the many available best fits within the DevOps processes they have adopted.

    — Mike Vizard

  • DevSecOps Survey Finds Failure to Communicate

    DevSecOps Survey Finds Failure to Communicate

    While it’s generally agreed that shifting more cybersecurity responsibility onto the shoulders of developers is a good idea, a failure to communicate across application development and cybersecurity teams has contributed to little progress in achieving DevSecOps.

    A survey of 1,310 IT decision-makers conducted by the market research firm Vanson Bourne on behalf of Trend Micro finds that while nearly three-quarters of respondents (74%) said integrating developer, IT operations and cybersecurity processes has become more important over the past year, more than one-third (34%) said these silos are making it more difficult to create a DevOps culture in the organization. A full 89% said software development and IT security teams needed to be in closer contact, while 77% said the same for developers, security and operations.

    Greg Young, vice president of cybersecurity for Trend Micro, said the two biggest challenges in achieving DevSecOps historically are the lack of trust between developers and cybersecurity professionals and a lack of tooling to foster collaboration and communication across teams.

    The rift between developers and cybersecurity is well-known: Application developers have been known to give short shrift to cybersecurity guidelines to make a deadline, only to have that application breached in a production environment. However, developers can counter that cybersecurity professionals can slow things down too much, in the name of being overly cautious.

    Young said organizations need to find tools that make it easier for those two teams to establish trust within the context of an integrated DevSecOps process. Rather than just relegating cybersecurity teams to defining policies, cybersecurity professionals need to find a way to provide input during all stages of the application development process without compromising the overall agility of the development team, he said.

    In fact, survey respondents identified fostering greater integration between teams (61%), setting common goals (58%) and sharing learning experiences across teams (50%) as the best ways to achieve DevSecOps. The trouble is, 78% of respondents said their organization needs to improve in all these areas.

    Unfortunately, nearly half of respondents (46%) said they have only partially developed their DevOps strategy, with only a third of respondents (33%) saying DevOps today is a shared responsibility between software development and IT operations.

    Regardless of how organizations achieve DevSecOps, the one certain thing is most organizations have no alternative. The rate at which applications are being developed today generally exceeds the ability of short-handed cybersecurity teams to keep pace. The only way to make sure applications are more secure than they have been historically is to make implementing security controls part of the application quality assurance process. That said, cybersecurity teams most likely will take a “trust, but verify” attitude toward developers to ensure the right controls have been put in place.

    Of course, none of this is going to happen of its own accord. Senior leaders need to make DevSecOps best practices a requirement. Otherwise, DevSecOps will always remain one of those many aspirational IT goals that go unfulfilled.

    — Mike Vizard

  • With DevOps Culture, It’s Mind Over Matter

    With DevOps Culture, It’s Mind Over Matter

    There is quite a bit of conversation about tools versus culture, and sometimes, those constantly involved in the back-and-forth forget that not everyone is so steeped in the finer points of the conversation.

    Tools is the easy part. There are a ton of tools available to optimize IT operations, from small bespoke products such as the Antsle Private Cloud Server to CA’s broad suite of Dev/Test/DevOps/ARA tools. There are plenty of places to find lists or charts of tools, and I’ll leave you to them, just mentioning the two I’ve written about in the not-too-distant past: Xebia Labs’ Periodic Table of DevOps, and CA/Automic’s Continuous Delivery Landscape.

    My youngest just built a Cube-solving robot, so this picture inspired me.

    But what of culture? When pundits and old hands talk of culture, what exactly are they talking about?

    Well, it still varies a bit from organization to organization, but there are some definite underlying foundations.

    Increased Cross-Team Communications

    Even if an org is full-on DevOps, there is still the requirement of cross-team communications to make sure everyone understands what is going on.

    One of the things that this does not make abundantly clear, I will belabor a bit (sorry, old hands). Communications is not just talking. It is not just email exchanges, it is not just sitting in another team’s meetings while researching your current problem on your phone.

    It can be these things, but it is a breadth of options. People are using Slack channels to keep everyone updated, common notifications or even pub-sub systems to make certain information about the state of IT, operations and builds are getting wide distribution. Increase communication, not chatter.

    Organizational Change

    You hear that a lot, and it can mean complete overhaul of an IT organization, but in an enterprise setting, it rarely does. The reason is simple. There may only be one or two Cisco specialists, or one or two EMC specialists, and these people don’t properly belong on one or two product/project teams in the long term. The same goes for security and a whole further swath of operations team members.

    So in the enterprise, what “organizational change” often means is moving those responsible for development and core deployment closer together on small, product- or portfolio-based teams. Networking staff, security staff and infrastructure staff will join the teams as needed, but are not part of the core team.

    Management Change

    This is another often spoken-of mantra that easily can be misunderstood. In short, managing a small, agile, entire product lifecycle team is not the same as managing a pool of resources that pop from project to project and are either (a) not involved in the operations portion at all, or (b) not involved in the development portion at all.

    For a great set of perspectives on this topic, I’ll recommend our partner The DevOps Institute. It has an eBook and a certification course (DevOps Leader) on this topic.

    Decentralization, Yet Increased Oversight

    This is often a confusing pair of messages we send when talking about what DevOps culture change does. It really is not that complex—pundits just assume everyone already knows, and, honestly, those knee-deep in DevOps do know.

    Decentralization, as taught in the DevOps Leader course mentioned above, is about driving as much decision-making as possible down to the team. When teams are built around a product or group of products, then those with the most pertinent information about what is best for the product quite often can be made within the team, speeding decision-making and implementation.

    Increased oversight is an acknowledgement of two things. First, there is more information available in an agile environment, and that information is available more frequently. Standup meetings offer some, while milestones offer other data. Second, tools are starting to allow rollup of information in a uniform fashion for CIOs, CTOs and business leaders to look at. This means they can quickly see the status of projects they have a vested interest in and provide feedback into the process. To go from, “Oh, this roadmap item is going to take a lot more work than we thought,” to, “Great, we have a plan, let’s keep moving,” is shorter when there is more information available to the decision-makers on both the business side and the IT side.

    There is no doubt plenty I have missed, but these seem to be the core things that those of us discussing this topic a lot assume others know, and that those just looking into DevOps really don’t. Hopefully it will help someone push through the clutter and come to a decision on DevOps in general, or culture changes in particular.

    — Don Macvittie

  • Bridging the Gap Between ITSM and Software Engineering

    Bridging the Gap Between ITSM and Software Engineering

    Considering the individual roles of IT service management (ITSM) and software engineers, it seems obvious they should work closely together. ITSM tracks internal and external customer issues and engineering fixes code-related issues (such as defects) that IT cannot fix on its own.

    However, more often than not, coordination between these two departments is poor, which—critically—undermines customer response times and damages application satisfaction. It’s important to remember that the quality of customer response isn’t just about speed, it’s about giving customers insight into the state of the issue.

    The disconnect between ITSM and engineers, often caused by individual priorities and semantic differences, makes this real-time insight difficult. Both teams have individual and shared concerns, and separating these while simultaneously improving collaboration is a big challenge.

    Addressing this relationship is an important step in optimizing ITSM and DevOps integrations, alongside focusing on IT help desk enhancement requests to product management, and tracking code from build to release and back.

    The Flow of Information on Things that Matter

    Most of the tickets generated by the IT help desk can be handled internally with no help from engineering, but it’s the tickets that do need help which require consideration. For these issues, there needs to be an open flow of information on the things that matter between these two teams.

    IT help desk must give engineering enough information to understand the defect and its impact on the customer. Meanwhile, engineering needs to be able to give the help desk a sense of when to expect the fix, when the fix is done and be able to request more information when required.

    Information that should be shared from the help desk to engineering includes the following:

    • Severity – Engineering needs a sense of the importance of the defect. If everything comes in as “High Priority,” nothing is high priority. The help desk must understand that engineering already has its own internally generated set of defects, as well as defects found by QA and other sources. For these customer defects to be prioritized and fixed in a timely manner, engineering needs to know how impactful they are to the customer.
    • Description – This is perhaps the most important piece of information the help desk can pass along. The more contextual information that can be shared, the better. It’s immensely important to provide engineering with the necessary steps to reproduce the specific defect, which version of your tool the customer is using, the general environment, etc. Sometimes this is best in structured fields, while other times it’s important to simply write out everything.
    • Screenshots and other visual information – Along with the written description of the problem, engineering often requires logs and/or screenshots. As the saying goes, “A picture is worth a thousand words.”

    Now that engineering has the vital information it needs to fix the defect, it has a responsibility to provide useful information back to the help desk:

    • Planned release – This should not be a firm commitment, but rather an estimate to give the help desk general timing. While the actual date of the fix may vary, it’s still useful to be able to tell a customer,”This is coming soon,” rather than, “We realize this is a problem and it’s on our backlog to fix.”
    • Engineering status – While this is a single defect to your customer and to them only has one status, there are really two statuses your organization will care about:
      • Status of the ticket in your ITSM tool
      • Status of the defect in your defect tracking/agile planning tool

    It’s very important that the ITSM tool contains both statuses to provide more information and context to the help desk. Imagine the benefit of knowing that the defect is “In Triage,” “In Progress,” or “In Verification” and being able to provide that information to a customer.

    • Actual release/released – As opposed to the planned release information, this lets the help desk know that the customer’s issue has been resolved. Imagine running a report from your ITSM tool indicating the defects fixed in your most recent release. Your IT help desk can proactively reach out to customers to let them know to upgrade, enabling you to offer more proactive customer communications.

    Finally, and perhaps most important, you allow your teams to talk about the “same thing” even when it exists in different tools and they speak a different language. There are four core ways to do this: 

    • Cross-tool tracking – Each artifact in each system should have the ID (and ideally URL) of its twin artifact in the other system. If a help desk representative needs to talk to an engineer about a defect, the rep needs to let engineering know which defect it is in the engineering tool, not just in the ITSM tool.
    • Routing – IT help desks often support multiple products, each of which have multiple components that may belong to a different engineering team. The help desk needs some indication which component and/or team should work on the defect. This information will help the IT help desk know which team to reach out to for help.
    • Filtering – Not every ticket in the ITSM tool needs engineering help (that’s a good thing). However, there should be some indication on the IT ticket if it has been sent to engineering. You do not want to send the same defect to engineering twice (confusing) or to assume it’s been sent when it hasn’t (poor time to resolution or issue overlooked).
    • Communication – IT and engineering need a shared way to talk about a specific defect that they both care about. The closer this communication can be to the native commenting that already occurs, the better. Ideally this is not via email as that communication vehicle does not stay attached to the artifacts in question, meaning information can be hard to find or get lost.

    The Benefits

    Customers will love it – Improved communication means happier customers. Customers can plan their upgrades with more certainty, and their trust grows since your organization is able to deliver on its promises. No longer will they feel like their issues are being thrown into a black hole.

    Better engineering focus – Engineering gets pulled in a variety of directions, contending with feature work as well as internally generated defects. The more information it has, the easier it is to prioritize and deliver more value to customer. Without the ability to share the severity of a defect, you risk two undesirable outcomes:

    • The defect is fixed instead of more important work, which hurts all your other customers.
    • Other, less-important work is prioritized, which can threaten your relationship with this customer.

    Better trust across your organization – Open communication fosters trust and understanding. Providing insight into prioritization and status let’s your help desk feel part of the development process. No longer will staff feel like their requests are being ignored with no idea when they will be fixed. Enhanced cross-team communication also helps engineering to avoid feeling like work is simply being thrown over the fence. Obtaining more context around a defect is invaluable.

    Next Steps for Total DevOps Integration

    To fully integrate your ITSM and engineering teams, there are still (at least) two other processes to implement:

    • A method for the IT help desk to provide enhancement requests to your product team: These enhancement requests are similar, but distinctly different from the defects described above. Consequently, they need to be prioritized and triaged by a different team.
    • The other process to implement is the traceability from task to code to build and back again. To properly inform customers that their problem is fixed in this version of your product, it’s important to correlate features, stories and bug fixes with the actual version of your product that includes them for the first time.

    Bridging the gap between ITSM and engineering teams brings your company closer to customers. While making your organization work as a unified whole is an incredibly complex problem, addressing this relatively small, but vital, piece of the puzzle helps you on your journey to integrating your whole software value stream. This change of mindset, combined with connecting all teams, tools, disciplines and processes in an enterprise’s software value stream, optimizes collaboration, productivity, efficiency and most importantly, value delivered to the customer.

    About the Author / Trevor Bruner, Product Manager, Tasktop

    Trevor Bruner is Product Manager at Tasktop Technologies. His background includes experience in financial services, oil and gas and as a Navy submarine officer. Connect with him on LinkedIn and Twitter.

     

  • 5 Team Skills That Make DevOps a Success

    5 Team Skills That Make DevOps a Success

    When starting their DevOps journey, your team will discover it needs to develop some new skills. Most likely the team is good at typing code and solving issues, but what about the soft skills?

    Many teams have to learn how to deal with issues themselves—as self-supporting teams, there is no longer a manager who will help them out and tell them what to do.

    During the Phoenix Project DevOps business simulation, the majority of teams discover collaboration and communication are skills they lack. I am often surprised how few people can really facilitate standups, retrospectives, Andon-sessions and other communication methods.

    Here are the five team skills that participants recognize as core skills they learn (or could learn) during the simulation.

    The Standup

    The standup is a very powerful way to share knowledge about certain issues. The team will stand together for a short time and discuss an issue that blocks the flow, needs clarification or needs to be high priority. So, who should initiate this standup and who should lead it? I’ve noticed a lot of participants find it very difficult to manage this standup initally, but after a few times the team discovers the key elements of a successful standup:

    • Chose a facilitator. Someone who is leading this session. It doesn’t matter who (it doesn’t have to be a manager).
    • Share the focus: What are we going to talk about?
    • Keep it short (time is ticking).
    • Make sure we all understand the outcome.
    • The importance of listening and engagement.

    Facilitating a Retrospective Session

    DevOps is also about continuous learning and experimenting. One of the important steps in this process is retrospective. This activity explores the past round of work and reviews what went OK and what needs to be improved. Again, during the simulations I discovered that not many participants know how to execute this activity. After being shown the right example, the team often can perform this activity themselves. This is what teams learned during the simulation:

    • Someone from the team must facilitate this process.
    • Make sure the improvement is supported and understood by the whole team.
    • Test the improvement before to applying it.
    • Record the discoveries—this becomes part of the visual management system and part of the team backlog of improvement needs.
    • This team skill is one of the skills that more than one team member should be able to execute.

    Managing the KanBan

    During a project, teams sometimes will have standup moments to discuss the work visualized on their KanBan. Work will move from backlog to doing and done, and new priorities will change the order of work. During the simulation participants will take the lead in this process, but some don’t find this easy. After the sessions they discover:

    • Use standups to discuss the changes on the KanBan, make sure the team is fully involved when moving notes around.
    • Challenge participants to share their thoughts. Saying “yes” doesn’t always mean “yes.”
    • Errors are made, but that doesn’t mean somebody has failed and should be punished. Keep the session safe and open.
    • The KanBan is a form of visual management system (VMS). The VMS is not the goal—it is an instrument and must help the team to visualize flow, limit work in progress, drive productivity through an awareness of what people are working on and continuously improve the process.
    • Make sure at the end of the session, all participants know what’s agreed.

    Managing an ‘Andon’ Session

    ‘Andon’ is a very powerful instrument to explore a situation that stopped the flow. As soon as the flow stops, someone “pulls the rope” and the team “swarms around” to investigate the error and try to continue the flow as quickly as possible. This session should be led by a team member; it doesn’t matter who. During this session, the team discovers the following learning:

    • Make sure the session is short and focused on fixing this blockage and restarting the flow.
    • Make sure we are not blaming each other; it should be about exploring what stopped the flow, fixing it and agreeing how to prevent it from happening again.
    • Make sure the whole teams swarms around and participates.
    • Create a safe environment.

    Collaboration

    Doing the work is not always easy. Sometimes we don’t know what to do. Sometimes we need help, and sometimes we are not happy with the actions of a team member. This is what collaboration is all about.

    One of the first aspects of collaboration is helping each other. But, this is not always effective. Sometimes it’s even disruptive or we just take some work from somebody else if we think he is too busy. Here’s what participants learned about collaboration during the simulation:

    • We have to avoid “compensational behavior.” This is about taking other people’s work with the intention to help the other. Sometimes this person doesn’t know you took the work and he or she does it again, creating unnecessary double work.
    • Collaboration is about shared goals and shared processes. We should all know what we are doing and how.
    • It’s also about clear roles and responsibilities. If you know what your colleague is doing, you know what you have to do. And the other way around.
    • You must have an open team culture in which it is also safe to say you don’t know and to ask for help.
    • Collaboration is fun, and it gives energy if we as a team achieves something.

    Conclusion

    I have visited many global DevOps conferences in the previous years and have listened to numerous speakers declaring, “It’s all about people.” And they were right. Unfortunately, the audience often did not get many useful answers.

    A high-performing collaborative team needs team players who know how to deal with the collaboration and communication issues themselves without needing management intervention.

    Teams will have to go through the stages made famous by Bruce Wayne Tuckman (Forming, Storming, Norming, Performing and Adjourning) to become an effective, collaborative team.

    Continuous learning is a key success factor and a critical competency for any DevOps team. Why not start this learning journey in a safe and challenging environment?

    A simulation such as the Phoenix Project is a very powerful instrument to teach teams how to collaborate and become high-performing. The environment is safe and feels like the real work environment. Participating in this simulation with an actual team allows you to capture and agree on actions to takeaway. Outcomes can easily be transferred to day-to-day work.

    I wish you a lot of soft skills.

    About the Author / Jan Schilt

    Jan Schilt is owner of GamingWorks. His background is Human Resource Development (MSc). Within GamingWorks he is responsible for Business Simulation design, Facilitation and Train the Trainer. He is also an expert in developing learning activities related to organizational change. He builds all the simulations and has delivered more than 300 workshops worldwide.