devopsy.kinsta.cloud

Tag: collaboration

  • Bridging Departmental Divides for Successful Automation Projects

    Bridging Departmental Divides for Successful Automation Projects

    For too long, IT has been largely isolated from an organization’s core business. Any division between IT and lines-of-business (LOB) is even more detrimental when speed is not just a competitive advantage but an existential necessity in today’s accelerating digital economy. 

    As business leaders streamline and turbocharge every facet of their operations, savvy organizations are rushing to eliminate inefficient and damaging gaps between departments by putting more software tools in the hands of more employees. Analysts predict 80% of technology products and services will be built by those who are not technology professionals by trade by 2024. 

    This hits home amidst the booming trend toward robotic process automation (RPA), low-code/no-code and other automated solutions, which have only continued to grow as more businesses realize the vast benefits of automation: Accelerating operations while also reducing costs; elevating customer experiences and shifting employees to higher-value positions and laying the foundation for new data-driven revenue streams.

    Squandering Automation’s Advantages

    But these advantages are quickly squandered if there’s a turf battle between the business unit looking to optimize processes and the IT department responsible for deploying the tools to make that happen.

    When there isn’t collaboration and plenty of trust on both sides, automation initiatives are more prone to disappointments and delays. 

    This may happen if the IT department comes across as too smart for their own good, putting less value on feedback from their LOB colleagues and rushing to implement software with a focus on speed rather than outcomes. On the LOB side, leaders may assume their IT counterparts are too technical and don’t understand business objectives and choose to override important IT input about which vendors are best qualified when it comes to support, integration and security.

    The problem here is not the technology; hundreds of thousands of businesses across the world have successfully deployed process automation solutions. It’s the execution.

    When an automation initiative fails, there’s almost always blame to be shared on both sides of any divide. Likewise, success typically boils down to people across IT and every business department working better together to achieve a common goal. 

    To embrace a collaborative mindset and set up your automation projects for success from day one, I encourage you to follow these clear steps:

    1. Reinforce a shared mission: Whether it’s automating the customer onboarding process or deploying RPA bots to automate a repetitive, time-consuming process, communicating a shared mission is the crucial first step to pulling off a successful project. On the IT side, that involves talking with the LOB about their goals, objectives and business strategy. LOB leaders, meanwhile, can emphasize that IT is an equal business partner that has valuable insights and expertise to contribute.
    1. Establish visibility and transparency: Armed with a full understanding of business objectives, IT leaders can now evaluate tools built to give all stakeholders a full view of the processes that will be affected. By documenting and mapping out each process within an organization, leaders can better understand current processes and gain insight into areas that are ripe for standardization and automation. 
    1. Tailor solutions that match the problem: With heightened visibility across the organization, LOB and IT teams can then determine the scope of each problem and tailor solutions accordingly. Some processes can be kept and optimized; some can be tweaked with automation. Other processes may need to be reconfigured significantly before automating or shut down entirely because they are outdated or unnecessary. 

    A great example of this collaborative approach comes from Coca-Cola Beverages Florida, LLC (Coke Florida): Encumbered with a legacy process repository — a collection of PDFs, videos, pictures and spreadsheets outlining more than 600 processes — Coke Florida standardized and leveraged visual process mapping software to establish an easily accessible document repository that provides visibility and control over key processes, encourages collaboration and increases accountability. 

    Coke Florida continued an organization-wide initiative to digitize and automate its business processes with digital workflows, forms and RPA software, driving further efficiencies across its entire organization. As the company discovered firsthand, shared goals result in shared success. 

    When speed and high-quality outcomes become the norm, companies master the essential arts of urgency, resilience, visibility and collaboration. By bridging the divide between departments, organizations not only drive internal efficiencies but also gain a competitive advantage that is indispensable in today’s burgeoning digital economy. 

  • Atlassian Survey Shows Lack of Collaboration in Software Development

    Atlassian Survey Shows Lack of Collaboration in Software Development

    A survey of 750 IT and engineering leaders found that while a full 83% of respondents agree that interdepartmental communication is critical for successful software development, only 41% of respondents view cross-collaboration to be a priority.

    The survey gathered responses from within organizations that generated more than $50 million in annual revenue and was conducted by Forrester Consulting on behalf of Atlassian.

    Overall, more than two-thirds of respondents (68%) said more departments than ever are involved with software development. Overall, 80% said they need to improve collaboration with other departments, but 82% don’t feel particularly confident about their ability to accomplish that goal. Three quarters (75%) also noted the need to improve collaboration within their own department.

    Well under half of the respondents (42%) said their culture, processes and tools enable the real-time teamwork and free-flowing information that help leaders make sound decisions.

    Among the subset of respondents that are highly collaborative, however, more than (53%) said they see greater customer satisfaction, with 59% reporting increased revenue because of that increased customer satisfaction.

    Suzie Prince, head of product for DevOps at Atlassian, said the challenge organizations face is finding a way to successfully employ a mix of synchronous versus asynchronous communication mediums to better enable collaboration. In fact, collaboration as part of any DevOps culture needs to be a C-level discussion to consistently accelerate the rate at which software can be developed and deployed, she added. The core issue is that not every management team is equally comfortable with open communications between the various departments that make up an organization, said Prince.

    It’s critical for C-level executives to set that tone and lead by example; DevOps best practices can’t only be adhered to by development teams. The entire business needs to embrace DevOps best practices as an operating model for the business to really attain the maximum benefit.

    Unfortunately, DevOps practices within development teams have been unevenly adopted, so it’s often very difficult to get the rest of the business to embrace DevOps principles. Organizations that do embrace DevOps, however, tend to be much further down the path toward becoming a digital business and can more adroitly take advantage of business opportunities as they arise or shift strategy as changing business conditions may warrant. In fact, organizations that embraced DevOps best practices arguably fared better during the economic decline that followed the onset of the global COVID-19 pandemic that took every business and IT leader by surprise.

    It’s not clear from the Atlassian survey results if a DevOps divide is starting to emerge that makes some organizations more competitive than their rivals. In theory, at least, if every organization is now a software company that happens to build something or deliver a service, then the faster they can reliably build and deliver applications the greater the competitive advantage they can attain and sustain.

    There are, of course, a whole host of factors that determine how competitive any organization might be. However, in the age of digital business transformation, it’s clear that being able to build and deploy software at a fairly regular cadence is the new table stakes required for simple survival.

  • Managing Cloud Governance Costs Collaboratively

    Managing Cloud Governance Costs Collaboratively

    For those responsible for managing infrastructure, the concept of governance is common, especially as it relates to cloud services. For cloud services, it’s defined as a framework that guides how end users use these services by defining and creating policies to control costs, minimize security risks, improve efficiency and accelerate deployment.

    The term is often associated with “rules” or “compliance” and can restrain innovation within an organization, as it typically is mixed with regulatory bodies and governance procedures that add cycles to required tasks. But what if we could flip the script and make governance more of a collaborative effort? What if we used an approach wherein teams across an organization share information and feedback for better business outcomes?

    This collaborative approach can be beneficial in ensuring everyone is on the same page, enabling businesses to get the most out of their cloud infrastructure while ensuring costs stay within budgets.

    Legacy Governance Overshadows Growth and Creativity

    Legacy governance is an extremely paranoid way of running your business. For example, blocking people or departments from making buying decisions is a perceived best practice to avoid overspending on cloud infrastructure. Unfortunately, this is actually the opposite of what organizations with cloud infrastructure should do.

    The advantage of the cloud is that it gives your organization the ability to develop and bring products to market faster—and at a lower price point—than traditional methods. Following legacy governance processes—adding more steps to the process for provisioning resources—results in slower launch times and overprovisioning of resources (since there is a lack of visibility and teams are not sure when they will get more), negating the cost benefits of on-demand cloud infrastructure over traditional data centers.

    Empowered Employees Produce the Best Results

    Think about it: An overbearing manager or boss makes you feel like you’re walking on eggshells when it comes to your work. Sometimes, this is the same effect legacy governance policies can have on employees.

    Removing access barriers and giving team members the freedom to easily request and use resources should be a cloud operator’s ultimate ambition. It’s also cost management that’s collaborative.

    The idea behind a collaborative approach to managing costs is that the individuals who work on the projects themselves–whether that is the engineering team, DevOps teams, etc.–are best suited to manage them and provide the proper infrastructure recommendations because they know what their needs are.

    To receive the full financial and organizational benefits from a collaborative approach, there are three simple steps to take:

    Have a Consistent Source of Truth

    Have a consistent and agreed-upon source of truth for decision-making and self-evaluation against key metrics. This means that everyone in the business—executives, finance, managers and individual contributors—are aligned and looking at the same numbers. When this happens, teams spend less time haggling about ownership and more time looking at how they can improve. When this doesn’t happen, the focus turns to storytelling about why the numbers are wrong, not solving the underlying inefficiency problem.

    Trust the Team

    Trust the members of your organization to leverage this information for the best possible business outcomes.

    Collaborate

    Encourage collaboration inside and between layers of the business to ensure the decisions are made with the complete picture in mind.

    Implicit tradeoffs are made every day at every business level for teams to align their work to organizational priorities. Encouraging collaboration between different layers, viewpoints and skillsets in the business helps to highlight these implicit decisions and make them explicit, intentional and agreed-upon

    Moving away from legacy governance to a more collaborative approach is within reach for any organization. The key is understanding what methods are required for the transition to be a seamless and positive experience that teams will embrace.

  • Reducing Friction in Developer Collaboration

    Reducing Friction in Developer Collaboration

    Given how the individual unit of deployment has gotten increasingly smaller, such that the unit of deployment is usually a microservice, it would be tempting to think that individual developers are more able to control how well the code they write (the service they deploy) will work in production. In fact, though, almost the opposite is true. Instead, as the number of services in an environment increases, whether or not one service will work correctly in a production environment has more to do with how well it works with other services rather than the quality of the code.

    This makes collaboration between developers even more critical than ever before, but the packaging of code in microservices actually makes collaboration more challenging. Developers don’t collaborate by working together on a shared codebase — instead they work completely independently on services that could easily be written in different languages, providing the illusion of complete independence.

    In most organizations, ensuring that services work together is a largely informal process. It’s managed by walking over to a colleague’s work station and asking what updates they’re working on or what version libraries they’re using. In a remote work environment, teams rely on Slack messages or Zoom calls to solve issues relating to services interaction. This creates a lot of friction for something that is a critical part of the software development workflow. Failures in service integration can and do cause problems in production.

    Pay Attention to Service Communications

    A perfectly crafted microservice is not going to run in isolation in the production environment. Compatibility issues between each service and upstream and downstream dependencies are just as likely to cause bugs, downtime and poor performance as problems with the code deployed in a container.

    The only way to catch compatibility issues before production is for developers to work together and communicate about the updates they’re working on and how those might impact interdependent services. In the current system, however, this level of collaboration introduces a lot of friction in the development workflow, reducing the individual’s and the team’s velocity. Since developers are generally evaluated based on velocity and code quality — but not necessarily on how well their services work with other services — if the friction remains, developers will be tempted to deploy without fully understanding how dependencies will be impacted.

    Since CI/CD pipelines are generally not set up to test how well services communicate with each other, problems with service fit that aren’t addressed at the development stage generally aren’t found until either a canary deployment goes wrong or there are problems in production.

    Replacing Tribal Knowledge

    One of the other reasons companies need to focus on developer collaboration is that remote work has made it even harder to communicate tribal knowledge. In my experience, no development team has been able to completely wean themselves off of tribal knowledge. Even teams with extensive technical documentation often had or have experienced team members who maintain a unique understanding of the application’s business logic and can share that knowledge when needed.

    Tribal knowledge also relates to service integration and communication — often, insights about how services work together isn’t well-documented, even if each individual service is well-documented. Often, the easiest way to see how they would work together is not to have the two developers responsible for each service work together, but rather to have a senior developer take a look. Especially as development teams work remotely, that type of review isn’t feasible.

    How to Help Developers Collaborate

    Most teams have ways for teams to communicate — they have a Slack setup, they have internal forums and video conferencing solutions. But they often don’t realize that these communication platforms aren’t really collaboration platforms — they are not providing a way for developers to actually work together on interdependent services the way they might if working on a shared codebase. Communication isn’t enough for true collaboration to happen — developers need a way to work together and see how colleagues’ changes impact their own services.

    Facilitating true collaboration, the kind you would get from two people looking at the same screen and coming up with solutions together, is more challenging than making it easier for developers to talk to each other. Without true collaboration, teams will continue to have trouble with communication between services — and there’s no Slack for that.

  • Key Success Factors for Your Nearshore Initiative

    Key Success Factors for Your Nearshore Initiative

    The IT talent shortage is becoming a growing problem. The U.S Bureau of Labor Statistics projects the industry demand for software developers will grow 22% between 2019–2029. This is significantly higher than the average demand growth rate of 4% for all other occupations. As the IT talent gap grows, companies across industries are looking to nearshore partners to help fill the void. Unlike offshoring, nearshoring relies on partners geographically located in the Americas, as opposed to Europe or Asia, for example. It is a growing segment of the market. Case in point, Brazil’s software development services exports have grown 1000% in the last 10 years, gaining an increasing foothold from in the United States for innovative software development and digital transformation initiatives.

    There are several advantages to outsourcing your software development needs to a nearshore partner, including access to high quality IT talent, lower costs, faster time-to-market and, most importantly, the productivity increase that comes with full-time collaboration. With a growing list of global providers in the market, how do you go about selecting the right partner? Here are three important factors to consider.

    Time Zone Proximity

    There are many benefits to being in close geographic proximity and in a similar time zone to your development partner. Being able to have regular iteration reviews during your regular business hours can make or break any project. Everyone is already taxed with a full day of video meetings during the pandemic – why make it more difficult? I’ve heard horror stories from corporate leaders trying to manage partners on the other side of the world with a 12-hour time difference. Time and distance challenges can be disruptive, lower productivity and hurt team building. The importance of real-time communication, feedback and collaboration cannot be underestimated during the software development process. We are all looking forward to getting back to face-to-face meetings, and being in closer geographic proximity will make travel easier once we can gather together again.

    Cultural Alignment

    Teams built on collaborative partnerships are the most successful. The first step to ensuring your teams can successfully tackle your software projects is to make certain the team knows what problems you are trying to solve. That can be more difficult than it seems when working with global partners. My own experience has taught me that different cultures have different work styles and can approach projects in different ways. The culture similarities between North and South America for example, make it easy to stay culturally aligned and approach projects in a more collaborative way. Creativity, innovation and collaboration need to be guiding principles, and your partners should be recognized for their technological capabilities, results and business acumen. Strong teams offer professional support and recommendations during the co-creation process, adding value across all deployment cycles. When projects require collaboration and coordination, cultural alignment becomes more important than ever.

    Ability to Scale

    Most companies start out outsourcing small projects to their partners to gain confidence and trust in the relationship. As that initial project comes to a close, companies often turn to their partners for larger, more complex projects only to find out their partner does not have the right resources to handle that next project.

    As a result, they are forced to restart their search and onboard a new partner. You can avoid this all together by ensuring your nearshore partner can successfully scale their teams and capabilities based on both your current and future needs. Doing your due diligence and verifying a partner’s track record and their ability to rapidly build teams can head off any growing pains. Can they double or triple the team’s size and hire a specific type of developer or engineer? If yes, where are these professionals coming from – in-house or via an outside agency? Does the team have exceptional qualifications and the right skills? How are your partner’s retention rates? It is important to understand how and where the resources will come from when you are ready to expand your relationship. You want companies that are built as nearshoring partners and who are able to scale as you scale.

    Nearshore partnerships are not a one-size-fits-all relationship. To be successful, organizations need to ensure their teams can work cohesively together. The benefits of proximity and time zone overlap, as well as cultural alignment, can ensure the partnership adds value. Collaboration and teamwork will be easier with a team whose culture is similar to yours. Partners who can meet that criteria, and who can demonstrate a similar set of work values, can help you reach your software development and digital transformation goals.

  • The DevOps Long Tail of Salesforce’s Slack Buy

    The DevOps Long Tail of Salesforce’s Slack Buy

    While most of the focus on the acquisition of Slack this week by Salesforce for $27.7 billion clearly revolves around digital business transformation initiatives, the implications of the deal for DevOps teams that have been employing Slack to collaborate for years is significant.

    Salesforce owns both Heroku and Force.com in addition to providing developers with a set of low-code Lightning tools for building applications on top of software-as-a-service (SaaS) applications built by Salesforce.

    During a conference call with analysts this week, Salesforce CEO Marc Benioff made it clear most of the initial focus will be on tightening integration between Slack and the company’s broad portfolio of customer relationship management, marketing, analytics and artificial intelligence software. However, Slack first gained traction as a collaboration service that DevOps teams employed to share updates and notifications. Many DevOps teams still employ Slack for that purpose and it’s only a matter of time before all the units that make up Salesforce tighten integration with Slack.

    It’s not clear to what degree that integration might convince DevOps teams to either stay with or switch to one of the several platform-as-a-service (PaaS) environments that Salesforce makes available. However, the Lightning PaaS that Salesforce provides for organizations that want to extend the company’s SaaS applications has been gaining significant traction. Rather than writing entire applications from the ground up, the path of least digital business transformation resistance for many organizations is to employ low-code tools such as Lightning to extend existing SaaS applications.

    Salesforce also own MuleSoft, which it positions as a platform for integrating both SaaS and on-premises applications to further those digital business transformation initiatives.

    That approach has gained significant traction in the last six months as organizations have expanded reliance on SaaS applications to enable employees to more easily work from home to help combat the COVID-19 pandemic. For its most recent third quarter, Salesforce posted revenues of $5.42 billion, an increase of 20% year-over-year. Benioff said the company is now lifting its future guidance to slightly exceed pre-pandemic levels. Salesforce is projecting fiscal 2021 revenue at the end of its fourth quarter will total $21.11 billion. Revenue guidance for fiscal 2022 has been raised to $25.5 billion.

    Most of the custom applications being built on top of Salesforce platforms are constructed by professional developers. That shift toward employing Salesforce SaaS applications as a platform has created demand for DevOps platforms from providers such as Copado and Gearset. Most recently, Gearset has begun offering free training to encourage the adoption of best DevOps practices among developers of applications based on the Salesforce platform.

    Benioff said the first fruits of the acquisition of Slack will manifest themselves next year. In the meantime, DevOps teams that have standardized on Slack for collaboration should expect to be hearing a lot more about Salesforce tools and platforms on a Slack channel near them.

    Of course, none of this is lost on Microsoft, which is similarly moving to incorporate Microsoft Teams within DevOps workflows. It will be up to each individual DevOps team to decide which approach to collaboration makes the most sense from here.

  • How to Foster Collaboration Between DevOps and Security

    How to Foster Collaboration Between DevOps and Security

    DevOps is on the rise. Back in 2018, MarketsandMarkets wrote that it expected the DevOps market to grow to $10.31 billion by 2023. That’s up from $2.90 billion in 2017, with a compound annual growth rate (CAGR) at 24.7% projected for the forecast period. Demand for DevOps solutions and services in response to the need for fast application delivery capabilities would likely help to drive this increase.

    Even so, security issues are introducing some challenges for organizations. A study conducted by the Enterprise Strategy Group and commissioned by Synopsys Inc. found that 48% of respondents had knowingly pushed out vulnerable code into production due to time pressures. Patrick Carey, product marketing director for the Synopsys Software Integrity Group, noted that about half of those respondents had done so “because the vulnerabilities identified were discovered too late in the [development] cycle to resolve them in time.” Such weaknesses elevate the risk of a data breach, and they potentially carry reputational costs for organizations that don’t plug those gaps before they release their products into production.

    These findings beg the question: Why are organizations struggling with their security efforts for DevOps? What’s not working for them?

    This blog post will explore these questions in terms of a cultural divide that exists between DevOps and security teams. After exploring where each team is coming from, this blog post will provide recommendations on how organizations can work to foster cooperation between their security personnel and DevOps teams.

    The Great Divide: Understanding the Issue

    The cultural divide alluded to above boils down to a false understanding of security and its impact on the development process. DevOps personnel are required to work within short development cycles to meet their employers’ evolving business needs. Subsequently, some organizations might interpret security as an opponent to their developers’ speed and respond by sacrificing security for the sake of speed. This decision enables misconfigurations, vulnerabilities and other security weaknesses to make their way into production.

    However, this interpretation overlooks an important reality: Many DevOps teams view security as a nuisance that gets in their way and slows down their work. Retroactive fixes ultimately take time and effort. In response, organizations might hold back on investing in the security of their DevOps processes, thus creating “technical debt” in the event that the work doesn’t get done.

    With that said, organizations have an incentive to rethink how they conceptualize security so that they can avoid these costs and keep their development processes running smoothly. But this raises an important question: How can organizations go about doing that?

    How to Balance DevOps and Security

    First, organizations should work to foster a culture of communication through which security personnel and DevOps team members can learn from one another. One solution to start with is having leaders from both teams “walking in the other team leader’s shoes,” thereby allowing them to share information and discuss their perspectives.

    Such communication will be effective only if personnel understand where the other side is coming from, however. That’s why organizations have an obligation to make their security policies and development workflows as understandable and implementable as possible. With this transparency, security and DevOps can begin to craft a way forward.

    Organizations can help out by encouraging both security teams and DevOps personnel to expand their knowledge. With respect to the former, security personnel have an interest in learning how to frame their message in the right language. It’s important to acknowledge that security teams can speak of potential security issues burdening projects with unexpected work and/or threatening operations’ availability with longer mean response times.

    Of course, security teams need to have a basic understanding of where developers and operations personnel are coming from. They can do this if organizations support them in learning about programming languages and how applications are developed. Subsequently, security personnel can use this knowledge to hold more credible discussions with their Devs and Ops counterparts as well as to properly configure their organizations’ Kubernetes.

    StackRox emphasizes the importance of administrators using automation to review their environments for possible misconfigurations:

    That’s because in a sprawling Kubernetes environment with several clusters spanning tens, hundreds, or even thousands of nodes, created by hundreds of different developers, manually checking the configurations is not feasible. And like all humans, developers can make mistakes – especially given that Kubernetes configuration options are complicated, security features are not enabled by default, and most of the community is learning how to effectively use components including Pod Security Policies and Security Context, Network Policies, RBAC, the API server, kubelet, and other Kubernetes controls.

    As far as DevOps personnel are concerned, training is key. Organizations should specifically consider training their DevOps teams in secure coding practices and educating their employees about attackers’ tactics. These individuals can then incorporate that knowledge into their coding practices and development processes. Additionally, organizations can uphold this security mindset among DevOps personnel by assigning security responsibilities to an individual on the DevOps team or to someone in a new position. They can then overlook security protocols among the DevOps personnel.

    Positive Focus Goes a Long Way

    The key to making security and DevOps teams work together is not taking their collaboration for granted. Like any relationship, organizations need to foster this cooperation by using positive focus and work to bring these two groups together. In that way, they can enjoy both the speed of DevOps as well as the security to stay safe against evolving digital threats.

  • Building (and Nurturing) a Product Team During a Pandemic

    Building (and Nurturing) a Product Team During a Pandemic

    Building a successful product team is difficult under the best of circumstances. Building one during a pandemic raises the level of difficulty by an order of magnitude. But it’s not impossible.

    In early 2020, everything changed. For months now we’ve been scrambling, adapting to a new normal that none of us had the foresight to plan contingencies for. We’ve moved from a world of in-person collaboration to one that relies heavily on technology to keep the proverbial wheels turning.

    The shift to an at-home workforce has brought with it the productivity you might expect when you strip away lengthy commutes and other inefficiencies. We’re left with an operation that’s run lean, on the back of technological solutions that push deliverables out the door in a matter of weeks, not months.

    Traits of a Team That Can Weather the Storm

    Now that digital transformation is no longer optional, a digital-first product team isn’t either. These digital natives were nice to have before, but in a world driven by Zoom meetings, Slack and Google Docs, they’re essential. Entire operations, quite literally, could fall apart without them. Without a doubt, a good product team starts with a good leader, and that leader these days needs a firm grasp on the tech challenges faced by their teams and the solutions that keep every part of the business moving in times of uncertainty.

    But it’s not just technology. The DNA of the perfect product person starts with curiosity, an ability to poke and prod and find inefficiencies by asking the right questions and always seeking a better solution.

    They should also have a growth mindset. An effective product person is always pushing the limits. It’s this ambition, this desire to keep moving forward regardless of the current situation, that often moves an entire team to keep up or risk getting left behind.

    They aren’t followers. The ideal product person is willing to argue against a decision that the rest of the room agrees with. They stand their ground and explain their thinking in a way that’s productive and respectful. They might not be the typical extrovert, the person always willing to step up and lead, but when they speak up, their words have purpose. These types don’t follow orders blindly; they question them, looking not only at the task but also the desired outcome, in an effort to find a better way. “Because we’ve always done it that way” falls on deaf ears, as these types understand that what brings you success rarely keeps you on top without the ability to adapt and evolve.

    The Collective Consciousness Inherent to a Product Team

    It’s important to zoom out and remember that a great product team is about more than a group of individuals. When done right, it’s a collective that moves as one. Individual achievements become all but meaningless and the focus is always on the team.

    This really boils down to culture. While a product leader chooses the shared beliefs, ideas, attitudes and knowledge that make up the team’s identity and work ethic, it is only the team that can internalize this collective consciousness and make the desired culture a reality. This is why one person can so easily make or break a team, so ensuring a good culture fit becomes the gel that holds the entire thing together.

    For the most part, product teams need individuals that are team-oriented, individuals that care about propelling the team forward rather than just achieving individual goals. Understanding is everything, and an empathetic individual understands not only their own struggles but the challenges faced by those around them. The importance of these individuals cannot be overstated, not only for the culture of the team but that of the company as well.

    Last, but not least, we look for people who make good decisions. This doesn’t mean they always make the correct decision. They are human, after all, but they are decisive in their decision-making and willing to take responsibility for decisions that go wrong. We don’t typically see the results of these decisions right away. Often, they play out several months, or even years, down the line. But we have to know that the person making these decisions is capable of weighing all the options, seeing all the angles and being decisive when called upon. This is particularly true at the senior level, the driving force of the team’s decision-making capabilities.

    Culture starts from within, and though teams are of the utmost importance, they are composed of individuals. If we were to build a product team in 2020, in the midst of a pandemic, we could do worse than identifying these characteristics in each member. One individual could propel the team to new heights or serve as a speed bump on the road to success.

  • How to Solve 3 Significant Development Challenges

    How to Solve 3 Significant Development Challenges

    As products, systems, and software grow in complexity, so does the development process. This can lead to an increased risk of flaws and can result in expensive and potentially reputation-harming mistakes or recalls.

    These new complexities have shifted the product development process entirely, requiring optimization from end to end. Engineering and design teams need solutions that answer the most common challenges they face in this process. This means being provided purposeful, structured collaboration tools; connecting distributed team members; and accurately capturing and facilitating feedback, decision-making and context for requirements under review.

    Navigating Development Challenges

    To do this, teams developing complex products, systems and software must first overcome some significant obstacles. To help navigate this journey, let’s examine some of the most prominent product development challenges engineers are facing today.

    Outdated Legacy or Document-based Solutions

    The traditional approach to managing risks and requirements is highly manual, operating in an old mindset in which numerous spreadsheets and versioned documents are shared via email. This method has serious drawbacks, including no guarantee that data is up to date. This results in valuable time lost deciphering different versions or painstakingly making changes manually to achieve cross-team alignment.

    Additionally, without a clear path of traceability—which can be difficult to achieve for those who rely on static documents—teams often end up referencing older and often outdated versions of requirements. This inevitably leads to misalignment, increased risk and costly rework.

    The solution? Uplevel your traceability practices. Moving on from outdated legacy solutions to a modern requirements management tool is the first step to bolstering creativity, productivity and collaboration.

    Compliance, regulations and standards processes 

    Product, systems and software development has become much more complicated over time. As a result, so has product risk and the accompanying regulatory compliance required.

    To ensure the long-term success of organizations developing these complex systems, software and products, strong collaboration between teams, knowledge of applicable regulations and effective requirements management platforms are necessities. These tools provide a simple path and single source of truth for defining, verifying and validating key regulations. However, despite numerous industry studies indicating that requirements issues are a prominent factor of project distress, not everyone is convinced their team needs to focus on requirements development and management. Further, they’re unsure of how it will all pay off.

    To address these challenges, companies need to streamline their quality and risk management strategies. This can be done by incorporating detailed traceability across the development life cycle—from the high-level user needs and systems requirements through to validation and verification.

    Effective Review Cycles

    Review cycles are often time-consuming and fragmented. For example, when approaching requirements management manually and with disparate documents, a cycle can be repeatedly delayed due to versioning issues and lack of a single source of truth updated in real-time. It also reduces team visibility throughout the review process; individuals end up spending hours per week in review meetings just to ensure everyone is on the same page.

    To up-level this process, it’s necessary to have:

    • One source of truth for requirements and tests.
    • A straightforward way to send items such as requirements, user stories or test cases for review.
    • Best practices for each major role involved clearly outlined (i.e., reviewer, approver, moderator).
    • Real-time collaboration within a shared, dynamic requirements management platform.
    • An outline of a formal approval process to capture and record sign-off.

    Collaboration is Key to Development Success

    At the end of the day, collaboration is at the core of all product development work. The ability to effectively work together is critical to ensure innovation doesn’t stop. In this era of rapidly accelerating change, structured and strategic team collaboration is the means for improving the product development process for all involved. By updating your legacy traceability solutions, establishing effective review cycles, and streamlining your regulations, compliance and standards processes, your team will be well on its way to a much more effective and unified product development process.

  • Should Conway’s Law Be Applied to DevSecOps?

    Should Conway’s Law Be Applied to DevSecOps?

    Strictly adhering to Conway’s Law could lead to less innovation and the inability to keep up in a fast-changing market

    When it comes to determining how an organization should be structured, the 1967 Conway’s Law provides a plausible direction that many software companies could follow. However, in today’s ever-changing cloud environment, it is arguable whether it can be used in DevSecOps companies, a quickly growing organization structure. While Conway’s Law is helpful to consider, it should only be used as a guideline and not strictly followed because it can lead to less innovation and the inability to keep up with the fast-changing market.

    What is Conway’s Law?

    Conway’s Law is a term that originated from engineer Melvin Conway’s 1967 thesis paper to Harvard Business Review. In his submission, he wrote that “any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication methods.” Based on his observations in the engineering world, he believed that the success of a software is based on the organization’s company structure and communication style. As a result of this paper, software companies began to emphasize collaboration and teamwork and implemented it into the company’s work culture.

    How Can Conway’s Law Apply to the DevSecOps Field?

    Conway’s Law has many valid points. The law emphasizes the importance of a company’s structure and the necessary balance of business and design to ensure a viable product, as the quality of a product “comes from within.” However, there is no right way to organize a company, and it should be structured in a way that makes the most sense for an evolving, cloud-based product.

    In the DevSecOps field, many solutions are run by enterprises that are cloud-based. This means that all the data and networks are stored in remote servers, making it easier for companies to constantly develop new technology and improve existing products. This new norm is redefining the way companies are structured today, and traditional standards cannot be followed. If a company strictly follows Conway’s Law, it will be difficult for them to innovate.

    Here are a couple of takeaways from Conway’s Law that can benefit DevSecOps companies:

    Small Teams With Equal Representation

    Conway’s Law explains that the bigger the team, the higher likelihood of miscommunication and tension, causing unproductivity. Many tech companies, such as Microsoft and Amazon, structure their employees in small teams (around 10-15 members) to oversee and specialize in a specific aspect in the company’s product, but aim to achieve the same business goal. This type of structure allows more leeway to experiment different ideas and quicker response time to fast-changing needs.

    Collaboration is Key

    Some argue that following Conway’s Law may decrease the company’s overall cooperation and lead to small team allegiance. While there is a fine line between small work groups and department cliques, collaboration needs to be a core concept embedded in the company’s organization.

    If the organization’s culture is based on companywide collaboration, it will solve these problems, as collaborative processes and platforms prevent cliques from forming and allow teams to be independent, creative and agile. For example, for security teams to successfully collaborate with DevOps teams, they need to intentionally create solutions that can be embedded with existing DevOps pipelines.

    Conclusion

    While Conway’s Law is an important social contribution to organization principles, it should only be used as a rough guideline because following it too closely can stymie innovation in a fast-changing cloud environment. Conway’s Law highlights the importance of company structure and implies that a successful organization is structured with small teams focusing on one sector of the company, and with consistent collaboration established throughout the company to systematize unification and togetherness.

    As organizations compete for the greatest slice of pie, it is critical for leaders to look inward and ensure internal structures and processes are setting their products up for success.