To help those teams gain insights into how products are advancing, Lucid Software is announcing enhancements to its visual collaboration platform that are designed to help elevate agile workflows by cultivating greater alignment, creating clarity and improving decision-making. 

“Visual collaboration is about seeing an entire workflow from the very beginning, enabling teams to align, make informed decisions and guide the initiative all the way to market delivery,” said Jessica Guistolise, an evangelist, Agile coach and consultant at Lucid. “Lucid excels at bringing all necessary information into one platform, supporting teams regardless of whether they follow Agile or simply need to iterate faster.”

Visuals, Guistolise said, are important for getting all stakeholders on the same page and improving the overall developer experience. “Prior to the pandemic, agile teams would gather in one room surrounded by visuals and sticky notes that displayed their work, vision, mission and tracked dependencies. Then, we all went home. Now where does all that information live?” Lucid, Guistolise explained, became a centralized hub for teams that have everything they need to do their work, day in and day out. 

Lucid’s latest release includes an emphasis on team-level coordination and program-level planning. On the team level, there are features for creating dedicated virtual team spaces for organizing such critical artifacts as charters, working agreements and more. Lucid’s platform replicates the benefits of physical team rooms and serves as a central hub for collaboration, where all needed documents are stored and can be shared. On the program level, real-time dependency mapping enables visualization and management of those dependencies directly from Jira and ADO. Other new features are structured big room planning templates to coordinate cross-functional work and the ability to sync project data between Lucid, Jira and ADO to have the most current information reflected across all platforms.

When it comes to team-level coordination, team spaces are customizable, allowing for a more personalized and engaging work experience. “When working with distributed teams, fostering a sense of team connection can be a challenge,” Guistolise said. “This brings some of that humanity and team experience. ‘What did you do this weekend? Can I see a picture of your dog?’ All of that can be done visually and it cultivates a shared understanding of one another, and not just of the work that we’re doing.” 

Speaking to how these features enhance the developer experience, Guistolise came to embrace agility because, she said, “when we bring humanity back into the workplace and elevate the overall team experience, we not only boost collaboration and efficiency but also foster connection that makes those moments more enjoyable.”

Customizable Agile templates are also available to help guide teams through daily standups, sprint planning retrospectives and other Agile events by offering integrated tools such as timers, laser pointers and the ability to import Jira issues. 

Lucid also offers a private mode to allow for anonymous contributions of ideas and feedback. Guistolise explained that private mode offers psychological safety “to allow for those voices who may not feel comfortable speaking up or even dissenting in a meeting.” Private mode, she added, still allows teams to surface that information anonymously, which means better decisions will be made in the long run. The release also includes new estimation capabilities for streamlining sprint planning using a poker-style approach, and those estimates can be synced with Jira or ADO to align planning and execution.

Further, two-way integrations with Jira and Azure DevOps mean that “no one has to take pictures of the sticky notes on the walls and then type it into a back-end system so there’s a record of what is going on,” she said. Instead, because of the integrations, everything moves automatically back and forth between systems, providing updated, real-time information upon which to make those business and development decisions.

These latest innovations from Lucid Software empower developer teams to have a more positive working experience by providing the tools they need to navigate the complexities of Agile workflows, from daily coordination to large-scale program planning. By enhancing both team-level and program-level collaboration, Lucid continues to lead the way in providing the most intelligent and comprehensive visual collaboration platform to support modern teams.

The post Accelerating innovation: How the Lucid visual collaboration suite boosts Agile team efficiency appeared first on SD Times.

But as with any product team, you have limited resources and the need to balance both business and engineering objectives. So many stakeholders inform your developer experience roadmap that it can be difficult to prioritize.

Yes, you need a roadmap 

The biggest thing that distinguishes platform engineering from the top-down platforms of tech days of yore? Nobody has to use it. 

When you’re building any developer experience tooling — whether it’s an internal developer platform or portal or just a directory or better documentation — you have to build something that your engineers actually want to use. Your platform strategy — sometimes called a developer experience or DevEx strategy — should make developer lives so much easier that they need a really good reason to go off that golden path. 

Platform engineering requires a Platform-as-a-Product mindset, packed with user-centric design, prototypes and demo days. Your colleagues become your customers.

You not only need an internal product roadmap, you need to actively publish it within your organization. This way not only are you making commitments to solve your developer-customer’s problems, you are closing that feedback loop, so your platform team knows early and often if you’re building something that they even want or need.

Know your stakeholders

