Category: DevOps Culture

  • Using Internal Wikis for Web Development Projects

    Using Internal Wikis for Web Development Projects

    A team-based web development project is always a complex endeavor. It involves different developers with varying levels of experience, different fields of expertise, milestones to accomplish and a timeline to achieve.

    To facilitate the sharing of information, it’s not always enough to use project management tools like Asana or Jira. Sometimes, a wiki may be needed to help distribute knowledge and best practices to everyone working on the project.

    In this guide, we discuss the practicality of using wiki tools for information sharing among web devs.

    What is a Wiki?

    A wiki is a program that enables users to collaborate in the creation and population of the content for a website. The word comes from the “wikiwiki,” which is Hawaiian for “fast.” In other words, a wiki is an app that allows for crowdsourced content to create pages of information.

    In addition to wiki pages, Web 2.0 tools allow users to connect and share information via rich media such as RSS, OpenSocial and OpenID. Another use for wiki tools is to share creative content such as photography and design concepts. A very simple way of sharing web pages on the wiki is to add a share icon at the top of the page. Simply add the share icon to a wiki page.

    The Benefits of Wikis

    Wikis bring a number of benefits to web dev teams, such as:

    Knowledge Sharing

    Since people working on the project have different levels of expertise and experience, the wiki allows subject matter experts to contribute information based on their specialization. This valuable knowledge can be accessed by others who need such information and dispels the formation of “information silos” that usually impede teams working in isolation from each other.

    Searchable

    The information stored in a wiki is categorized and organized in hierarchical and logical structures. It allows users to easily search for information based on topic, field or category, and learn what they need in an instant. This improves productivity and minimizes the need to chase other colleagues down in the search for data.

    Single Source of Truth

    By acting as a central repository of information, all data gets vetted before making it into the wiki. This makes the stored information verified and accurate and the wiki acts as the single source of truth for the whole team.

    Easy Updates

    The wiki allows contributors to update information easily and conveniently. As such, all references are up-to-date–a critical factor for any web dev project.

    Wikis and Web Development

    Wikis have the potential to make it easier to share knowledge with stakeholders as well as spread the expertise of a motivated development team, leading to better management and accountability. 

    Many wikis are publicly funded in different ways. For instance, several open source wikis exist, such as BikiWiki, ObjectiveWiki, GrowWiki and PDFLabs wiki, but we can see a few web-based initiatives in this space as well. These include Virgil Technology wiki and KnowledgeVerify.

    Microsoft’s SharePoint platform is arguably one of the best solutions for online collaboration on web-based projects. Because SharePoint is integrated with almost all major applications (Windows, Word, Excel, PowerPoint, etc.), users can create shared webpages based on SharePoint site templates and share these with their colleagues. While it’s true that SharePoint cannot solve all the problems related to information sharing and preservation, it provides a great starting point for finding common ground on project development.

    The Advantage of Wikis Over Other Collaborative Tools

    While project management tools usually incorporate collaborative functions, they are not as full-featured as a wiki is when it comes to knowledge sharing. The wiki is notable for having the following features that other tools may lack:

    Search functionality: Wikis have full-featured search capabilities to aid in the search for information. No need to drill down tree structures and categorical hierarchies.

    Comments: Adding comments to a page is an efficient and fast way to contribute and help others.

    Content creation: You can write wiki articles using any text editor, or you can write it using the wiki syntax—it largely depends on the platform. The wiki syntax is quite similar to the HTML format. One thing that makes wikis useful is that when you share a wiki page, everyone can see the changes as they are made. So sharing works through a web link instead of having to publish to a file.

    The wiki markup is a sequence of tags that represent the structure of a page. There are two main types of wikitext; the wiki syntax and the HTML syntax. The wiki syntax comes from Wikipedia, which is a popular wiki. Both are immediately available to devs, making content creation and editing easier.

    Access control: Since wikis can change based on edits and the number of links get added to the pages, they use an access control and version management system.

    With its growing array of software options and constant framework decisions, the world of web development always needs quick, organized patches of information. Rapid creation and publishing options mean that, for an almost 20-year-old technology, wikis can still be a valuable tool for web devs today.

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted as part of an effort to better serve our audience.

    Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.

    Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

    The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

    We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

    LinkedIn

    Underdog Fantasy
    Remote
    Senior DevOps Engineer
    $150,000 to $240,000

    SimplyHired

    DISH Wireless
    Littleton. Colorado
    Senior DevOps Engineer
    $106,210 – $143,750

    Monster.com

    UMD Energy Solutions
    Bonita Springs, Florida
    AWS Cloud Engineer
    $100,000 to $120,000

    Indeed.com

    Medispend
    Remote
    DevOps Engineer
    $100,000 to $130,000

    Dice.com

    Venusgeo
    Clinton, New Jersey
    AWS DevOps Lead
    $120,000+

  • What a Dev Wants: Security Training for Today’s Developer Workforce

    What a Dev Wants: Security Training for Today’s Developer Workforce

    It’s no secret that developing a strong security culture is a critical component of the production of secure products, yet organizations often overlook the fact that their security training programs set the foundation on which this culture is built. When it comes to developer training, our goal should be to align the intrinsic motivations of a learner with the company’s strategy and objectives. But if either of these is misaligned, the training program, and ultimately the organization, will suffer because it is either irrelevant or perceived as a compulsory box that needs to be checked.

    Addressing the Interests of Developers Vs. the Organization

    Unfortunately, there is a gap between the buyer persona and the developers themselves, even though developers tend to have a fairly consistent response about the ways they want to be trained. Rather than implement a program that is doomed to be viewed as a time-consuming compliance requisite, organizations should rather ask this simple, yet pertinent question: What do developers really want out of their security training program?

    When it comes to today’s security training programs for developers, there’s often a separation between compliance-based training and developer-centric training; in other words, the interests of the organization don’t always align with the interests of the developers. In most highly regulated organizations, there is a mandated security training curriculum that all employees, including the development teams, are required to go through on a yearly basis. This leads to a drawn-out, painful process that leaves employees clicking through modules as fast as possible. Developers may then need to go back and look up security topics on a regular basis if they are looking to implement them into their code.

    While developers are certainly making an effort to adhere to security requirements, this greatly slows the ability to get the product to market in a secure and efficient way.

    What Training do Developers Really Want?

    Organizations should prioritize programs that will specifically target their development teams by asking what those developers are actually looking for. With so many training programs on the market, it can be difficult for an organization to determine which will resonate the most with their employees, specifically their development teams. The fact of the matter is that, when it comes to security training, the majority of developers want to do as little of it as possible. They are willing to check the boxes for compliance purposes, but they want it to be as seamless as possible. As the complexity of training tactics continues to evolve, an ideal curriculum is simple, like programs that can be embedded in the tools developers use on a daily basis.

    The most effective training programs are engaging and relevant. Managers tend to see better results from training that is hands-on, interactive, engaging and related to developer tasks. Gamification is also a great way to engage developers. For instance, organizations have started livening up their training curriculum with leaderboards. In fact, recent studies have indicated that developers would opt into shared company leaderboards with points for content consumed. Not only are these programs engaging for the developers, but they are also incredibly effective, as they motivate teams to view more content by leveraging individuals’ pure competitive drive.

    Security Champion Programs for the Win

    Organizations could also implement a security champions program. These programs vary depending on the organization, but in its simplest form, a security champions program designates a “champion” from each team. The champion is then tasked with leading the team as a subject matter expert as far as security goes. One thing to keep in mind here is that this program could be a major failure if done improperly. Remember, you don’t want to designate just anyone as the team security champion; you want to be sure you’re selecting an engaged employee that will prioritize secure practices and proactively communicate updates across the team.

    Regardless of what avenue an organization chooses, the name of the game is ensuring development teams are actively engaged with a relevant and realistic training program. The result of which will have an important downstream impact as organizations work to build a culture with a strong foundation in security. After all, “checking the box” can only go so far when it comes to developing a winning—and secure—solution.

  • Why You Need to Empower Your Developers

    Why You Need to Empower Your Developers

    In recent years, the demand for software developers worldwide has increased. However, in 2020, when the pandemic hit, many CIOs pulled back considerably on their IT spending. This trend has quickly reversed. In 2022, worldwide IT spending is expected to reach $4.4 trillion. Additionally, according to the U.S. Bureau of Labor Statistics, employment in software development is projected to rise by 22%.

    Although organizations across several industries are increasing investment into IT, the supply of technology talent has struggled to keep pace. With the demand for creativity, developers understand their importance and can better dictate their terms — including higher salary compensation and enhanced benefits. Organizations that don’t meet these expectations risk losing coveted talent.

    Remote work continues to be a top priority for many developers, along with great company culture. To create a positive work environment for developers, business leaders must offer a culture that makes tech employees feel a sense of belonging and purpose while working remotely. Many developers also want opportunities for growth and the ability to provide agile and innovative toolsets to help increase productivity and collaboration.

    Let’s discuss some of the ways modern organizations can still empower developers and how business leaders can build a workplace culture that attracts some of the best developers in the business.

    Provide a Supportive Digital Workplace

    Open source usage has increased significantly in the workplace and continues to be a formative resource for developers. The open source community provides many new technologies that developers seek and even require in order to work at the top of their abilities. For example, open source provides some of the most popular programming languages available, including Javascript, C+++, and Python. The presence of multiple languages makes it easier for developers to write code and produce high-quality work efficiently.

    Open source communities help developers build their skills and allow them to customize their technology stacks, as a result allowing them to optimize their productivity and learn different techniques from other open source projects. There is little to no debate that open source is critical to the tech industry and developers. Embracing open source can increase satisfaction and create a better workforce overall.

    Inspire Collaboration Among Software Developers

    In the past, office perks such as free food and collaborative social areas were used to attract new employees and retain current employees. However, in the remote work world, these can no longer remain a priority. Instead, business leaders should prioritize the holistic professional experience that their organization provides its employees. For developers, in particular, building this experience falls on CIOs and IT leaders to ensure they are providing workplace satisfaction, modern technology and flexible processes. To do so, they need to focus on tools that promote productivity and communication.

    Most employees are familiar with the workflow software and collaboration tools that many workplaces provide. Without these offerings, remote workers would feel confused by their workload at the worst and adrift from their co-workers at best. For developers, however, these general collaboration tools won’t cut it, as they are poorly suited for engineering workflows. General collaborative software doesn’t offer the ability for deep customization, nor do they adapt natively to deploy on-prem or in the private cloud. As a result, developers have little to no use for these tools.

    And that lacking sense of utility makes a crucial difference. Developer burnout is at an all-time high and inefficient workflows can keep teams from performing at their best. Or, worse, it can frustrate individual employees, leading to lower retention rates and less attractive offerings for prospective employees. Business leaders looking to offer developers an improved working environment should provide a more integrated, developer-oriented tech stack.

    Empowered Software Developers are Productive Developers

    While the market has changed, for many developers, fragmented tools remain a top productivity challenge. Investing in modern tools and programming languages while also removing tech complexities are the keys to improving productivity and simultaneously creating a better developer experience. This is why organizations must implement open source applications so developers can have complete visibility and control over the entire stack.

    With tool fragmentation causing a number of distractions, developers can become frustrated and spend time responding to every individual incident. This poses the threat of a developer losing their love of the work. By doing away with fragmentation from old technology and selecting relevant solutions, business leaders allow developers to do what they do best: Develop software.

    When organizational leaders empower their developers, they in turn find their product teams are more productive and feel more tied to the organization as well as their customers and each other. Thus, what is best for developers is best for the organization at large.

  • To Build a Durable SaaS Business, Rethink Your Product Roadmap

    To Build a Durable SaaS Business, Rethink Your Product Roadmap

    During a tech downturn, with enterprises cutting their subscription software budgets and VC funding drying up, SaaS businesses are increasingly shifting their strategic focus from growth to resilience. 

    The standard startup playbook—hunker down, cut burn rate and hope the market improves before you run out of runway—isn’t the right path forward for SaaS businesses. Instead, the key to durability is to lean into efficient growth. By revamping their product strategy, companies can lower the cost of customer acquisition with low-touch onboarding strategies and also increase revenue retention with stickier products, helping to unlock new ways to scale up and sustainably grow revenues. 

    Implementing this approach requires a fresh approach to your product roadmap—because when you scale through retention and expansion, the primary goal is maximizing utility for existing customers so they’ll increase usage and be willing to spend more over time. That means prioritizing core features and usability and not tacking on new features in a bid to draw in new customers with adjacent use cases.

    Getting that right, in turn, requires SaaS leaders to leverage the product itself as a key to understanding which features need attention, as well as a messaging channel and conduit for two-way communication with end users so you can influence user behavior and collect user feedback. Here are four steps that product managers can take to drive durable, resilient growth for their companies:

    Get Serious About Analytics

    Every business wants to use data to drive better decision-making—but many organizations fail to realize that their own product is their most potent source of data. Unlike web analytics which show only the behavior of random web users, product data has the power to help you understand the user journey, what they’re finding useful, what they’re struggling with—and how you can create value to keep them coming back for more.

    That makes product analytics—data showing how your product is being used, along with user surveys, messaging and other more qualitative measures—a powerful resource as you seek to anchor your development roadmap in the things your customers actually need. Armed with user feedback, it’s possible to learn how your customers feel, understand what’s missing—and invest in improvements that align with your users’ evolving needs.

    Stay Focused on Stickiness 

    Your analytics dashboard should have a strong focus on your stickiest features—the ones that keep users coming back for more. Those will include your product’s key value drivers during the early evaluation stage when you’re looking to hook new customers and turn their curiosity into a compelling use case for your product. But they will also include outcome-related features that enable established customers to measure and increase ROI as they scale up. Finally, they will include features that directly drive organic expansion, such as collaboration functionality that drives users to invite colleagues to use your product.

    Product managers (and their bosses) naturally get excited about new features—but by taking a data-driven look at stickiness across the whole customer life cycle, it becomes easier to identify opportunities to innovate around your core functionality and make it more integrated, scalable and productive. Customers won’t renew or expand their contracts because you rolled out a shiny new feature—but they will keep renewing if your team keeps investing in making their outcome-driven features the best they can possibly be so they can be successful at their job.

    Make Space for Quick Wins to Drive Advocacy

    If you view your roadmap as a waitlist for dev resources, it’s tempting to simply add newly identified usability bugs or hiccups to the bottom of the list, and circle back to them months later once your team is done working on building out new features. But in the end-user era, users control the renewal decision, so customer satisfaction isn’t a nice-to-have—it’s something you have to make time for to build and grow a durable business. That means pre-allocating time and resources for quick fixes and small enhancements that reduce friction, eliminate pain points with core features and drive stickiness for existing users. 

    As you track user experience across your stickiest features, you’ll find errors and pain points that need to be remedied promptly to keep your users happy. These are hard to plan for because they’ll emerge on a daily basis based on usage data and user feedback—so the key is to proactively assign resources to address these unplanned issues and turn them into quick wins, enabling you to iterate quickly rather than risking user frustration by adding core-feature fixes to your standard product roadmap.

    Influence User Behavior 

    User enablement is sometimes underestimated by product teams, but the shocking truth is that most customers won’t carefully read through your release notes in search of new features. In fact, they may not even notice your newly released functionality—and those that do might still struggle to understand how that feature supports their core use cases or to intuit the best practices for using it effectively. 

    To increase visibility into new features, you need to leverage in-app messaging, enabling your core users to unlock new functionality in an optimal way so you can capitalize on your product investments. As part of every release process, invest in user enablement by creating effective in-app communication with links to articles and videos that can help users adopt features successfully. 

    Invest in Revenue Drivers

    Of course, focusing on stickiness doesn’t mean slamming the brakes on all new features. The key is to use product data to ensure that innovations aren’t coming at the expense of core-feature usability. Before signing off on a new feature, make sure you have a hypothesis on how it will drive revenues—and remember: Innovative new capabilities might attract a subset of early adopters, but during a down economy your customers care more about must-have features than about nice-to-have add-ons. 

    Be sure to weigh a feature’s projected value—for your users and also in terms of revenues—against the cost of maintaining that feature over time. Every company has a finite amount of dev-hours to dedicate to perfecting its product, so even revenue-positive features can prove a drain on resources. Be realistic about what you can manage and don’t sacrifice long-term stickiness for short-term innovation.

    Remember Your North Star

    To make the right decisions during tough times, every SaaS business needs to focus on its North Star. For product managers, that means taking the time to understand—in a granular, data-driven way—exactly what makes their SaaS product worth paying for. Real resilience comes from leaning into those things and scaling by optimizing the user experience to make the product as sticky as it can be.

    Building durable and resilient SaaS businesses isn’t just about belt-tightening. It requires a commitment to scaling through the product and using it as a vehicle to drive retention and expansion by increasing value across your core features in ways that keep customers coming back for more. That, in turn, requires a fresh approach to your roadmap—because more than anything else, the way you understand and invest in your product will determine your company’s success or failure during the tough times that lie ahead.

  • DevOps Dozen² Awards 2022 Nominations Now Open

    DevOps Dozen² Awards 2022 Nominations Now Open

    The DevOps Dozen² Awards are back for their eighth year and nominations are open. These awards highlight, recognize and honor the outstanding and inspiring leaders who have made significant contributions to the DevOps community over the past year. We are very proud of the explosive growth and continued success of our community and we are excited to celebrate its hard work and achievements.

    For the third year in a row, we have expanded our DevOps Dozen awards program to include two different groups: The DevOps Dozen Community Awards and DevOps Dozen Tools and Services Awards.

    There are 12 awards within each group:

    • DevOps Dozen Community Awards—Honoring the leaders who have made a positive impact on the DevOps community.
    • DevOps Dozen Tools and Services Awards—Recognizing the companies that develop and deliver outstanding solutions to empower developers, DevOps and IT operations teams.

    Nominations are made by the audience. Anyone can nominate a tool or service, although there is a $250 entry fee for the Tools and Services Awards nominations. We implement this fee to cut down on spam and superfluous nominations. However, there is no fee for Community Awards nominations. Please note that commercial tools and services are not eligible for the Community Awards and will not make it through to the finals.

    Finalists will be selected and winners will be chosen from among the finalists. The finalists will be determined by general public voting (weighted for 40% of the final total) and our judges’ selections (weighted for 60% of the final total).

    The last day to submit your nominations is October 22, 2022. To vote, follow the steps outlined on the DevOps Dozen² website.

    Meet the DevOps Dozen² Judges

    We have an esteemed panel of judges with a wealth of experience and extensive industry knowledge.  Most have served as DevOps Dozen Award judges in the past:

    • Tracy Ragan, CDF board member and CEO at DeployHub
    • Charlene O’Hanlon, VP and managing editor at Activate Marketing Services
    • Mitch Ashley, founder and principal at Techstrong Research
    • Alan Shimel, founder and CEO at Techstrong Group

    Our judges will review the submissions made by the public and choose the winners.

    The 2022 DevOps Dozen² Categories

    DevOps Dozen Tools and Services Awards

    • Best End-to-End DevOps Tool/Service
      Consolidation in the DevOps space has led to a greater selection of platforms offering end-to-end solutions. This award honors the platform with the most diverse and robust solution for DevOps teams.
    • Best DevOps Repo/GitOps Tool/Service
      GitOps has become an integral part of the DevOps toolbox. This award is presented to the most outstanding code repository/Git/GitOps tool.
    • Best CI/CD Tool
      This award recognizes the best CI/CD tool that helps teams to deliver quality code faster.
    • Best Value Stream Management Tool
      Value stream management has come into its own as an important tool for measuring the business value of DevOps and application development. This award recognizes the value stream management tool that most effectively helps organizations visualize the value stream, track metrics and measure improvement.
    • Best Observability Solution
      This award recognizes the best observability solution for understanding the performance of individual components, systems and entire applications.
    • Best DevSecOps Solution
      This award honors the best DevSecOps solution, which enables security to be included earlier in and continuously throughout the SDLC.
    • Best Testing Tool/Service
      Testing is a mainstay in the DevOps toolchain. This award recognizes the best testing tool for ensuring the quality of code.
    • Best Kubernetes Platform/Service
      The adoption of containers has paved the way for an entire solutions ecosystem. Kubernetes is perhaps the most widely recognized and utilized tool for container orchestration. There are many platforms and services that offer Kubernetes-based solutions. This award honors the best Kubernetes platform/service available.
    • Best Cloud-Native Security Solution/Service
      The cloud-native movement has taken the IT world by storm due to the depth and breadth of the solutions available and the benefits of building applications and services specifically for cloud-native environments. This award recognizes the best cloud-native tools, solutions and services.
    • Best DevOps for Mainframe Solution
      Despite their age, mainframes are a mainstay in the IT world, and a variety of solutions are available for enabling DevOps practices in mainframe and hybrid environments. This award recognizes the best of them.
    • Best DevOps for DataOps/Database Solution
      Databases often have been left out of the DevOps conversation, but that is changing  as the concept of DataOps is gaining greater traction. This award recognizes the best solution in the database and DataOps space.
    • Best New DevOps Tool/Service Provider
      This award recognizes the best new service provider or tool that has brought innovation to the DevOps space in the past year (must be less than 24 months old).

    DevOps Dozen Community Awards

    • Best DevOps Industry Implementation
      This award honors organizations that have successfully adopted and implemented DevOps principles and practices.
    • Best DevOps Survey/Analysis/Research
      This award recognizes research that has significantly and positively impacted the DevOps community.
    • Best DevOps-Related Video Series (video)
      This category highlights the most entertaining, educational and inspirational DevOps video series—those with the most engaging and highest-quality content.
    • Best DevOps-Related Audio Podcast Series
      Which is your favorite DevOps podcast from this year? This category celebrates the many great DevOps podcasts driving discussions about everything from CI/CD and testing to DevSecOps, Kubernetes, containers and more.
    • Best DevOps Book/eBook of the Year
      Each year sees a plethora of well-crafted DevOps-related books and ebooks. This category highlights the most popular and  most-read of the year.
    • Top DevOps Evangelist
      This category is one of our favorites! There are so many great evangelists who spread the DevOps gospel, but we want to know who does it best. Nominees can work within the DevOps space or outside of it.
    • Best DevOps Transformation (non-vendor)
      In a year marked by continued digital transformation, we want to know which organizations stood out in their efforts to transform their business through DevOps.
    • Best DevOps Event of the Year
      Virtual events became the norm throughout  the pandemic. But as more people crave face-to-face interaction, in-person events have slowly made a comeback. Which DevOps event stands out from the crowd?
    • Most Innovative DevOps Open Source Project
      Open source projects are meant to promote innovation and increase efficiency, velocity and quality. While there are many great open source projects out there, the best ones are those that create a community of people who work on and with the technology and support each other.
    • DevOps Executive of the Year (non-vendor)
      This category celebrates excellence among DevOps leaders at the C-suite (or equivalent) level.
    • Best DevOps Presentation of the Year
      This category recognizes the best DevOps-themed presentation from the many (virtual) conferences that took place this year.
    • Best DevOps.com Article of the Year
      This category celebrates excellence among DevOps leaders at the C-suite (or equivalent) level.

    With so many talented and inspiring leaders empowering our community, choosing a winner is no easy task. Although not everyone can take home an award, being nominated is still a remarkable achievement and serves as validation that you’re on the right path. We greatly appreciate your dedication and service to the DevOps community.

    For more information, please visit the DevOps Dozen² website. If you have any questions regarding the nomination process or any technical issues regarding the website, please contact us at DD@devops.com.

  • Heat Cooks Twitter DC | AI Will Kill All Humans | Patreon Layoffs, CSAM Claim

    Heat Cooks Twitter DC | AI Will Kill All Humans | Patreon Layoffs, CSAM Claim

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Twitter is in a “non-redundant state” thanks to a hot summer, AI is likely to eliminate us, and Patreon fires 80 staff amid nasty allegations (TW: Child safety). (more…)

  • The Definition of Done: Why it’s Important for Success

    The Definition of Done: Why it’s Important for Success

    Establishing clear communications and expectations across software organizations is essential to the success of any project. A company is less likely to experience unexpected delays or other unpleasant surprises if everyone is on the same page. To ensure all team members are synchronized and to eliminate unnecessary ambiguity, engineering teams should create a “Definition of Done” to guide projects.

    What is the “Definition of Done”?

    In Agile software development, the definition of done is a working agreement between teams that defines a set of standards to identify something as “done.” Because Agile is an iterative approach to software development, sometimes it is unclear when a task is complete. Product managers often report that something is ready for delivery when it’s “Dev done” and not “QA done.” In other words, the code has been written, but no documentation or tests have been created or executed. For other parts of the software organization, code without QA or documentation is not “done.” Intuitively, the definition of done exists to eliminate confusion about what “done” means across an organization.

    How to Create a Definition of Done for Your Software Organization

    For some software organizations, the definition of done is a static set of guidelines and benchmarks established at the start of a project. For other organizations, including here at Allstacks, engineers have the latitude to amend the definition of done as they go. That approach empowers an engineering team to make decisions that will produce the best possible results.

    When establishing a definition of done within an engineering organization, consider these tips:

    ● Communicate criteria in a way that the whole software organization can universally understand.
    ● Ensure that the definition of done addresses both tactical and technical requirements.
    ● Create a living document for alignment that can be amended because of unforeseen circumstances, like losing a team member or a significant market shift.
    ● Consider that the robustness of the document will vary by team maturity, and specific teams might need an addendum for special requirements. For example, bigger enterprise IT teams frequently need more detailed documentation compared to two-person shops.
    ● Establish an understanding among all teams that, until all criteria are met, the user story, task or project is not “done.”

    A definition of done acknowledges the shared responsibility between the frontend, backend and QA. Beyond those roles, other stakeholders might contribute to defining “done,” like Scrum masters, board members or business analysts, depending on the organization and its structure. Further, the product owner may also define “acceptance criteria” with goals targeted toward the end-user experience that the engineering team must also address as part of their work.

    How a Definition of Done Can Help Teams be Successful

    The definition of done helps a software organization maintain alignment on projects and keeps everyone on the same page. Misalignment can have heavy consequences. For example, it can initiate premature conversations with customers before a product is really ready, create friction between internal stakeholders and/or risk other go-to-market initiatives. When the definition of done encompasses defined steps for a project down to the task level, Agile teams can create more cohesion across an organization and eliminate unforeseen delays.

    A definition of done outlines each task in a software engineering project. Noting the completion of each task can be an indicator of whether a project is on track to meet established deadlines. By noting the time it takes to complete each task, an engineering team can measure the velocity of a project, and that can help protect due dates or raise a warning flag about the need to shift timelines.

    The Definition of Done Helps Support Software Team OKRs

    Objectives and key results (OKRs) are a goal-setting framework to help senior leadership focus on what matters to the organization. By defining software engineering OKRs, senior developer leaders can keep their teams focused on aligning engineering goals and activities to business outcomes while also giving them room to experiment.

    Creating engineering OKRs involves taking the organization’s objectives and crafting actionable, generalized engineering objectives while identifying the metrics and milestones that drive progress. Translating the organization’s objectives for the engineering team helps them to understand exactly how their work impacts the company.

    One of the key benefits of the OKR framework is giving the engineering team a shared language and vision for success. However, without an established definition of done, OKRs will have a lot of unintentional gaps (and teams will have a lot of misunderstandings). Start with a definition of done to ensure that each team knows what their part is and when it’s officially ready for handoff to another team. Teams will pass the baton smoothly across the organization and there will be fewer obstacles in the race toward release in the market.

    A Definition of Done Can Help Organizations Grow Smarter

    In a small startup with a handful of software employees, establishing a shared understanding of timelines and goals is easy. As software organizations grow, casual chats at the water cooler aren’t enough to keep an organization in alignment. All team members must understand and have input on goals and objectives and those goals must be in writing and accessible to everyone. The benefits of establishing a definition of done include creating a shared understanding and unified language for software delivery, ensuring that new employees have access to tribal knowledge and process expectations, and detecting and removing false agreements between teams to create real consensus. By creating a definition of done early in an organization’s history, company leaders can ensure alignment even as more people join.

  • Kintaba Creates the First Conference Dedicated to Incident Response – Techstrong TV

    Kintaba Creates the First Conference Dedicated to Incident Response – Techstrong TV

    John Egan, Co-founder and CEO at Kintaba, talks about IRConf, the first conference fully dedicated to Incident Response. The company behind the conference is Kintaba — a modern incident management platform for the entire organization. The video is below followed by a transcript of the conversation.

    Alan Shimel: Hey, everyone. Welcome to Techstrong TV. We have got another segment for you here. I’m happy to be joined by John Egan. John is the CEO of Kintaba Incident Response. 

    Hey, John. Welcome to Techstrong TV. 

    John Egan: Thanks, Alan. Good to be here. 

    Alan Shimel: Nice to have you. So, John, you know, I might have messed up what your position with Kintaba is. 

    John Egan: That’s right. CEO and Co-Founder. 

    Alan Shimel: Okay. And you know what? I mean I’ve heard of Kintaba, but that doesn’t mean our audience knows Kintaba, so if you wouldn’t mind, give us maybe a quick little background on Kintaba and maybe a little bit of your own background? 

    John Egan: Yeah. So, Kintaba is an incident response platform. We’re designed to let any organization be able to easily implement best practices for responding to critical moments within the company, so this tends to be things like site outages, major customer issues, and other sort of technical and non-technical problems that require kind of a group real-time response, you know, separate from like project management where you might have planned things that are happening. You take, like, the outage that happened, I think yesterday, at GitLab was a good example, right? Or a slack outage like that, that has an incident response team that’s responding to that situation and making sure it gets fixed quickly, and they’re probably using some kind of tool, either internally or off the shelf, and we’re that tool that any organization can implement in minutes instead of bringing in a consultant and spending months on this kind of stuff. 

    Alan Shimel: Absolutely. You know what was interesting, John, is I mean look, I’ve seen, for whatever reason since I’ve started DevOps.com eight years ago, incident response has always been like this, you know, it’s part of the DevOps story, and we’ve seen of course, you know, several companies have very successful exits and be, you know, very successful. They all kind of follow this pattern where they, you know, were replacing the beeper, then they became incident response. Then it becomes a whole platform, and APIs and integrations, and so forth. What makes Kintaba different? 

    John Egan: So, we’re really purists on the incident response side of things. I think a lot of organizations that come into this space end up either kind of pivoting over towards alerting, all right, which is sort of Pagerduty’s world – 

    Alan Shimel: Right. 

    John Egan: Which is more about automated detection, ping someone, it gets closed out, you know, you might get thousands of these things across the organization, or they go broad and start to become, you know, more of like an SRE platform to try to handle all of these different things that the site reliability engineers are really managing inside of the organization. But we really believe that incident response stands on its own as a practice that cuts across all of the organizations inside of your company. So, something unique about Kintaba is normally when you’re rolling it out within the organization you might start small. You might start with five or six seeds, a couple of people in SRE, but really rapidly we tend to get deployed across the entire organization and what we do really well is we’re a collaborative layer that helps everyone from customer success, to your SREs, to even your PR and marketing guys all be connected during these critical moments and all have one place that they can go to see what’s happening and participate in that response. 

    It’s a bit more of, you know, we call it an evolved sense of incident response, right? Versus kind of the old-fashioned way of looking at it, which might be two or three people in your SRE team are responsible for this. It’s really more about the entire community of your organization that responds to these company critical moments and building software that makes it easy for all of those people to participate. So, we’re a very non-technical feeling piece of software. We’re very human driven, everything from our reporting, to our collaboration experience, to the way you go and write documents, which is a new feature we’ve just released, all of this information is designed to be as easy to use as something like Google, as opposed to being, you know, more like a, you know, almost like a service now, kind of like complex enterprise implementation. 

    Alan Shimel: Got it. Good stuff. And, John, we’re going to talk about this conference you guys are putting on, but before we go, before we dive into that, you know, so we understand what Kintaba is. You know, in your go-to market here what are you guys finding? What are you seeing? You know, what’s kind of the state of the market, if you will? 

    John Egan: So, we’re really learning a lot about this community as it’s just starting to form, right? I think when communities are young and they’re new you actually find the best practices are pretty fluid and I think it’s one of the unique things about this space is Google put out a book back in 2016 where they sort of defined how they handle incident response internally. It was the first time anyone really wrote it down in a way that could be absorbed, but it turns out every organization has a slightly different attitude that they take towards this space and when you’re implementing a product, something like Kintaba, it really turns out that that product has to be pretty flexible on its way in to make sure that it’s easy for people to adopt, and then it also has to bring with it sort of almost like a light hand to say these are the very high-level macro steps you’re going to take to be successful, right? 

    And so, what we’ve learned early on is when Kintaba first launched, you know, over a year ago, we were very rigid about the way that you sort of had to come in and step through, you know, each part of incident response. What we’ve really learned and what the products evolve towards is to have rigidity around the high level steps report openness around visibility to when incidents are happening, like easy to use collaborative spaces, post mortems that editable and changeable, but also, be flexible in terms of who’s getting access to this thing, how are you giving people titles that are non-technical in the, like, customer success roles, you know, and in the marketing and PR roles, and how do you bring all of that together at once. We thought when we came in that, okay, maybe this would be a couple of seat experience for people, you know, you come in and maybe you need two or three seats, greater, four or five, and what we’ve really learned is these are company practices, like I was saying before, and I think that’s been kind of our big learning about the space is as the community grows this is really a cross-functional community inside of organizations rather than just a technical practice inside of DevOps and I think that’s really exciting. 

    Alan Shimel: Yeah. Absolutely. Absolutely. So, John, you guys are coming in behind the first dedicated incident response virtual conference coming up in April. Why don’t you – well, I already said it I guess, but why don’t you take it from there? Tell us more. 

    John Egan: Yeah. So, IR Conf, or Incident Response Conference, was really built out of the fact that we just couldn’t find another one to be part of that was focusing purely on the incident responder. When we talk about communities internally, you know, you think of communities as what makes people put their hands up and say, “I’m part of that,” right? I think DevOps, and SRE, and a lot of these spaces have done a good job, right? We have crowds and people will say, “Okay. I’m part of that.” Incident response has always  been one of those ones where I think people sort of nervously said, “Well, I think I’m part of that.” What IR Conf really does is it focuses not on sort of that statement of I’m in the incident response department, but instead focuses on the idea that I’m a responder, right? I’ve been part of responding to a major incident and when you ask that question it turns out a lot of hands go up and it turns out that there’s a community there that’s really looking for other practitioners to come together and talk about these things I was just talking about, right, best practices, right? What are other companies experiencing? How are we defining this role and the people who are involved? And so, what’s really cool about this conference is we get to focus really directly on that incident response process, you know, not even necessarily as it relates to other parts of DevOps, but just how we deal with this very specific problem that faces all organizations. 

    So, I’m really excited we have one our keynote is Emily Freeman, who’s out of AWS – 

    Alan Shimel: Sure. 

    John Egan: And has done all kinds of great talks about kind of the wider, softer development lifecycle inside of DevOps, and here she can speak much more directly, you know, to this response, incident response space. I think you can see the excitement around it. You know, we have sponsors, basically everyone across the DevOps world, Honeycomb, Commodore, Rookout, BridgeCrew, Gremlin, Teleport. All of these folks, you know, really came running in and said, “Yes. This is great. We need a space to come in and talk to our sub-communities that are already using our products that care about this space,” and so really, we just felt like there was a hole in the market and so this is a free conference. Anyone can join. This is a virtual conference. It’s on April 1st. It’s at IRCONF.IO if you’re out there looking for it. We’re really hoping to just get everyone to come along who’s ever been involved in an incident before and has experienced that fire moment inside of a company of, you know, hopefully not panic, but maybe panic, and wants to come together and talk to other folks, who have had the same experience. 

    Alan Shimel: Sure. I’m thrown back to my cyber – we didn’t call it cyber then – to my infosec days in the war room, you know, when stuff hit the fan. You know, best practices that were to set up a war room on how to respond to a breach, you know, some sort of attack. 

    John Egan: And that’s really where a lot of this grew out of, right? 

    Alan Shimel: Sure. 

    John Egan: We have incident response really lived in the security world – 

    Alan Shimel: Yeah. 

    John Egan: And it’s one of these parts of the evolution of the space, right, that now we’re adopting, you know, that process that really got its feet inside of the security incident response space across the organization to say, “Wow. These guys are doing a great job,” like, “We should be doing similar work across the org.” 

    Alan Shimel: Not all companies had such a great job on their war room, but that’s a whole other story. 

    Hey, John, you mentioned Emily Freeman speaking. Who are some of the other speakers? 

    John Egan: We’ve got two more who are announced right now and it’s Emily Freeman, and it’s Dave Rensin. Dave Rensin was previously at Google and ran a good chunk of the SRE Team there. He’s at a new organization now and he’s spoken at a couple of other conferences in the DevOps space, specifically about the process of incident response. I’m really excited about him being able to come in as well and talk, both, from a large company standpoint, right, a company like Google, where he really pushed a lot of customer metrics, right, for dealing with incidents, not just internal technical metrics, as well as the smaller company, like where he’s moved to now is a startup.

    Those two are kind of our cornerstones. Then we’ve got a series of other speakers, who are announcing over the next couple of weeks – 

    Alan Shimel: Who?

    John Egan: Who are coming in from all over industry, so I’m really excited. I’m can’t announce them here yet. They’re not finalized yet. 

    Alan Shimel: Okay. Good. 

    John Egan: Really exciting. Great organizations. 

    Alan Shimel: Can’t blame me for asking. All right. Hey, John, for people who are interested, that was IRCONF.IO? 

    John Egan: That’s right. IRCONF.IO. You go in there and just click Attend and register. We’re still at early bird, so everything is free right now. 

    Alan Shimel: And it’s April 1st. Do you have times on that? 

    John Egan: I believe we’re planning to start it early, around 8:30 is the beginning of it. 

    Alan Shimel: East Coast time? 

    John Egan: It’s technically a half-day, but it runs until about 2:00, I believe. 

    Alan Shimel: So, that’s East Coast time though? 

    John Egan: East Coast time. Yes. 

    Alan Shimel: Yep. We’ve got a global audience here, so that’s East Coast U.S. time. 

    John, sounds great. You know, if there’s a need in the market, you know, the market has a vacuum, so it’s good to see it getting filled here. I want to wish you the best with it, with the conference and with Kintaba. 

    John Egan: Great. Thanks, Alan. 

    Alan Shimel: It was great having you. John Egan, CEO, Co-Founder, Kintaba, the folks behind IRCONF and you can find out more about that at IRCONF.IO. That’s coming April 1st. Check it out. 

    We’re going to take a break here on Techstrong TV and we’ll be right back. 

  • DevOps World 2022: Developer and Security Links Protect Your Supply Chain

    DevOps World 2022: Developer and Security Links Protect Your Supply Chain

    Ever since the SolarWinds attack back in December 2020, software supply chain attacks have been top-of-mind for any company that builds software. The idea of endangering not just your organization by being attacked but also your customers really sharpens your focus.

    Another complicating factor is that applications use a combination of open software components and homegrown code to deliver applications. This software supply chain means your software can be compromised through no fault of your own but instead based on the components you use. The Log4j attack is an example of a component creating vulnerabilities in any software that uses it. So how do we defend our software? We need to think differently about where security starts and how security concepts can be integrated into software earlier in the development process where it interfaces with the rest of the technology infrastructure.

    Building a Secure Pipeline

    Modern software development is built on the CI/CD pipeline. It allows the application security testing and software composition analysis to happen way earlier in the integration process (shift left), and that allows you to identify and fix issues before the code gets anywhere near customers. Sounds simple, no? Just run your code through a pipeline, integrate security testing, identify issues, fix them, and deploy secure software.

    As with most things, what sounds simple in theory can be challenging to implement in reality. First, shifting left requires a collaboration between developers and security teams. Finding the security issues don’t matter if they don’t get fixed. To increase the likelihood of these issues getting fixed, the security team needs to provide context to the developers regarding the urgency of the flaw or vulnerability and some guidance on the best way to fix the issue. To be successful, security folks can’t just drop a report with hundreds of defects and vulnerabilities on the developers and expect that anything productive is going to happen. If this scenario reminds you of getting a report from your vulnerability scanner with hundreds of issues you won’t fix, well, that’s because it’s very similar.

    Second, security must add value to the development and architecture process by offering up infrastructure-as-code (IaC) templates and a toolchain that makes it easy to implement secure application stacks. Maybe that looks like a template library managed by a cloud security Center of Excellence, which can provide these tools across all of the application teams leveraging efforts.

    Combatting Supply Chain Attacks

    Finally, you can implement a security champions program, training a developer (or two) on each team about security issues and they can act as a security emissary to the developers. This provides scale, ensuring that the security team doesn’t become a bottleneck to fixing the security issues.

    Given the sophistication of the software, the attack surface of the code, and the velocity of the development process, combatting supply chain attacks requires tight and ongoing collaboration with the development team and shifting left to catch the security issues earlier in the integration process.


    Want to learn more about this and other related topics? Join CloudBees for DevOps World 2022, held in Orlando, Florida, at the World Marriott Center. Use discount code DW22 when registering and get access to all the fantastic offerings, including keynotes, sessions, training and other interactive activities. We can’t wait to see you there for the DevOps Remix!