devopsy.kinsta.cloud

Tag: project management

  • The Strategic Product Backlog: Lead, Follow, Watch and Explore

    The Strategic Product Backlog: Lead, Follow, Watch and Explore

    The economic outlook for 2023 suggests many organizations will be leading through a period of resource scarcity as IT budgets are scrutinized and organizational priorities are re-evaluated. For the product manager, smaller budgets and fewer resources place even greater emphasis on ensuring alignment between enterprise priorities and the product backlog.

    Many tools are available to help product managers prioritize individual work items at a tactical level for DevOps teams. These models generally seek to quantify some combination of internal stakeholder value and level-of-effort required for developers and DevOps teams to complete. Higher-value lower-effort items rise to the top.

    Other strategic factors are just as important in the prioritization process, particularly for products living within a larger enterprise product portfolio and competing for scarce resources. For these, a product manager must understand why a given work item or capability should be given priority and how it should be pursued. This involves asking questions such as: On what basis should an item come into the product consideration set? How much should DevOps and developers seek to innovate in delivering a specific capability or feature? What is the product and the portfolio-level opportunity cost of pursuing a given piece of work?

    A strategic model for backlog evaluation helps to set expectations with DevOps, developers and other internal stakeholders and ensure customer needs are front and center in prioritization decisions. It establishes a common language for collaboration. Two dimensions should emerge in evaluating capabilities at higher product and portfolio levels: Capability alignment to business-level strategy and the potential for a capability or feature to not just satisfy but captivate customers with a novel or compelling experience.

    The intersection of business strategy and customer experience factors can serve as a useful model for a product manager to think strategically about their backlog. The model helps to inform not only the question ‘Should we do this?’ but also ‘How should we proceed?’ and make things clearer for DevOps teams.

    Lead

    Items in this quadrant are the unicorns of the backlog and have the greatest potential to both strategically differentiate a product or enterprise and captivate customers. Product focus in this quadrant should be to invest in innovative, industry-leading approaches to satisfying customer needs in a manner that is consistent with business strategy and unique selling proposition. These items should receive the highest strategic priority on the product backlog.

    Follow

    Potential work items in this quadrant have a high potential to delight customers if handled well and irritate them if not. However, these elements are unlikely to be competitively differentiating given the current business strategy. Product focus in this quadrant should be to continually assess competitor treatment of these elements and adopt proven best-in-class experiences within the industry and adjacent industries. The product should focus moderate priority on competitive intelligence for elements in this quadrant and follow existing competitor approaches that enhance the customer experience.

    Watch

    Items in this quadrant are generally not problematic for customers. They are unlikely to differentiate the product or enterprise from competitors given the current business strategy and should be given low priority. The product should monitor proposed solutions in this quadrant to ensure no unnecessary customer effort is being introduced by other backlog items.

    Explore

    Product functionality in this quadrant is either not problematic for the customer experience or represents capabilities that are still emerging in the marketplace. These elements have a likelihood of developing into competitive levers, provided they can be developed in a manner that enhances the customer end-to-end journey. The product should place a high priority on product discovery for elements in this quadrant. It should explore capability innovation through design thinking or similar customer-centered ideation approaches.

    Mapping a product backlog to these four quadrants is as much art as science. It requires a deep understanding of business strategy, intended outcomes and customer needs. As with any strategic model, its value comes from the quality of discussions it produces and its role in surfacing implicit assumptions from the product’s stakeholder group, including DevOps teams and developers. Whatever model is used, having a mechanism to drive strategic product discussions is a critical tool in the product management toolbox and an important step to product management maturity.      

  • Atlassian Extends Automation Framework’s Reach

    Atlassian Extends Automation Framework’s Reach

    Atlassian this week extended its namesake automation framework to include its Confluence collaboration software. In addition, it’s now possible to automatically create bi-directional branches in Bitbucket, GitHub or GitLab platforms from within the company’s Jira project management application.

    At the same time, it’s now possible to automatically generate feature flags from within Jira through integration with the feature management platform created by LaunchDarkly and automate alert and incident responses stemming from the Amazon Web Services (AWS) cloud.

    Dilani Kahawala, head of product for the automation platform at Atlassian, said these extensions to the Atlassian Automation framework are part of a larger ongoing effort to remove the silos within software engineering teams and the rest of the business.

    DevOps teams, for example, will now be able to expand the number of those automated actions being taken because change requests can be automatically created. Atlassian estimated that IT teams will spend 25% less time managing change requests and save 115 hours per month.

    To save more time, templates that automatically create Wiki pages in Confluence can be spun up at the completion of every sprint.

    Since it first launched for Jira in 2020, Atlassian claims more than 10 billion automated actions have been executed across the Atlassian platform.

    Kahawala said as more organizations realize how dependent they are on software to drive revenue, the need to close the divide between software engineering teams becomes much more pressing. She noted that changes to the timetable for one project can have a cascading effect across the entire business. At a time when organizations are counting on digital business transformation initiatives to remain competitive, the speed at which organizations share updates across silos is critical, said Kahawala.

    At the same time, organizations are also striving to become more productive in an uncertain global economy. Automating rote tasks makes it possible for development teams to spend more time writing code, added Kahawala.

    Less clear right now is whether businesses can absorb the pace of change that is enabled by modern software development. Historically, business leaders complained that their dependency on IT was holding the business back because it took too long for IT teams to implement changes. Today, however, many organizations routinely deliver code updates to mission-critical applications daily. While not every delivery may involve a major new update, it’s apparent that the pace of innovation is now occurring at speeds many organizations find challenging to absorb.

    As organizations continue to adopt best DevOps practices, the pace of innovation is only going to accelerate further. The challenge—and the opportunity—is to ruthlessly eliminate as many manual tasks as possible to accelerate the pace of innovation. After all, software engineering pros have better ways to spend their time than manually creating yet another branch in a continuous integration/continuous delivery (CI/CD) platform or, worse yet, reenter data into a project management application.

    Join the makers of Jira for a brand-new (free) Agile & DevOps event. Atlassian Presents: Unleash is designed to help your team collaborate from discovery to delivery to running great software. Get first access and “cheat codes” to the newest Jira Software features and products from Atlassian; network with peers, industry experts, and Atlassian product leaders; and solve real-life challenges around your Jira and toolchain configuration and workflow. Live in Berlin or digitally on February 9. Register for free.

  • GitLab Strengthens Remote DevOps Management

    GitLab Strengthens Remote DevOps Management

    GitLab this week moved to provide remote developers with access to a more secure continuous integration/continuous delivery (CI/CD) platform while at the same time adding a dashboard that makes it simpler to track the overall status of application development projects.

    David DeSanto, chief product officer for GitLab, said GitLab Remote Development takes advantage of an instance of the GitLab CI/CD platform running on a Kubernetes cluster. That cluster is accessed via a Web-based integrated development environment (IDE) to eliminate the need for developers to create development environments on their local desktops.

    That capability reduces developers’ time and effort on tasks other than code and gives organizations more centralized control over the intellectual property being created, noted DeSanto. Organizations will no longer have to worry, for example, about theft of a developer’s laptop that has sensitive data on it, he added. In addition, organizations will be able to more easily create “golden” images that can be consistently accessed by developers residing in multiple locations.

    In addition to making it easier to centrally manage a distributed team of developers, GitLab is also adding a GitLab Value Streams Dashboard that provides senior executives with access to metrics that assess the overall health of an application development project. While GitLab has always provided metrics to DevOps teams, DeSanto said this dashboard, available as a private beta, makes it possible to identify, for example, bottlenecks that might result in delayed delivery of an application.

    Value stream management (VSM) is, of course, not a new idea. The issue that DevOps teams are trying to come to terms with is whether they need to adopt a dedicated VSM platform. The other option is to simply provide a set of dashboards that enable senior IT and business executives to track projects’ progress without deciphering a set of much lower key performance indicators (KPIs). Previously, the GitLab platform surfaced a lot of nitty-gritty details that don’t provide the context senior executives required, noted DeSanto. The Value Streams Dashboard metric surfaces KPIs based on DevOps Readiness Assessments (DORA) metrics from Google alongside other flow metrics.

    These latest offerings are part of a larger case being made for an integrated DevOps platform that reduces the total cost of application development by eliminating the need for organizations to integrate various tools themselves. Each DevOps team can employ as many of the modules GitLab makes available as they need. Once invoked, they take advantage of the same data store as every other element of the GitLab platform. That capability is becoming more critical as organizations embrace platform engineering to reduce the cost of application development using DevOps best practices, said DeSanto.

    It’s not clear how much interest there is in replacing legacy CI/CD platforms that, in some instances, have been in place for nearly a decade. However, as the pace at which applications are being built and deployed continues to accelerate, there is no doubt that organizations of all sizes will need to modernize application development processes.

  • Three is the Magic Number: Planning and Executing a Successful DevOps Project

    Three is the Magic Number: Planning and Executing a Successful DevOps Project

    Diligent preparation, clearly defined workflows and watchful monitoring are key to delivering a high-performing DevOps project. DevOps is one of the hottest buzzwords in programming, but everyone seems to have their own ideas when it comes to structuring and deploying a DevOps team.

    In basic terms, DevOps is the integration of developers and IT operations workers into a single group, with the goal of increasing the speed and quality of software deployment. Its creation was a response to concerns over the segregation of teams, which led to communication breakdowns and a lack of cohesion.

    Since its inception, DevOps has grown in popularity, with 83% of IT decision-makers stating that they have implemented this style of working in some form.

    However, transitioning business focus in this way does not guarantee an immediate change in fortunes–this dynamic represents an IT culture shift, with increased emphasis placed on collaboration and interpersonal skills. For this model to yield returns, engineers should be open to new information, technology and ways of working.

    So, what vital steps must a DevOps team take to ensure the successful delivery of a project?

    Understanding the Needs of the Client

    The preliminary stages can make or break a DevOps project. If the team does not emerge with a vivid idea of what the client wants and how this can be delivered, the venture is doomed to failure.

    It is crucial that both the team and the client are willing to put the time in to understand each other’s goals, ensuring that their visions align for the steps to follow. This can be done through a series of meetings and workshops, where objectives are identified and both establish a good comprehension of how the final product should look.

    If executed correctly, the DevOps team will exit the project’s first phase with a well-defined brief and a crystal-clear understanding of what the client wants to see delivered. When this step is rushed, engineers will be held back by a lack of direction, increasing the chances that the finished product will not reflect the client’s hopes.

    Configuring the Environment

    This next phase is where the developmental process of the app begins, which is usually facilitated using a cloud-based solution. The team begins by preparing the environment’s aesthetic, working out the components it should contain and exploring how they should be configured to maximize efficiency.

    It is during this period that cybersecurity measures are added so that the final version of the app is as close to impenetrable as possible. This shows why a DevOps team needs a diverse range of skill sets: Cybersecurity experts are few and far between, but there should be at least one member of the group whose knowledge can be called upon to ensure protective measures are properly implemented.

    A successful developmental phase is underpinned by clearly structured workflows, with the project mapped out step by step and everyone involved understanding where they fit into the plan and how they can contribute.

    However, a DevOps project is rarely smooth sailing from start to finish–development is often disrupted by missed deadlines, bugs and conflicting duties pulling engineers away from their stations. For this reason, agile and multi-skilled team members, who can ably jump in and assist in various areas, are extremely important for ensuring continuity when workflows are derailed.

    Avoid Failing at the Final Stages of the Project

    Just because the development of a product is complete and the app is live, this does not mean it is time for the DevOps team to rest on their laurels and move on to the next project. It is essential that they continue to monitor the app in its early stages so that any bugs can be identified and immediately fixed.

    Engineers should be in place to see how much the environment is burdened and how it responds depending on the rate and number of new users. Any data obtained is a precious commodity and should be treated as such, with teams ordering and labeling results as soon as they are collected.

    Once the baseline data has been gathered, results can be analyzed to pinpoint which parts of the app may need recalibrating. After making these improvements, the final result should be a product performing at an optimal level while also meeting the client’s specifications.

    Don’t Rush the Project’s Process

    At the conclusion of all three phases, DevOps teams should have absolute confidence that the project is headed in the right direction and that they are fully equipped to execute the next procedural steps.

    A well-designed app is far easier to produce when a team is made up of specialists from an array of fields eager to collaborate and communicate with one another. Assembling the right personnel will aid the smooth transition between the stages of a DevOps project.

  • Atlassian Extends Jira’s Reach Into DevOps Workflows

    Atlassian Extends Jira’s Reach Into DevOps Workflows

    Atlassian today added a range of capabilities to its Jira project management application that make it easier to manage software development projects, including a toolchain page that simplifies tool discovery for any given project.

    In addition, Atlassian is including a Discover tab on that page that makes it possible to track activities and set priorities by providing more context around the goals for any given project.

    Atlassian said it also plans to add scope change insights later this month and, in the first quarter of 2023, auto-detection of stuck issues will be added to an existing ability to predict when application development projects will be completed.

    The company has also added a pull request activities feed to the Code tab in Jira to make it easier to compare and contrast issues, identify anomalies and discover opportunities to move work forward along with a Code insights view for tracking branch, commit, pull request and deploy activities.

    The Releases tab in Jira now surfaces feature flag status alongside development, build and deployment statuses. There’s also an ability to automatically generate release notes in the Confluence wiki application provided by Atlassian. Finally, in 2023, Atlassian is committing to making available a dark mode option for running Jira that some DevOps teams prefer.

    Suzie Prince, head of product for DevOps at Atlassian, said all these Jira updates are extensions of an Open DevOps initiative the company launched earlier this year that integrated Jira with a wide range of DevOps tools. The goal is to make it simpler for DevOps teams to track project progress without necessarily having to deploy, for example, a separate analytics application. As part of that effort, Atlassian also revealed Jira has been integrated with Compass, an extensible catalog launched earlier this year for tracking software components and is available in beta.

    In effect, Atlassian is making a case for Jira to become a software development project tracking hub by automatically pulling data from various other DevOps tools. Rather than requiring a project manager to send multiple requests for updates to individual developers and manually enter data, Jira’s integrations with various tools can both pull relevant data and apply analytics in a way that makes it simpler to identify issues that are adversely impacting deadlines.

    Those insights can then be shared more easily with both development teams and other stakeholders in the business that have a vested interest in making sure project deadlines are met. It can also make it simpler for application development teams to justify the need for additional resources.

    Project management is, of course, one of those thankless tasks that doesn’t always get the appreciation it deserves. However, as it becomes easier to automatically collect data about the status of any given project, the task itself should become less intrusive. Hopefully, as those tasks become more automated, the friction that often exists between application development teams and project managers will also subside.

  • Allstacks Adds Alert Capability to VSM Platform

    Allstacks Adds Alert Capability to VSM Platform

    Allstacks has added an alert capability to its software-as-a-service (SaaS) value stream management platform that automatically notifies DevOps teams when software project goals and deadlines are likely to be missed.

    The core Allstacks platform employs machine learning algorithms and artificial intelligence (AI) models to keep track of pull requests, commits and card changes via a set of dashboards that are designed to be accessible to anyone in an organization.

    The Allstacks Alerts capability makes it possible to notify those stakeholders via email or Slack any time a specific indicator, such as a pull request, has been open for four days, which would suggest risks of delays have increased. Support for Microsoft Teams will be added early next year.

    Adam Dahlgren, senior vice president of product for Allstacks, said the goal is to leverage the advanced analytics built into the platform to surface thoughtful observability insights versus simply firing off a series of generic alerts that lack any context.

    Value stream management (VSM) platforms such as Allstacks automatically take technical metrics collected via DevOps tools and correlate them to key performance indicators (KPIs) defined by business leaders. The concept of value stream management traces its lineage back to lean manufacturing methods, which called for each step of a manufacturing process to be continuously measured. As software development has evolved from being a craft to a highly-automated process using DevOps best practices, an appreciation for the value of monitoring the impact of missed software development deadlines on the business has grown as organizations realize how dependent they are on software.

    In fact, many organizations are discovering there is a clear disconnect between their business goals and software development processes. Business leaders are especially anxious to understand how a software development project delay might impact future revenue projections at a time when economic conditions are the most uncertain they’ve been in recent memory.

    VSM platforms also make it possible to track KPIs spanning multiple software development projects; the hope is that doing so will make it easier to see where resources should be reassigned as various bottlenecks are encountered. In the long term, Allstacks is also working toward adding scenario planning tools to make it easier for IT and business leaders to model “what-if” scenarios, added Dahlgren.

    It’s not clear how much organizations are willing to invest in VSM platforms, but the need for them is becoming more acute. The challenge many organizations still face is making sure they have the tools in place to collect the appropriate technical metrics. A SaaS-based platform should make it simpler to achieve that goal and to apply algorithms to what can quickly become a large corpus of data.

    Of course, it’s still early days as far as the adoption of VSM platforms are concerned. But there’s no doubt the divide between application development teams and the rest of the business is continuing to narrow. Less clear is to what degree that increased visibility will lead to a higher degree of empathy between dev teams and the business.

  • Managing Technical Debt is a Balancing Act

    Managing Technical Debt is a Balancing Act

    Technical debt is a nightmare for product managers. It can slow down teams and inhibit response time for delivering quality products to market. Yet, there are times when technical debt can be beneficial; but turning it from a headache to a positive is a balancing act. 

    Nimble project managers and developers should strive to develop an equilibrium that balances creating, reducing and accepting technical debt. The good news is: That’s attainable.

    The Shape of Technical Debt

    It’s essential for PMs to understand how technical debt can arise so they can identify its characteristics and manage the amount to carry or avoid to the team’s advantage.

    Laying too much brick and mortar will take software features too long to develop. It risks their rollout arriving well past due dates. But fixating on speed threatens to underdeliver on functionality. Circumstances like these will diminish the ability to deliver powerful results over time.

    Similarly, ignoring the power of third-party solutions to slot in and satisfy customer needs and speed-to-market is outdated thinking. For example, software like embedded analytics can arrive off-the-shelf to complete an architecture task quickly and affordably while freeing up the team to address other challenges. Remaining agile with all options available to the team is critical.

    Overall, the project manager’s goal should be to identify the indicators of technical debt and hone their skills to address each type.

    Building Architecture

    When a team is tasked with delivering new features or functionality, building upon the existing structure to support the new capability is not unusual. Lack of foresight or diligent planning about what’s necessary to enable this function can be a critical oversight that leads to a void in need resolution, i.e., incurring debt requiring payment.

    Speed versus Quality

    Delivering at the speed of modern business often means facing time constraints that can impact the quality of work. Faced with such limitations, teams may take shortcuts. Ultimately, those shortcuts can lead to an increase in technical debt.

    Quantity versus Speed

    On the opposite end of the spectrum, eagerly attacking a project that requires significant lead time can result in overbuilding. This leads to a different form of technical debt. Longer projects can be affected by technological change—an evolution that makes some previously completed structures outdated. Debt takes the form of teams forced to return upstream to make necessary changes when they should instead remain downstream.

    Near-Sightedness

    Unlike the oversight or overbuilding described above, if the team fails to consider future needs and focuses only on current tasks alone, it risks creating debt that arises by starting from scratch. If teams don’t anticipate the next feature or prepare for future functionality while in development, they will likely pay for this near-sightedness down the road.  

    To Build or Buy

    Developers want to build. It’s what they do. But it’s not always in the organization’s best interests. When a team faces complicated requirements, is extended beyond its capabilities or is simply well outside its repertoire, debt can be avoided by looking toward existing platforms that fulfill its needs. In such instances, a third-party solution saves significant time and money. For example, an embedded analytics tool built with the latest technologies and deployed turnkey frees the development team to remain focused on its expertise and apply its talents there. Think: Does the team need to invent a new wheel, or does one already exist? While choosing the former risks taking on debt, selecting the latter holds the promise of reducing it.

    Manageable Debt

    Still, technical debt can be a benefit. 

    Consider this example: You want to roll out a platform that delivers to the customer and market, but it’s a ground-breaking product. You don’t yet know everything you want or need to know about how end users will engage with it and what they’ll ask it to do. In situations like these, it’s reasonable to get the functional framework of the software into the hands of the market so that you can absorb reams of feedback, return to the platform and then build out or fine-tune its features and functionality. Actions like these are wise. PMs haven’t mortgaged the farm for a bag of magic beans—they’ve taken on a reasonable amount of debt to fertilize team knowledge into a product that will ultimately deliver the most value.

    Recognizing technical debt and its approach, avoiding or accepting it accordingly and then managing it with deliberate efforts to pay it down within acceptable limits is where PMs want to be. If you invest in paying it down or seek and accept third-party solutions to avoid it altogether, you’ll maintain team focus and velocity on the projects they excel in. 

  • Clubhouse Becomes Shortcut to Transform Software Project Management

    Clubhouse Becomes Shortcut to Transform Software Project Management

    Shortcut, formerly known as Clubhouse Software, today announced that its project management software for software development teams has been expanded to include additional workflow capabilities.

    CEO Kurt Schrader said team-to-workflow functionality is being added to the software-as-a-service (SaaS) platform and will make it easier to share workflows across software development teams in a more standardized way.

    Organizations can standardize workflows across multiple teams while still giving each team the ability to customize workflows for their own unique processes. As work gets created and assigned, it automatically moves into a workflow without having to manually update processes.

    Shortcut is designed to make it simpler for development teams to collaborate in a way that maintains transparency with other teams working on projects that are part of the same larger initiative, said Schrader. It allows product managers, engineers and designers to plan, track and measure their work without friction as the organization continues to grow in size, he added.

    For example, Shortcut will surface what teams need to focus on as priorities and timetables change within a specific project in addition to allowing users to define sprints using start and end dates, and the tool then sends reminders so the team can reserve time to focus on specific projects.

    Shortcut will also integrate with continuous integration/continuous delivery (CI/CD) platforms via application programming interfaces (APIs) to enable the development of custom workflows that include, for example, integration with real-time conversations occurring via the Slack collaboration service.

    Most of the project management software DevOps teams employ today is too complex and intimidating for the average business executive. Rather than forcing business users to learn how to master these applications, a case can be made for a more intuitive set of project management tools for both software development teams and the product managers they ultimately serve.

    As more organizations realize how dependent they are on software to drive business processes, many of them are reviewing the tools they currently rely on to manage software development. The goal is to not only reduce friction and enable more transparency across teams but also to provide stakeholders outside of the development team with more visibility into the status of any given project.

    At the same time, organizations are simultaneously launching more software development projects that have many dependencies. Many of those initiatives are based on microservices that are being built in isolation from one another before being aggregated to create an application. The dependencies between those microservices require organizations to make sure they are developed and deployed in a way that doesn’t leave one software development team waiting on another to finish a project before they can complete their work.

    Shortcut

    Schrader said that humans, as a species, are bad at organization. Project management applications should make it simpler for companies to understand how projects are not only organized but also all the dependencies that exist between them.

    Regardless of how software development projects are managed the need for greater visibility is obvious to all. Less clear is the best way to go about achieving that given all the communications channels available.

  • High Priorities

    High Priorities

  • Atlassian Delivers on Forge App Dev Platform Promise

    Atlassian Delivers on Forge App Dev Platform Promise

    Atlassian this week made available a Forge platform for building applications that complements its existing portfolio.

    Mike Tria, head of platform engineering for Atlassian, said Forge is intended to provide an application development environment to both IT organizations and third-party partners. It provides developers with access to an integrated Atlassian DevOps toolchain to accelerate testing, deployment, debugging and to capture log data, added Tria. Forge also presents developers with a command line interface through which they can be onboarded to the Atlassian cloud where Forge runs to access documentation and application samples. It uses OAuth 2.0 to ensure applications deployed on the Atlassian cloud only access data they have permission to access.

    The overall goal is to provide developers with a more modern application development environment as an alternative to the application development platform the company previously made available.

    Once an application is built, developers can then publish their applications on the Atlassian Marketplace as free or commercial offerings. There are already more than 3,500 Forge apps that were created during a beta process that began late last year. Forge will soon be extended to the rest of the Atlassian portfolio, noted Tria.

    Forge is intended to complement an Open DevOps initiative launched earlier this month that tightens integration between the Jira project tracking and management tools provided by Atlassian and a wide range of other tools commonly employed by DevOps teams. The goal is to not only make it easier to correlate issues that are listed in Jira with artifacts found in various software platforms, but also to collect data from DevOps tools to automatically update Jira.

    That data will then be employed to inform key performance indicators (KPIs), based on graphs that Atlassian provides within Jira, to keep track of value streams. Rather than having to acquire a separate value stream management (VSM) platform to track software development progress, the insights needed to understand the impact of, for example, a delay to one project becomes a dividend of using Jira.

    Like most providers of software-as-a-service (SaaS) applications, Atlassian has been making available a platform for building applications on top of the same platform it employs to build its own applications. Atlassian claims there are more than 1,200 partners building applications in addition to internal IT that teams that have built custom extensions to its applications. Atlassian has already shown a proclivity for acquiring independent software vendors (ISVs) that build applications on its platform. As part of the overall Forge initiative, Tria said Atlassian will be working more closely to identify the white space that won’t be addressed by the Atlassian product roadmap at some future date.

    In the meantime, independent software vendors and internal IT teams will need to determine to what degree they will prefer to stand up their own application development environment versus opting to be dependent on Atlassian. In theory at least, applications built on Forge should be more tightly integrated with the rest of the Atlassian portfolio. The only potential downside is, of course, any potential conflict that might emerge with a provider of an application development platform that also happens to sell application software.