Perhaps even more than when you are working with external users, a platform team, as stewards of the developer experience, is beholden to many stakeholders. 

As Sergiu Petean from Allianz Direct pointed out, a common anti-pattern for platform teams is only addressing the single stakeholder of the software engineer. The larger the enterprise, the more regulated your industry, the more stakeholders you have to consider from Day One. 

At the insurance giant, his team initially highlighted eight different stakeholders that all bring different demands:

• End users
• Quality
• Security 
• Software delivery 
• Data
• Sustainability
• Incident management
• Compliance 

Later they realized the platform has the capacity to interact with even more teams. 

Work to build a relationship with each of your technical and business stakeholders. Learn what part of the software development lifecycle matters most to them. And then bring them into your feedback loops that impact your platform engineering product roadmap.

Learn to prioritize

The more stakeholders you identify, the even more feature requests you’ll receive. Yet, according to research by DX, the average team focused on developer experience is a fraction of the whole engineering org. That can seem overwhelming, but a platform engineering strategy is all about centralizing and solving frustrations at scale.

How can you possibly balance so many conflicting demands? HashiCorp’s platform engineering lead Michael Galloway recommends looking to remove the pebble in their shoe.

The biggest points of friction will be an ongoing process, but, as he said, “A lot of times, engineers have been at a place for long enough where they’ve developed workarounds or become used to problems. It’s become a known experience. So we have to look at their workflow to see what the pebbles are and then remove them.”

Successful platform teams pair program with their customers regularly. It’s an effective way to build empathy.

Another thing to prioritize is asking: Is this affecting just one or two really vocal teams or is it something systemic across the organization? You’re never going to please everyone, but your job in platform engineering is to build solutions that about 80% of your developers would be happy to adopt. 

Go for the low-hanging fruit

Another way that platform engineering differs from the behemoth legacy platforms is that it’s not a giant one-off implementation. In fact, Team Topologies has the concept of Thinnest Viable Platform. You start with something small but sturdy that you can build your platform strategy on top of.

For most companies, the biggest time-waster is finding things. Your first TVP is often either a directory of who owns what or better documentation. 

But don’t trust that instinct — ask first. Running a developer productivity survey will let you know what the biggest frustrations are for your developers. Ask targeted questions, not open-ended ones. You can get started inquiring about the 25 drivers of developer productivity — which socio-technically range from incident response and on-call experience through to requirements gathering and realistic deadlines. 

Mix this with informal conversations and pair programming with your devs to uncover big and small problems that need solutions.

As startup advisor Lenny Rachitsky suggests, you can rate each idea from 1 to 5 across the X of how impactful it’ll be to solve a problem and Y of how much effort it’ll take. Just make sure anything that shows up on that “guesstimation graph” meets the requirement that it solves a problem for a majority of your developers — because a platform team should never work for just one dev team.

Don’t forget to value quick fixes to help ease some pain. Following the agile practice of “walking the board,” prioritize features closest to Done. This allows for early wins to foster platform advocates, which can go a long way to increase adoption. 

Be open to changes

As CTO of Carta Will Larson put it, “If something dire is happening at your company, then that’s the place to be engaged. Nothing else will matter if it doesn’t get addressed.” 

Your roadmap is just that, a map — there’s always more than one way to go. You need to be ready to deviate and change your priorities. This could be a global pandemic or an urgent vulnerability patch. It could be the need to adopt a new developer technology because it will help you work with a big-name integration partner. 

Especially in a well-regulated industry, your cybersecurity and compliance stakeholders can influence a lot of change. Just because platform engineering is opt-in, doesn’t mean it can’t facilitate some mandatory changes too.

No matter what the reason, it’s important that you communicate any fluctuations to your internal customers, explaining why the roadmap priorities have changed.

Continuously measure

Engineering is a science, so we know you can’t improve what you don’t measure. This “metrics-backed intuition” as Diogo Correia, developer experience product manager at Pipedrive, calls it, fosters continuous improvement, not just for your platform strategy but for your developers too.

His team uses DX for quarterly developer surveys. Then it developed and open sourced a one-hour developer experience workshop to help dev teams not only surface their own struggles but to set individual team focus areas for the next Q. 

“It has an immediate impact in terms of the sentiment and priorities that they report in the next quarter,” he said. For example, a lot of developers complain about technical debt, but almost no devs want to spend time fixing it. This knowledge has fed into Pipedrive’s rotation of teams focusing on paying down that debt versus releasing new features.

