devopsy.kinsta.cloud

Tag: collaboration

  • Fiberplane Adds Wasm Plug-in Framework for DevOps Notebook

    Fiberplane Adds Wasm Plug-in Framework for DevOps Notebook

    Fiberplane today announced it is extending the reach of a real-time collaboration notebook designed for DevOps teams by making available tools for building plug-ins based on the WebAssembly (Wasm) framework.

    Micha Hernandez van Leuffen, Fiberplane CEO, said these plug-ins, dubbed providers, will make it much simpler for anyone to connect the Fiberplane notebook to other DevOps tools and platforms.

    The Fiberplane notebook uses the same operational transformation algorithm used in Google Docs to enable teams to easily collaborate around a document or spreadsheet. The core platform itself is built in Rust and WebAssembly. That approach enables a DevOps team to, for example, write and run PromQL queries and display Prometheus charts alongside other data presented via an integrated graph. Wasm makes it possible to run those providers both in the browser and on a backend platform.

    Fiberplane also announced it is open sourcing its Provider Development Kit (PDK), written in Rust, to enable organizations or third-party developers to create additional plug-ins. A Fiberplane Daemon then executes the plug-ins. The overall goal is to provide an open format based on Wasm for consuming DevOps data, noted Hernandez van Leuffen.

    The full open source Fiberplane WebAssembly-based Plugin System includes a Fp-bindgen to provide the bindings generator for building plug-ins, the Provider Development Kit (PDK), a toolchain for building plug-ins, a set of pre-configured plug-ins for Prometheus, ElasticSearch, Sentry, Grafana Loki, Cloudwatch and a generic HTTP provider, the Fiberplane command line interface and the Fiberplane Daemon.

    Fiberplane is essentially taking the concept of notebooks used for collaboration by data science teams and applying it to DevOps workflows. The goal is to improve DevOps teams’ productivity by reducing the amount of time it takes to sort through multiple types and classes of DevOps data to resolve an issue.

    As IT environments become more distributed in the age of the cloud and microservices, troubleshooting issues now invariably spans the responsibilities of multiple members of an IT team. Fiberplane, in effect, makes it possible to spin up a virtual war room that enables the members of an IT organization to collaborate until the issue of the moment is resolved.

    The speed at which any IT issue is resolved has become a crucial metric. Given the complexity of IT environments, it’s inevitable that incidents will arise. Ideally, IT teams would discover those issues before they disrupt the business. However, in reality, the metrics organizations use to evaluate the effectiveness of a DevOps team are often how quickly IT issues are resolved once they are discovered. The longer it takes for a distributed DevOps team to marshal its resources, the more likely it becomes that team will be perceived as being inefficient—regardless of what level of application availability is actually achieved.

    Most DevOps teams have, of course, implemented a wide range of incident management best practices that create a level of muscle memory for responding to a wide range of issues. The trouble is there will always be unforeseen issues that arise. DevOps teams, as a result, need to find ways to quickly focus on an unpredictable issue that they didn’t anticipate.

  • Software Quality is the Heartbeat of the Best Organizations

    Software Quality is the Heartbeat of the Best Organizations

    JPMorgan recently announced it was hiring 2,000 engineers, despite the gloom in global economic markets. Is this not an odd risk for an organization to take, given the demand for (and cost of) software developers today? What’s happened?
    JPMorgan’s hiring drive is no mystery. Virtually every company in the world is leveraging software, with many transforming themselves into software organizations to drive new efficiencies, widen profit margins and create new markets. Software has been disruptive, so much so that the current era has been dubbed the “third industrial revolution.” Consumers are benefiting from switching providers at the click of a few buttons and most consume services through software. Bad software experiences today mean rapid customer churn and competitive disadvantage.

    Quality Should be the Heartbeat of any Organization

    In spite of quality’s importance, testing is still perceived as a secondary discipline and a check-the-box exercise. This reflects practices developed for assembly lines during the original industrial revolution. A product gets assembled and testers verify its quality as it leaves the production line. Testing’s goal in this context was to identify problems before they reach end-users. This same approach has been applied widely to software development and is still used by “waterfall” organizations.

    Yet, software development has been revolutionized by new methodologies and practices. Software today is constructed at incredible speed. Notice I’m using the word “constructed” and not “built”—the best developers leverage libraries or APIs to assemble software using existing components. They then add a few pieces of custom business logic to define the intellectual property of an application. Many organizations don’t even code software, instead customizing off-the-shelf software with vast configurations to modify functionality.

    The assembly-line approach to software development is no longer appropriate. When testing is left late, defects are found before a release or even in production. Release cycles are longer and products poorer quality. Yet, many organizations still stick religiously to this approach, with testing teams operating in distinct silos.

    The Role of the Tester is Evolving

    The best organizations in the world are changing how software is built. Testing is no longer a check-the-box exercise at the end of the assembly line. It is transforming into a discipline that revolves around evangelizing and driving quality throughout an organization.

    Quality should be baked in as early as possible, touching every artifact produced. Ideally, this should occur from the start, as a requirement is formulated, all the way through to the software being shipped. The idea of siloed teams working on different pieces is outdated. For quality to thrive, teams must collaborate.

    Modeling offers one approach to driving quality and collaboration throughout an organization. Its journey starts with a requirement. These are typically formulated by business analysts or product owners. Having been a product owner, I found that this usually involves lots of scribbles on paper before communicating to stakeholders on a whiteboard. The preliminary requirement then gets reviewed and refined.

    At some point, the requirement will be converted into walls of text in a project management tool. Modeling intervenes at this stage, adding visualizations that make requirements more consumable, less ambiguous and easier to understand.

    The word “modeling” may seem a scary concept, but it need be no more than a flowchart that encapsulates a requirement. The benefit of modeling is not only that it provides a digital collaboration asset; models can also generate coverage-focused tests before a line of code is written. Modeling creates requirements that are quality-driven and quality-driving.

    The Journey of Quality-Driven Requirements

    • Models Provide Data Upfront

    Developers today require rich data to develop, while testing is only as good as the available test data. Yet, many organizations still feed slices of production data into developers and test cases.
    This approach is problematic for several reasons. First, it often risks legislative non-compliance. Second, production data features large volumes of low-variant data. Data may not then be available when developing unusual-but-important scenarios. Imagine an overdrawn account with several beneficiaries: What should happen when a transfer is attempted?

    Modeling defines data explicitly in requirements. It allows engineers to understand a requirement explicitly, including the relevant data. From the modeled definitions, correct data can then be masked and subset, or generated synthetically. Data can further be delivered on-demand and at scale using database virtualization.

    • Models Provide Understanding

    Once the requirement and necessary data are available, code can be developed. Using text-based requirements, misinterpretations often lead to incorrect functionality. Visual models instead align closely with business logic, and we often see developers enriching models with additional context so that models align with the actual software implementation.

    • Models Generate In-Sprint Tests

    Once the code is developed, the same tests which were created earlier from the requirements can be executed against new functionality. This facilitates reuse and means the test cases are ready to be executed immediately.

    Some tests might further be selected for automation. In this instance, automation can be overlaid onto the requirements model, reusing code to generate scripts. These scripts then become part of the standard regression pack as new features are added to the product.

    A Change Request Comes In

    With iterative development, change requests are common. This typically creates havoc for quality, since it is difficult to understand the impact of a change, and time-consuming to update artifacts like tests and data.

    Traceability is key to overcoming this challenge. Models can connect to external DevOps tools to provide end-to-end traceability, from a requirement, all the way to code and tests. The impact of a change can then be identified directly. Models can be updated, automatically synchronizing test data, test cases, and automation to bring everything up to date.

    Testing for the Fourth Industrial Revolution

    Software is playing a vital role in virtually every organization, as already recognized by organizations thriving today. Baking quality in early is the only way to ensure quality software. The role of testing must change on a large scale. Models offer a way to achieve a “shift left” and collaborative approach to quality while testing earlier and more rigorously by automating and optimizing test and data creation.

  • Atlassian Aims to Improve Collaboration With DevOps Teams

    Atlassian Aims to Improve Collaboration With DevOps Teams

    At an Atlassian Presents: WorkLife event today, Atlassian furthered its efforts to integrate the tools technology and business professionals use to manage processes.

    Erika Trautman, general manager and vice president of product for Work Management for All at Atlassian, said that as organizations increasingly rely on digital processes to engage customers, partners and employees, the need to facilitate collaboration across a diverse set of knowledge workers is becoming more pressing.

    As part of that effort, Atlassian is now making generally available a Smart Links capability within the Atlassian platform. Smart Links can be used to integrate both Atlassian applications such as Trello and Jira as well as third-party applications. That capability is now critical because there has been a Cambrian explosion of adoption of software-as-a-service (SaaS) applications that all need to be integrated into a common set of workflows, noted Trautman. Otherwise, each SaaS application environment becomes yet another walled garden that prevents any meaningful collaboration, she added.

    In addition, the company announced that Atlas, a directory that tracks projects and simplifies communications across teams using disparate applications, will become generally available next month. DevOps teams, for example, will be able to synchronize Jira events with projects being tracked via the Atlas platform.

    Atlassian has also streamlined the tools it provides to reduce the number of steps required to administer its applications and onboard new users.

    Finally, the company also has launched Atlassian Together, a single subscription offering through which organizations can license its Trello, Confluence, Atlas and Jira Work Management applications delivered via the cloud. An enterprise organization with more than 5,000 users can now, for example, license those applications for $11 per user.

    Atlassian is making a concerted effort to enable organizations to more easily collaborate at a time when they have become more dependent on software than ever, noted Trautman. In many cases, businesses are now trying to adjust to the rapid rate at which software is being delivered thanks to the adoption of DevOps best practices, she noted.

    As such, there is a greater need for integration between tools such as Jira that development teams use to manage projects and a wide range of tools used by knowledge workers residing in various departments, said Trautman. In effect, Atlassian is trying to enable organizations to reduce the “collaboration tax” they incur as workflows span multiple silos, she added.

    In fact, in many cases, organizations are struggling to keep pace with how agile software development teams have become. The irony is that not too long ago business executives routinely complained about how long it took IT organizations to adjust as business conditions changed. Now, many businesses are rolling out additional digital capabilities via software updates that can be made multiple times a month.

    The rate at which organizations will collaborate across departments will naturally vary, but the days when each department was a fiefdom unto itself are coming to an end. The challenge and opportunity may now be determining how modern organizations should be structured once it becomes easier to collaborate.

  • 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.

  • Boing

    Boing

  • How to Avoid Crappy Culture and Keep Engineers Happy

    How to Avoid Crappy Culture and Keep Engineers Happy

    Software engineers know how much they are worth—everyone wants them and there aren’t enough of them to fill that demand. While the need for tech talent is greater than ever, the pandemic has shifted priorities for many engineers. And they’re not alone. It’s a reality shared with millions of others in a variety of fields around the world.

    If the so-called Great Resignation has taught us anything, it’s that everyone is tired of crappy workplace culture. People are beginning to question why they’d stick around at a place where they don’t feel valued and supported. And for those companies not investing time and energy into their culture, good luck holding on to software engineers. They know their value!

    In this uber-competitive environment, the best way to keep software engineers happy and make the company a desirable place to join may seem counterintuitive, but hear me out: Just back off. Trust engineers to do their jobs well.

    Put in place the building blocks for a supportive environment where people feel comfortable taking risks and voicing their ideas—even contradictory ones—in positive ways. Then, get out of the way. Leaders have a responsibility to make these values stick and to hire people who fit them, even if that means not always picking the most qualified person available.

    Don’t Be Afraid of “Dumb Ideas”

    I’ll be the first to say it—I have a lot of dumb ideas. I’m thankful to have worked in places that encouraged me to share those ideas. It taught me to focus on building a company culture that values openness to new thought processes. Because you never know when something that might seem like a dumb idea could actually become the next big thing. 

    No one wants to feel shamed for speaking their mind. Encouraging people to share their ideas, even those that aren’t fully developed, fosters a sense of trust in the team and can lead to greater creativity and innovation. It also makes the company stronger by reducing stress on employees and avoiding negative outcomes like burnout and other health concerns that may ultimately lead to turnover.

    Getting to this point of psychological safety in the workplace is not an easy process. It has to be highly intentional given the standards that are often at play in the professional world. For too long, people have been thought of as replaceable cogs in an organizational structure, not as humans with unique and valuable skills, talent and shortcomings.

    It’s about recognizing that people are human and often want to feel authentic in how they work. That’s why it’s valuable to talk about new ideas to improve the company and its products, as well as talking about how you talk; set a defined standard for how important topics are discussed as a team. 

    Fostering a supportive culture doesn’t mean there aren’t disagreements. But there are ways to offer contrary opinions without being a jerk about it. This mutual respect between engineers allows people to look at things with a critical eye without hurting anyone’s feelings.

    At CodeSee, we do a weekly product review. And this often leads to statements like “the product does this, but I wish it did this.” This isn’t a criticism of anyone, and everyone knows that. It’s everyone helping each other in the pursuit of making things better.

    Don’t Hire Assholes

    Instilling these values in a company is a rewarding experience that allows engineers to flourish. But none of that matters if they don’t also show up in the hiring process. The same things we place importance on in our day-to-day operations are top priorities in hiring: Humility, trust and self-reflection.

    We’d rather have a decent engineer that fits our culture and embodies these values than a great engineer that isn’t supportive of others. We don’t subscribe to the idea that it’s OK to treat people like dirt just because you’re a genius.

    These ethos show up in the questions asked to prospective employees. Two of our go-tos are fairly simple. We often ask interviewees to define three strengths and weaknesses. It’s a number that requires some real introspection and helps us see if a person knows where they could stand to improve and have identified personal growth strategies. We’ll also ask, “When we call previous managers, what will they have to say about you?”

    These questions are meant to tease out some self-reflection, naturally. If they can put themselves in the shoes of their past managers, that shows a high level of self-awareness and empathy.

    Surprisingly, these questions have gotten under the skin of more than a few applicants. I’ve actually had people yell at me, the person doing the interview, because they’ve been made to feel uncomfortable. Obviously, that kind of response told us everything we need to know.

    Tools for Success

    Institutional knowledge is an asset to any team. However, it puts additional strain on senior engineers, who are already stretched thin, to hold that information in their head and teach/explain it to less-experienced colleagues. 

    This is something that needs to change to free up senior engineers to focus more on the big picture. We can solve that with tools to visualize code and by investing in models that provide these models to engineers to improve training. 

    Today, many engineers spend 60% of their time reading code. What if we could reduce that to 40%? Or 20% or even 10%?  If all our engineering talent spent 40% of their time doing other stuff, think about where we could be?

    However, productivity tools can be a double-edged sword. Instead of giving more freedom and trust to software engineers, some companies are using technology to wring every last ounce of productivity out of the workforce, efforts that are surely doomed to fail by encouraging talented engineers to start planning their exit.

    The bottom line is that everyone needs engineers. Losing at least some is inevitable. But if you are thoughtful about creating a supportive, innovative culture—and maintaining it—then it’s a lot easier to compete.  

    But it’s no simple task. Every decision you make—from who you hire to the products you build to the way you talk to each other in meetings—plays a role in shaping culture. Engineers will be compensated everywhere they go, so the best chance to get ahead is to build the best, least-crappy culture possible. 

  • Atlassian Expands DevOps Tools Portfolio to Improve Collaboration

    Atlassian Expands DevOps Tools Portfolio to Improve Collaboration

    Atlassian has added an extensible catalog for tracking software components, dubbed Compass, to its portfolio of DevOps tools along with an Atlassian Data Lake and Atlassian Analytics cloud service that makes it simpler to aggregate and query data collected from the company’s portfolio of tools.

    In addition, Atlassian is making its Atlas collaboration framework—formerly known as Team Central—formally available in beta. That framework, in effect, provides an overlay through which different collaboration tools adopted by various DevOps teams can be more easily integrated.

    Compass provides DevOps teams with the ability to map all the components they use to assemble their software as well as the teams that own them. DevOps teams can access shared components and documentation along with scorecards to allow them to measure and evaluate their architecture based on the baselines, security or compliance requirements they might be required to meet. It can be extended to other applications via an integrated Apps engine using Forge, the existing Atlassian cloud development environment.

    Tiffany To, head of product for Agile and DevOps at Atlassian, said Compass is designed for DevOps teams that are typically trying to manage 50 or more microservices. It is designed to be deployed alongside the Jira project management software that is widely used by software development teams to manage multiple projects.

    Atlassian Analytics, meanwhile, is based on a visualization and analytics platform the company gained last year with the acquisition of Chartio. Initially, the Atlassian Data Lake will include data from Jira Software and Jira Service Management tools with support for additional Atlassian platforms planned.

    Collectively, these tools are part of an ongoing Atlassian effort to make it simpler to integrate multiple DevOps teams, said To. Many of those teams prefer to maintain autonomy over the tools they select. The challenge that creates is organizations need some type of overlay through which they can collaborate and share best practices, she said.

    A survey of 2,000 developers conducted by Atlassian found half of the respondents exercise strong autonomy over the tools they use, with more control over tool selection gained as developers become more experienced. The same survey also found that 65% of developers felt they should be responsible for more of the software product life cycle than they currently are.

    It’s apparent that most organizations building software are trying to strike a balance between developer autonomy and centralized control. Developers are expensive to hire and retain, so there is a natural tendency to make available the tools they prefer. That, however, can lead to a level of tool sprawl that makes it difficult to determine the overall state of application development and deployment within an organization.

    Regardless of the approach, the need to remove as much friction as possible from DevOps workflows is clear, especially as the number of simultaneous application development projects continues to multiply. The challenge and the opportunity, of course, is achieving that goal while keeping developers happy.

  • Essential Ingredients For a Remote DevOps Team

    Essential Ingredients For a Remote DevOps Team

    Enterprise business processes are run on evolving applications, and the DevOps team needs to be as efficient as the applications they create. Unfortunately, the COVID-19 pandemic has had a profound impact on DevOps productivity—and that impact hasn’t always been positive.

    Tracking the performance of the DevOps team has become more challenging in a remote and hybrid world. Like everyone else, developers have become remote workers throughout the pandemic which means adapting to a new way of working. There has been a lot of research done on the impact of work-from-home on productivity. Of course, measuring any developer’s productivity was already a complex task. It’s not as though you can use a simple metric like the number of lines of code produced per day; it’s a lot more complicated than that.

    Working from home has made it even more challenging for developers to stay productive. There are dozens of distractions when you work from home, and research shows that it can take even the most skilled developer 15 to 20 minutes to resume work once they have been interrupted. There’s also more stress associated with balancing work and home life when working remotely. According to Catalyst, 92% of workers say they are feeling burnout from the stress of remote work.

    Software Development Thrives on Remote Work

    In many ways, the trend toward remote work has been a windfall for developers. The nature of coding has always lent itself to a hybrid or remote work environment, but unfounded concerns about securing intellectual property have always been an impediment.

    A recent Gartner survey revealed that employees are three times more likely to become high performers when given flexibility as to where, how, and when they work. Remote work also enhances flexibility and eliminates wasted time commuting. And work-from-home reduces childcare responsibilities. Catalyst found that 32% of women with child-care concerns are less likely to leave their jobs if they have work-from-home as an option.

    Remote work also eliminates geographic barriers, which is a well-understood benefit in the software industry. Being able to hire programmers working from home anywhere in the world increases the size of the talent pool and makes it easier to find developers with the right skillset.

    Of course, there are challenges for DevOps teams that embrace a remote work model. Communication is probably the biggest challenge. Zoom meetings may not be as effective as in-person meetings since it’s harder to read facial expressions and pick up non-verbal cues. It’s up to the team leader or senior manager to promote effective communications. It’s also important to have the right tools, have the right communications channels and maintain respectful interactions. Even with a remote work environment, the team dynamic can be adversely affected by the misuse of responsibility, behavioral issues and disrespectful behavior.

    Building a Remote DevOps Team

    Supporting collaboration in a hybrid work environment requires new processes, new guidelines and new tools. The best place to start is by choosing the right collaboration platforms and procedures. For example, email is a poor channel for immediate requests, but you don’t want to be answering continuous phone calls. Establish protocols for using email, chat, teleconferences and meetings. Adopting cloud communications tools also gives you more agility and scalability. 

    When choosing the right collaboration tools consider security. Working off-site gives you less control over enterprise access. Remote workers access enterprise systems using different devices and public and private networks. To reduce vulnerability to cyberattacks provide safe and secure network access with multiple security layers. Adopt virtual private networking (VPNs), remote desktop protocol (RDP) clients, and malware protection. Workers tend to be less security conscious when working remotely so take what steps you can to reduce risk.

    In addition to having the right tools, you must have the right approach. To continuously improve efficiency you need transparency, inspection and adaptation, just as you do with DevOps. Start by establishing and documenting a clear set of expectations for the remote team. Also, create a leadership hierarchy. Even though they are working from home, everyone needs a work structure. It’s up to the team leaders to create a stable work environment. Lack of clarity removes that sense of structure and safety and can undermine the team.

    Maintaining transparency is the best approach for any remote work culture. Establishing a workplace fueled by honesty and openness and where every voice is heard ensures everyone is working to achieve a common goal and keeps morale high.

    Maintaining a successful remote work environment depends on respecting the four Cs: Communication, collaboration, connectivity and culture. The four Cs are interdependent and work together to create an effective digital work environment, providing an employee experience across locations, devices, channels and situations.

    Creating a Productive Environment

    Once you have laid the foundation for remote collaboration, the next step is to monitor productivity. There are a few ways to look at DevOps team productivity. You can look at the final output of the overall effort, assessing the application that is the end product. You also can measure overall team productivity. 

    To monitor key metrics to assess team productivity, project managers must be prepared to drill down to evaluate hot spots:

    • Measure output for specific developers and see how it stacks up against the productivity of other team members. 
    • Maintain leaderboards highlighting top contributors. Using gamification creates healthy competition and can inspire greater productivity when top performance is recognized.
    • Create a conducive environment by providing the right set of tools and motivating engineers to be at their best.
    • Monitor distractions. Coding is an intensive activity and disruptions harm productivity.

    Don’t measure productivity based on coding. Developer contributions also include designing new features, functional discussions, code review, documentation, testing and bug fixes, meeting with customers and other tasks.

    Improving DevOps productivity is also a product of automation. In addition to streamlining real-time collaboration with tools such as instant messaging and Microsoft Teams, shortening development time with automated testing tools and AI-powered test frameworks eliminates manual processes and frees time for more productive tasks.

    If you are looking for a silver lining from the pandemic, consider the evolution of the remote work environment. Supporting remote DevOps developers is nothing new, but forcing employees to work from home has made the hybrid work environment more efficient. DevOps teams continue to invent better ways of working that promote flexible work hours, higher productivity and a better work-life balance.

  • Shifting Engineering Priorities for 2022

    Shifting Engineering Priorities for 2022

    Nearly every aspect of the software development process is accelerating, from the increasing speed of programming languages to the expectation of faster delivery. This has resulted in the misconception that speed and efficiency should be a DevOps team’s or engineer’s top priority. Though agile transformations have been a central strategy for most organizations in recent years, investing in team culture while undergoing an agile overhaul is paramount to overall success.

    For many workers, the pandemic caused a shift in priorities, so much so that as we begin to emerge from the events of the last two years, almost a quarter of UK workers are planning job changes and businesses are tackling the so-called Great Resignation. A desire to improve work-life balance and enjoy better benefits like flexible working has made employees more likely to leave a job. As such, maintaining employee satisfaction and protecting team mental health should be a top priority for companies wanting to keep retention rates high.

    This starts with leadership, and engineering and DevOps leaders must have full transparency into their teams, with an understanding of exactly what motivates them. With this in mind, here are three top priorities for engineering and DevOps leaders in 2022.

    1. Prioritize Team Culture

    The tech sector is notorious for a high employee turnover rate, with a LinkedIn report putting it at 13.2%, far above other industries. For engineers especially, the increased pressure to deliver at lightning speed has created an unsustainable “churn and burn” culture.

    Simultaneously, engineers have no shortage of options when it comes to job prospects as demand is booming. In fact, this particular sector in England and Wales advertised more job vacancies in 2021 than all British businesses across 2020.

    To avoid any leavers, it’s important for engineering leaders to establish a unique and engaging culture within their teams, and actively and continuously examine it to ensure that engineers feel supported and valued.

    However, there are a few key principles shared across world-class engineering teams. Allowing engineers to work on projects that excite them and allow them to explore their creativity is crucial. This may involve giving them dedicated time to work on developing their skills and pursuing innovative projects. In addition, leaders should cultivate a culture for their engineering teams that is built around appreciation, collaboration and psychological safety. Weaving open and honest career discussion and satisfaction check-ins into one-on-one meetings will help employees feel listened to and motivated by their personal progression.

    2. Use Data as Your Gut Check

    Ensuring decisions are data-driven is also incredibly important. The best leaders are often those who use concrete evidence to strengthen their teams. Engineering leaders must use data and metrics to gauge the health of their teams in the current jobs landscape.

    Even for engineering leaders, a team’s day-to-day programming can sometimes seem like a black box, so finding clear insights about the development process is imperative. With an engineering metrics solution, it is possible to obtain better visibility into your team’s workflow. This not only helps ensure efficiency and quality, but it can also help to gauge employee success and morale.

    Continuous health monitoring using a robust set of metrics will provide leaders with early identification and help to resolve any friction. A data-driven platform to ensure that individuals’ contributions are ‘seen’ is fundamental. Monitoring a teams’ daily workflow helps to identify standout employees that may otherwise fly under the radar, as well as flagging those who may be struggling. It’s important to pay particular attention to metrics that drive employees toward their professional goals and help to remove bottlenecks across teams.

    Prioritizing constructive feedback and one-on-one conversations with employees is crucial to employee success and retention. The focus must be on frequent check-ins with engineers to ensure that they are thriving personally and professionally.

    3. Focus on People First, Rather Than Performance

    Nothing will ever be as important within a team as the people. Only the engineering and DevOps leaders who prioritize people through a variety of tools and techniques will reap the rewards and stay ahead of the competition.

    Recent research has shown that happy employees are up to 12% more productive.

    An engineering team will deliver their best work when they feel encouraged by leaders, have the space and autonomy to work in a meaningful way and have accomplishments acknowledged and celebrated.

    As leaders, it is critical to remember to check in with team members as people, before checking in with them as workers.

    Engineering leaders will likely be battling for in-demand talent in 2022 and beyond as they continue to contend with the Great Resignation. In the face of this, there is a real opportunity for leaders to distinguish teams through their engineering culture. Whether you are cognizant of it or not, a team has a culture. It’s incumbent upon engineering leaders to make having a people-first culture the top priority in 2022.

  • 5 Tips for a Successful DevOps Implementation

    5 Tips for a Successful DevOps Implementation

    More businesses are turning to DevOps implementations to deliver software and updates with more efficiency. As much as business leaders know DevOps can help them to be faster and more agile, many of them are unsure how to get started. Many businesses even begin implementing DevOps only to run into unforeseen problems that hinder the process. 

    While DevOps can be beneficial, you do not want to make changes lightly. You need to know what you are getting into and prepare for ways the change can impact your company. Having a good team and providing them with the right infrastructure-as-code (IaC) tools will help, but there is so much more you need to consider before starting. 

    Here are five vital tips for successful DevOps implementations.

    Evaluate Your Processes

    You need to start by learning what DevOps is and what it means to your organization. Everyone on the team needs to understand what DevOps can do and the types of problems it can solve for your company. 

    Evaluate your entire development cycle from beginning to end. Look at the different processes that go into development to find different bottlenecks and inefficiencies. By finding the areas where your current processes come up short, you will be able to identify the areas to concentrate on when implementing DevOps.

    Collaboration and Communication

    Collaboration and communication are at the heart of successful DevOps implementation. You can get all of the best DevOps tools available, but if you do not have teams ready to work together and communicate, you will not achieve the full benefits of DevOps implementation.

    If you are going to succeed, you need to instill a strong sense of collaboration and cooperation among teams. Beyond that, you also need to provide your team members with tools that will help them communicate and collaborate. Communications platforms and collaboration software can be just as important as the tools that contribute directly to development.

    Set Goals

    DevOps implementation is not just about getting the right tools and changing processes. You need to assess the operations of your company and set goals for the implementation. If you are just buying new tools without setting a new direction, the implementation will not result in that much change. 

    Another good tip is to start with one smaller, more easily achievable goal and then scale up from there. Changing everything at once might be too much of a disruption. Instead, select a smaller goal and once that is achieved, move on to goals that are larger and more complex.

    Automation

    Automation is a big part of what makes DevOps beneficial to modern businesses. If you are going to achieve the full benefits of the change, you should automate as much as you can. Whether it is scanning code for misconfigurations or automated testing, you can do a lot to make your operations more efficient by using a variety of different automation tools. 

    You may also want to take automation one step at a time. If you try to dive headfirst into automation, it might be a bit too much for your team to keep up with. Instead, take a manual process that has been taking a lot of time and toil from your team and implement an automation tool. Let your team monitor for a few weeks to see how it goes and then take what you learned and apply that feedback to automating more processes.

    Know Your Key Metrics

    Set your key metrics from the very beginning of the implementation process. Without metrics, you won’t be able to keep track of the progress you make. A lack of tracking will also make it difficult to identify issues that might be holding back your progress. 

    Most organizations will need to focus on three points: Lead time, deployment time and mean time-to-recover. Beyond that, try to think about your users when defining key metrics. What do they like? What do they care about? What makes for a more pleasing experience?

    DevOps implementation is not simple. By taking the right steps to prepare, you can avoid the worst problems and put yourself in a position to respond well to the issues that do come up during implementation.