“The workshops help by identifying the concrete services or libraries that any given team owns that most developers in the team are feeling pain with,” Correia continued. This helps the team prioritize and plan to refactor, “instead of suffering through it for years on end, as before.”

In the end, the most important measurement of any developer experience strategy is if your internal dev customers are adopting and using it. Work to tighten that internal feedback loop to make sure you are building what they want. Only then will you achieve measurable, long-term success.

The post Prioritizing your developer experience roadmap appeared first on SD Times.

To transform with success and grow, collaboration is key. Collaboration not only accelerates the adoption and dissemination of new technologies, it also fosters the culture of innovation required where new, complex engineering solutions are needed to address unique problems. 

This culture-building was demonstrated at our recent Accelerate Conference where we brought together 400 of our top software engineers and Chief Information Officers for an intensive three-day collaboration in Kuala Lumpur, Malaysia for our ‘Accelerate Global Engineering Conference’. Our end goal is to leverage emerging technologies to address customer pain points; transforming the way data can be enabled enterprise-wide; and accelerating our engineering to simplify, standardize and digitize our processes to become fit for growth. 

Building on this momentum is critical in helping us become a client-focused, data-driven digital bank. Equally important is ensuring we have a diverse workforce engaged to contribute new ideas, innovation and creativity which can lead to greater productivity and business performance.

Creating a great engineering culture 

Building an engaged team should be a priority for every leader. Happy employees are productive, collaborative, and willing to work through challenges. Software engineers are no different and need the right tools, inspiration, and autonomy to deliver impact. 

First, many organizations still struggle to equip their software engineers with the right, up-to-date tools. In many instances, engineers are given the same computers as call center employees while senior managers get the latest and most powerful. At times broken processes are applied to the very cohort of experts that are charged with automating and eliminating them. Software engineers need more powerful CPUs for complex algorithm optimizations, or the additional RAM to host VMs locally, or the GPUs for machine learning, or access to production data to build models.

Upskilling and reskilling engineers should also be a priority to ensure they reap the benefits of new technologies like AI and Machine Learning with agility. At Standard Chartered, our Axess Academies help us ensure the skills of our software engineering workforce are continually upgraded and recalibrated to match the ever-changing demands of the market. For instance, we have over 130 classroom technology courses across the entire stack of technologies used in the bank, from full stack development to GenAI and Cloud Computing. New courses are added every quarter and existing ones are upgraded to reflect industry trends and changes.

Second, many organizations struggle to inspire their engineers primarily because the leaders in charge of this cohort generally do not ‘get’ software engineering. From top down as a bank, we believe that applying our technology in the right way is critical to accelerating our transformation. This enables us to standardize end-to-end, transform digitally while simplifying our business faster and permanently reducing structural costs.

Finally, autonomy is key for software engineers. Autonomy unshackles software engineering teams to ideate and deliver for the business on their terms while fostering a work culture that fulfills employee needs for meaning and personal growth. I would contend that digital disruption and Fintechs are not only about amassing more technology, or even newer technology, but about giving software engineers the space to deliver their agendas and being pivotal in delivering solutions.

With 3 trillion lines of code written every day and around 93 billion lines of code being added every year, and with things only set to increase, it is important software engineers play an instrumental role in the process of determining and shaping the development of new technologies, processes, and outcomes.

With over 10,000 software engineers, we continually build a bank that offers diverse experiences and opportunities for everyone to work on compelling and impactful projects. As our Accelerate Conference highlighted, we can do more to elevate our engineering community by increasing knowledge sharing, breaking down silos and raising the standards of technical excellence. By doing so, we empower the current, as well as the next, generation of software engineers with future-focused skills and experiences to be effective catalysts for digital transformation. 

You may also like…

Report: 7 qualities of highly effective teams

SD Times Open-Source Project of the Week: Developer Productivity and Happiness Framework

Q&A: How cognitive fatigue impacts developer productivity

The post Accelerating digital transformation means creating a great engineering culture appeared first on SD Times.

Those are certainly trendy topics. But based on the work I do on an everyday basis helping businesses plan and execute DevOps strategies, I’m noticing a different set of salient trends in the world of DevOps. Although much is being said about how technologies like AI might impact DevOps, the biggest changes I’m seeing right now involve other types of solutions and techniques.

Here’s a look at what I view as the three most important DevOps trends at present, as well as a breakdown of how they are poised to change DevOps tools and processes.

Trend 1: Policy-based management and IaC enable drive DevOps security innovation

Security has always been a priority for most DevOps practitioners. But right now, I’m seeing DevOps teams adopting new strategies in a bid to improve the security of the applications and environments they support.

One large-scale change is greater use of cloud-based policy management as a means of enforcing security best practices in cloud environments. Teams are configuring cloud services and resources using the code-based configuration frameworks that cloud providers support, then scanning the configurations to detect risks.

This approach makes it possible to enforce cloud governance consistently, centrally and automatically. Instead of simply writing governance policies and hoping that engineers remember to follow them when they are configuring cloud resources, businesses are increasingly building automated governance guardrails via policy-based management.

In a similar vein, more and more of the DevOps teams I work with are embracing static code analysis of Infrastructure-as-Code (IaC) templates as a means of detecting risks. As with policy-based management of cloud resources, an IaC-centric approach to infrastructure provisioning makes it possible not just to automate infrastructure management, but also to identify security risks earlier in the development lifecycle.

What’s more, some teams are making use of cloud policy and IaC code scanning as a way of warning each other about security policy changes that might cause an application or service to break. They do this by inserting configuration changes into their code using “audit” mode if their configuration framework supports it, or by simply configuring IaC scanners to flag changes if an audit feature is not available. This allows engineers to detect whether a change might cause a problem for an existing deployment.

This is important because within many organizations, the security team operates separately from application teams. When the two groups lack an efficient way of communicating with each other about changes, they may end up disrupting each other’s operations – an issue I like to call the “right hand/left hand” problem. Configuration scanning provides a systematic way of ensuring that each group is on the same page when it comes time to introduce changes – and the “audit” mode approach provides a grace period that allows time to react before a change actually takes effect.

Trend 2: Doubling down on DevOps automation with GitOps

Another overarching trend that is currently reshaping DevOps is the use of GitOps to make DevOps automation more efficient and consistent.

GitOps is the use of Git (or a similar source control system) to manage automated DevOps workflows. It involves defining configurations using code, then applying them through features like GitHub actions.

When you opt for GitOps, you move DevOps automation controls from individual workstations to centralized source control repositories. The result is the ability to track and manage all automated workflows via a central hub, which increases efficiency and mitigates issues like different engineers working with different versions of the same automation frameworks on their personal desktops.

In addition, GitOps automatically generates records of what has changed and how it has changed, since every action is logged through the source control system. This isn’t exactly documentation in the traditional sense, but it does mean that GitOps comprehensively documents every change – which is beneficial because human engineers tend not to be so thorough when it comes to documenting their actions.

To be sure, GitOps is not without its challenges. Implementing GitOps effectively requires additional skills – namely, expertise with both IaC frameworks and source control systems – that not all DevOps engineers possess. I also notice a tendency on the part of some teams to set up GitOps pipelines, but rely on manual approvals instead of automated actions to trigger changes – an approach that largely undercuts the value of automating pipelines in the first place.

However, these are challenges that teams can solve through education and by fully leaning into GitOps. In addition, techniques like automated testing of GitOps configuration code can help to build teams’ confidence in automations and reduce reliance on manual approvals.

Going forward, expect to see more and more adoption of GitOps techniques among teams seeking to level-up their approach to DevOps automation. Automating individual DevOps processes like software testing and deployment won’t be enough; truly efficient organizations will turn to GitOps as a way of automating their entire DevOps workflows, from end-to-end.

Trend 3: Investing in developer experience

Making software delivery processes more predictable and efficient is merely a step toward the ultimate goal of DevOps, which is to help developers become more productive and satisfied with their jobs.

To that end, I’m noticing a great deal of interest and investment right now in the realm of developer experience. This is playing out through two interrelated types of initiatives.

One is platform engineering, which involves creating DevOps teams who specialize in certain functions – such as network management or security – and designating them to support those functions throughout the organization. This approach reduces cognitive overhead for developers by freeing them from having to handle types of work that are not their main focus. In other words, instead of forcing developers to be DevOps generalists, platform engineering lets different teams focus on doing what they know and enjoy best – leading to greater productivity and higher levels of job satisfaction.

The other major trend currently playing out in the realm of developer experience is developer self-service. This means the ability of developers to obtain the technical solutions they need on-demand, without a complicated procurement process. In most cases, organizations enable self-service by implementing Internal Development Platforms, or IDPs, which host ready-made infrastructure resources and software environments that developers can deploy on a self-service basis.

There are risks inherent in these trends. They require specialized types of skills, and when poorly implemented, platform engineering and IDP solutions can create more problems than they solve. However, when you ensure that your teams have the requisite expertise, and when you deploy a carefully planned IDP that gives developers access to the resources they actually need, you’re likely to see a significant reduction in friction within your organization, and a boost in developer productivity and happiness.

Conclusion

Admittedly, discussing DevOps trends that center on security, automation and developer experience may not be as exciting as debating whether AI will take away DevOps engineers’ jobs. But if you want to know what’s actually changing in the world of DevOps – as opposed to which conversations are most hype-worthy – these are the places to look.

Security, automation and developer experience are also among the domains of DevOps where there is a great deal of opportunity at present to innovate – and, indeed, where adopting new tools and techniques will be critical for organizations that don’t want to be left behind as DevOps evolves.

The post Security, automation and developer experience: The top DevOps trends of 2024 appeared first on SD Times.

Further, the introduction of developer observability into code, the use of value streams to eliminate bottlenecks and gain efficiencies, and the development of AI code assistants all aim to achieve that same goal. 

Lots of approaches, but has there been much success? The idea of “shift left,” where testing, security and governance moved into the developer purview, actually created more burdens on developers, which actually slowed productivity. Any number of DevX tools came to market in 2023, but research showed that organizations were buckling under the weight of tool sprawl.

And developer platform engineering was seen by many as tying developers’ hands and locking them into a platform they might not prefer.

It seems, then, that the complexity of the problem of making developers more productive was equal to the complexity of actually creating the applications that drive today’s businesses.

But the effort wasn’t all for naught. On the contrary, many organizations were able to increase productivity through hiring strong leaders who understand the role of developers and how they like to work.

In interviews throughout the year, effective management was cited as one of the biggest factors in developer productivity. Chris Harrold, developer experience program director at simulation software company Ansys, told SD Times in an interview earlier this year that the number one hallmark of a high-functioning team is trust – trust that your team is pulling together in the same direction, and that each member has the others’ backs. “Uncertainty kills,” he said.

Also, developers want their work to have meaning, and they want to work on interesting projects. Sometimes, though, that is at odds with the goals of the organization. Good dev managers can help by spreading the less interesting but important work around the team. “Something that I tell all my developers is ‘Look, you’re not always going to work on the latest, greatest, most amazing things all the time. Sometimes you’re just gonna build a button for a website,’ ” Harrold said. Some companies, he said, allow certain hours during the week for developers to go off and work on open-source projects or other things that are interesting to them, as a way to keep them recharged and rejuvenated. “And then when they have to build that button for the website, they can say,’ Okay, well, I got my one hour fix of really interesting work. Now, let me do what I’m doing.’ “

Platform engineering

The concept of platform engineering became top of mind in 2023, as organizations worked to make it easier for developers to innovate without having to worry about creating the environments to build, test and deploy their applications.

Platform company Humanitec, which runs PlatformCon, this year produced volume 2 of its State of Platform Engineering report, which showed that internal developer platforms (IDFs) are being widely adopted. It included the first-ever platform engineering maturity model, best practices and reference architectures, and looked at AI and the future of platform engineering.

In an SD Times Analyst View piece in May, Jason English of analysis and advisory firm Intellyx explained, “The decision to create a platform is a commitment to help developers of varying skill levels abstract away the complexity of underlying cloud native architectures with interfaces and tools atop readily configured environments. A platform engineering approach must offer ease of use, elimination of toil, and reduced cognitive load for development teams—helping orgs attract and retain the best talent.”

Using metrics, and the McKinsey report

The widespread use of DORA metrics has created a kind of standard way to measure things like deployment frequency, change lead time, change failure rate and mean time to restore. Ori Keren, co-founder and CEO of engineering efficiency company LinearB, said those metrics are totally relevant to engineering, but there are misconceptions when those are all you look at.

Organizations, he said, need to look at the metrics that are important to the business as well. 

LinearB’s benchmark report this year added something called planning accuracy, which shows how much a company committed to was actually delivered. “If you can commit to something and hit your goals with 80% of the features, that’s elite,” he said. “Most companies are not in those areas.”

Connecting those DORA metrics to the business is critical to understanding if you’re being productive in the business sense. “I always like this analogy to a car and an engine, so the engine works perfectly fine. But you could be navigating this car in the wrong direction,” he explained. “So DORA metrics are the RPM, how the car is operating, but you still need to balance those with the business metrics to know that you’re moving in the right direction.”

In August, McKinsey issued a report titled, “Yes, you can measure developer productivity,” which spelled out metrics beyond DORA that attempt to align productivity, joy and business outcome. It was widely panned in the industry as being “naive” and “ignores the dynamics of high-performing software engineering teams,” according to an article written in response to the report by Gergely Orosz and Kent Beck on “The Pragmatic Engineer.”

Coding assistants

The year 2023 saw an explosion of generative AI solutions to assist developers in writing clean, secure code. Microsoft Copilot, delivered in February, and IBM’s watsonx, which launched in May, as well as a number of others emerged, but they came with a caveat. Since today’s applications are cobbled together largely through the use of third-party and open-source components, it’s important to safeguard the output against licensing violations or improper use of those components.

According to Chris Wright, CTO at Red Hat, the question of using open-source code to train an AI model needs to be addressed. Does the license approve that kind of use, or with open source, do the creators just want to opt out of allowing its use in models? And what about then having to turn your code back into the open-source community?

These questions, and more, will be explored more fully in the coming year.

The post Year in Review: Developer productivity appeared first on SD Times.

With developers getting lost in today’s decentralized, complex world of APIs, libraries, UI elements, frameworks and tools, Compass is designed to guide developers to their true north – delivering exciting new products that align with business goals and satisfy customers.

According to Taylor Pechacek, Atlassian’s head of product for Compass, developers need to navigate through this ocean of complexity to find the information and context they need around the work they’re doing, and to collaborate across the tech stack to make sure the software is kept in a healthy state.

So this, he said, is not just a technology problem, but very much a collaboration problem.

Pechacek explained that Compass improves the developer experience by creating a single, reliable and standardized place to capture all the context around the code. “There’s all these different software components out there, so an individual service is not just its code anymore. It has dashboards and observability. It has security issues coming in against it, it has compliance that the organization needs to stay on top of.” 

What they’re going to be able to do with Compass, he explained, is that they’re going to be able to empower developers to work autonomously. “They’re going to be able to increase overall engineering velocity by spotting those outliers. They’re going to be able to improve reliability, because developers and those teams understand how those pieces fit together.”

Pechacek noted there are four key default features in the Compass release. The first is a unified software component catalog to help users track all their services and relevant data and untangle their technical architecture all in one place. “Where is that run book?” Pechacek cited. “Which Slack channel do I actually contact? What is the latest deployment of this? Developers are going to be able to reduce time spent searching for this information, and they’re going to be able to get back into that flow state faster.” 

The catalog is being made available for free to Atlassian customers.

The second are health scorecards that help organizations track delivery and team health metrics to “identify points of friction for development teams and improve reliability for existing services,” Atlassian announced.

As Pechacek explained, “Once you have a consistent model of those components there, you can establish and evaluate the health of the company’s architecture and the team health. How do I keep all of my critical services secure?” The scorecards, he said, make it easy to monitor that progress. And if there are any regressions in the architecture health, such as having too many open security vulnerabilities, or incidents are eating up too much of your sprint, he added that “you can accelerate those feedback loops so that developers are not being interrupted by these apps coming across the business, and they’re able to get back to fulfilling more complex challenges for their team.” 

The third foundational component of Compass is templates. Pechacek explained that whether they’re creating a new service or a new library, developers often have to go through hours of configuration and library setup just to be able to write a piece of code. With the templates included in Compass, the organization can bake in best practices and enforce consistency. “So when a developer says, ‘Yeah, I need a new back end service to build my feature,’ that’s a one-click experience for them,” he said. “Essentially, they get all the infrastructure, they get their pipeline, they get the libraries that the company wants to give them, all the configuration settings and so forth. This is the happy path… and will help developers get started very quickly.”

The final piece is around extensibility, with Compass “being able to bring together information scattered across the organizations’ toolchain and ties it to relevant services and teams,” Atlassian wrote in its announcement blog. 

Compass allows development organizations to integrate across their existing tool chain, and to interact with that data. Pechacek notes that Atlassian’s APIs are free and accessible, and developers can collaborate with access to that information, coming from code, coming from CI/CD and observability, and take that information from Compass and put that back into other tools. “So now, my scorecards are part of my Jira Software sprint, to know how to prioritize technical debt versus innovation and new features,” he said.

Want to learn more about making developers more productive? Join us at Improve: Productivity, a one-day virtual event on Nov. 15. Learn more here.

The post Atlassian announces release of Compass DevX Platform appeared first on SD Times.