Jama Software® Partners with Sparx Systems To Strengthen Live Traceability™ Across Systems Development
Jama Software helps organizations manage requirements with Live Traceability™ through the systems development process for proven cycle time reduction and quality improvement. Sparx Systems is a leading integrated modeling and collaboration platform aimed at creating, sharing, and verifying models as a reference for building complex systems.
The seamless integration provides a real-time synchronous connection to the Enterprise Architect repositories. Users can work on the same model, at the same time, from anywhere in the world. Teams using a model-based systems engineering (MBSE) approach provide an integration with another best-of-breed tool while maintaining Live Traceability within Jama Connect®.
Live Traceability between Jama Connect and Enterprise Architect provides systems engineers, business analysts and software developers with real-time visibility between requirements and system models, enabling:
Instant access to view Jama Connect requirements and properties without leaving Enterprise Architect.
The ability to selectively create links between model elements and requirements
Seamless participation in the comment stream across tools
The creation of new model elements directly within Jama Connect
Bi-directional synchronization of changes
Simple and efficient setup and administration
This holistic approach will reduce the amount of iteration on requirements that take place in siloed tool environments as well as reduce the risk associated with manual efforts associated with tracing between disconnected tools.
“This first release of the Jama Connect integration for Enterprise Architect further cements Sparx’s commitment to integrate, harmonize, and work with industry-leading tools in the modeling and design space,” stated Geoffrey Sparks, CEO at Sparx Systems. “The Jama Connect Integration ensures the many modelers currently using our respective tool suites can share modeling and design info in a way that plays to the strength of each tool and seamlessly accelerates development. It has been a pleasure working with the Jama Software team and being able to bring this capability to our users and we look forward to future developments building upon this first release,” continued Sparks.
“The integration between Jama Connect and Enterprise Architect is a significant addition to Jama Connect’s best-of-breed ecosystem that is not only unique but essential for achieving Live Traceability across the systems development lifecycle,” stated Tom Tseki, Jama Software’s Chief Revenue Officer. “Jama Software’s ecosystem of connected best-of-breed tools continues to expand and the Requirements Traceability Alliance members are committed to interoperability across the entire system development toolchain.”
About Sparx Systems
Sparx Systems is a global software company specializing in high performance, visual modeling platforms for planning, designing, and constructing software-intensive systems. Sparx platforms are used by systems designers, corporate planners, business analysts, enterprise architects, standards developers, and software engineers. Sparx modeling software is widely used in finance, defense, government, aerospace, automotive engineering, geospatial, entertainment, health, smart grid, aviation, retail, and telecommunications. Sparx Systems’ flagship modeling platform, Enterprise Architect, provides robust support for team-wide collaboration and can scale up from single-user deployment to teams with hundreds of local and remote collaborators. With more than one million effective users globally and 80% of Fortune 100 firms owning licenses, Enterprise Architect is an essential platform for the most complex of projects. For more information, please visit the company website: https://sparxsystems.com
About Jama Software
Jama Software is focused on maximizing innovation success. Numerous firsts for humanity in fields such as fuel cells, electrification, space, autonomous vehicles, surgical robotics, and more all rely on Jama Connect® to minimize the risk of product failure, delays, cost overruns, compliance gaps, defects, and rework. Jama Connect uniquely creates Live Traceability™ through siloed development, test, and risk activities to provide end-to-end compliance, risk mitigation, and process improvement. Our rapidly growing customer base of more than 12.5 million users across 30 countries spans the automotive, medical device, life sciences, semiconductor, aerospace & defense, industrial manufacturing, financial services, and insurance industries. Visit us at jamasoftware.com
Click HERE to learn more about how Jama Connect can help you redefine and accelerate your systems engineering and development processes.
In this post, we recap a recent webinar hosted by Jama Software on the topic of integrating TestRail and Jama Connect
As the digital demands of the business continue to escalate, software delivery teams are under extraordinary pressure to deliver more work faster. Speed, however, counts for little if these teams are not delivering a high-quality product of value; rapid turnaround for a customer request is futile if the feature doesn’t work properly or meet their needs.
Fortunately, including quality assurance and test teams in the earliest phases of the software delivery lifecycle has never been easier; striking the right balance between speed and quality.
By seamlessly linking requirements to their test cases and test results, product managers and system engineers benefit from real-time visibility into test coverage and automated compliance reporting.
Join Jama Software’s VP of Product Management, Jeremy Johnson, and Tasktop Director of Partner Pre-Sales, Zoe Vickers, for a webinar demonstrating:
How linking requirements in Jama to tests that can integrate directly to or from TestRail enables transparency and cross-team alignment
How to correct inefficiencies and speed up time-to-market while enhancing product quality and employee satisfaction
Jeremy Johnson: I’m going to start by going through the agenda of topics that we have lined up for you today. Most of you are likely already familiar with Jama Connect’s ability to manage requirements, test and risk as part of your overall product development life cycle. So we’re going to start this discussion specifically around our perspective on integrations. We’ll have Zoe come in and talk about Tasktop Hub for Jama Connect and tell you a little bit about Tasktop as a company. Then we’ll move into test management challenges that we see when we discuss product development with our customers and prospective customers. And we’ll also touch on the benefits of integrating TestRail and Jama Connect. Zoe will then dive a little bit deeper into the integration flow and some of the benefits and show a live demo, connecting TestRail and Jama Connect. And then we’ll recap some key takeaways and get into some questions and answers at the end of the session.
So like I mentioned I’d like to start here with Jama software’s perspective on integrations. And the first point to touch on here is really the best practice around product development is to view integrations as a means to achieve live traceability across the systems development life cycle. Many if not most of you are familiar with the V model, you see a representation here. And you may not be with live traceability. So it’s really a component where different pieces of data that impact the product development life cycle need to evolve, need to be very dynamic throughout the process. Things like verification and validation need to happen much earlier in the process.
So maintaining this live traceability between all of these different product development components, different assets that might be involved, different products that might be involved is critical to optimizing your product development life cycle and processes. The real key here of course is that with this notion of live traceability in place, issues are reduced, and those that do arise are found earlier in the process. You can see here based on data from industry sources, these issues, finding these issues earlier in the can save 16 to as much as 110 times the cost of not finding them until later in the process.
Now I think everybody at this stage of evolution understands and agrees that this is the best practice. But really the challenge has been implementing this in the real world. So why is it that companies tend to struggle? And the reality is that most companies or probably nearly all companies don’t have an end-to-end system development process that covers all of these components. They tend to be broken up into silos, different toolsets, maybe even desktop tools and spreadsheets. Some of those things come into play. And all of those variability, all of that variability in the tool chain leads to potential issues. These areas with Xs on this representation of the V model. Those are potential areas where the traceability might be broken, and that results in significant manual effort, emails, meetings, all of those kinds of things, maybe a little bit of luck involved in trying to prevent delays and defects and rework and cost overruns that can come if those data points, that traceability is broken.
And Jama Software and Jama Connect as a product can certainly resolve some of these components in its inherent capability of tying risk and test information with requirements. But many companies have come to really accept this situation as unchangeable. If we don’t have a single platform to do all of this, then we inherently need to manage these things in silos and accept maybe desktop tools and spreadsheets or on some level part of the process. Then those are things that you’re simply not going to be able to control and manage. But a really a key to bringing this all together to achieving this live traceability is to sync these existing software tools, these best of breed tools.
Even in desktop tools and spreadsheets and things with requirements. So Jama Software is one of the companies that is really truly making this possible. So if we look at live traceability and an example of the connected data, the connected components within Jama Connect, you can see how easy it is to define elements, the relationships across tools, maybe even spreadsheets in this example. This happens to be from our medical device solution, but we have similar but tailored solutions for aerospace and defense automotive and semiconductor for industry industrial manufacturing, various different industries. These components are continually synced with best of breed tools. They’re applying their own specific engineering disciplines, and importantly linking that back to requirements and other vital components of the product development life cycle within Jama Connect.
So again you can see some of those connections in this diagram, very common for things like JIRA and Azure DevOps and downstream issue identification, task management, some of those things on the execution side. Zoe is going to touch a little bit on how JIRA comes into play in this scenario. We have test rail of course that Zoe will be talking about on the verification, the testing side. So those will come into play as we get deeper into this discussion. And one of the key ways that we help customers achieve this live traceability is with our strategic partnership with Tasktop. So to introduce you to Tasktop and some of their capabilities, I’ll now pass it over to Zoe.
Zoe Vickers: Thanks, Jeremy. I really appreciate it. Hi everyone. So what I just want to talk about as a whole is Tasktop has actually been a strategic partner of Jama’s for many years. And what this partnership really allows all of you Jama customers to do is you have the ability to integrate Jama with over 60 plus tools in the more agile DevOps testing ecosystem. The reason Jama decided to partner with us at Tasktop is because what we offer is an out of the box point and click configuration for setting up these integrations. What I mean by this is not a heavy services engagement. It is not something that each time you add a new project, you add new fields, you add new requirement types in JIRA that you might want to integrate with. Different tools like TestRail or JIRA. You don’t have to reach back out to Jama or Tasktop.
You are able to actually scale your integrations on your own. So that way you can build an enterprise wide solution within your own teams. One of the things that I want to show on the next slide is really the ability of what are all of the different connectors that Tasktop has. So I mentioned that we do allow you to integrate with over 60 different tools. Again, we actually have something called our integration test factory where internally at Tasktop we run over 500,000 tests a day, against every supported version of software that we have.
So again what we’re able to help, you do know we’ve helped many, many Jama customers do over the years is integrate drama with the fullest of tools on the right hand side. If you’re taking a quick look through that, they are out for the ties. Again, some of the most common ones that we are seeing specifically with Jama customers is we’re working with Azure DevOps, we’re working with JIRA, we’re working with TestRail, we’re working with Spark CA. And really the idea here is to bring in as much traceability across your different tool chains. So that way as you go back to some of those different traceability diagrams that Jeremy was talking about, you can see where all your [inaudible 00:12:05] teams are doing their work, and you actually have the visibility into the up-to-date status at any moment in time.
One of the big things that we talk about with Tasktop is why do you actually need an integration solution? There are some brilliant developers out there who can build a integration solution in-house. And a lot of times those integrations work beautifully, but what I’ve had many customers over the last few years talk with me about is that it’s hard to scale. And then it becomes a little bit more of a problem for them when it comes to error handling or troubleshooting. What we like to talk about at Tasktop is really to say first off integration solutions are needed, whether it’s through mergers or acquisitions or just growing teams as you go from large, medium, or small businesses. You have a lot of duplicate data entry that might be happening in a variety of tools.
Whether you’re communicating between your requirements tools, your agile teams, to your ITSM teams logging tickets. What task that’s going to help you do is actually eliminate a lot of that overhead and duplicate data entry, which then is going to help allow you to actually speed up your or delivery times and it’s also going to improve the communication between the teams, because they are able to collaborate across different tools without actually having to exit those applications. So one of the things that we’ll be able to even talk about today with Tasktop is you’re no longer going to have to walk across the office or send an email or extra Slack message. You can continue to comment back and forth in Jama, within TestRail, within JIRA. So that way your teams truly do have the end-to-end visibility of who’s working on what without having to log out of their tools of choice.
The main way that Tasktop actually does this is through something called model-based integration. So one of the big things that we like to talk about at Tasktop is there a value in just a simple point to point integration? Yes. This webinar today is talking specifically about Jama to TestRail. But we also need to be aware that none of you are going to operate in just the vacuum of those two tools. You probably have an entire ecosystem. 10, 15, 20 tools that your different teams are using. Tasktop is built to be an integration solution so you can scale across your entire organization. How we do this is that we are not actually a plugin to Jama or a plugin to TestRail. We are an independent third party solution that can be both on-prem or cloud hosted and how we actually offer this integration is through something we call model-based integration.
What a model is going to do is it is going to act as that universal translator to convert and normalize data between systems. What I mean by that is in that image on the right hand side you’re actually able to see for example I have a variety of different tools, this is an example customer we’ve worked with has. And specifically if we look at Jama they are doing a lot of their defect logging there. And as that relates back to their different requirements. So what I’m able to do is I’m able to take not only Jama, but also the specific work item that they’re working on. So there are different maybe bug or defect types with all the schema that makes up that specific item and map it into my specific model. From there, instead of just going over to TestRail, I could integrate that specific information with JIRA, with Azure DevOps, with a problem from ServiceNow.
And I’m also able to then take something like TestRail and map that into the model. So at any point in time when you want to add an additional tool or an additional work item, you want to actually bring integration and synchronization with your teams. You easily can map it to the model and reuse any half of any other integration to easily map it to. So an example of how this actually works is on this next slide imagine that you have your two different tools. So we have Jama test case on the left and we have a TestRail test case on the right. Then you have the model in the center. So think of your model as nothing more than a bucket of fields. Before you hopped on the webinar today, you probably decided, “Hey, I am interested in integration.” That means that probably on some little scratch piece of paper or an Excel document you have noticed and said, “Hey, I want to get information from this tool to this tool.”
The information I care about is something like a status or a priority or the assignee of this item. All that information goes into the model. Think of the model as Tasktop. From there I can easily map from Jama to the model, and you can see that we can have a one to one relationship between fields or a one to many. Then I can also map TestRail to the model. And as I do that, as we keep clicking through, you’re going to see these different boxes pop up, which shows a Jama collection and a TestRail collection. What that means is first off we look at the black lines. Tasktop is able to help route the data anywhere it needs to go to the correct fields, to the correct values via the model. From there, once we go into Tasktop later we’ll talk about how the architecture Tasktop works. Where in the previous side when I had shown you can map any tool to any other one half of an integration.
We see here that half of your integration is going to be called a Jama collection. That means we’re mapping from Jama to the model. And the other half of the integration is going to be from TestRail to the model and that’s your test rail collection. The reason this matters to you is that the second question I get from a lot of customers is, “Well, do we have to have all these fields equal? Does the schema in both tools need to match?” And the answer is no. You guys can start your integration with baby steps. You’re going to very easily be able to say, “This is this state of my Jama, this is the state of my TestRail. Let’s just start flowing information.” Then from there you can determine to scale.
One of the best parts of my role at Jama Software® is working with firms and people with different sizes and products, and services. I enjoy learning about their goals and challenges. I really enjoy geeking out and digging into processes and associated tools to identify areas for improvement. One question I get asked often is something like “I have PLM, why do I need Jama Connect?”
It is a fair question, so let’s dig in.
It may be helpful to define Product Lifecycle Management. Instead of using the definitions from the major PLM players (Aras, Siemens, PTC, Dassault) I am using a couple of internet sources – because the internet is always right. Wikipedia and Investopedia define PLM respectively as:
The process of managing the entire lifecycle of a product from its inception through the engineering, design, and manufacture, as well as the service and disposal of manufactured products. PLM integrates people, data, processes and business systems and provides a product information backbone for companies and their extended enterprise. Ref Wikipedia
The handling of a good as it moves through the typical stages of its product life: development and introduction, growth, maturity/stability, and decline.RefInvestopedia
Seems solid. But notice it does not say anything about a PLM tool. That is because PLM is a collection of processes first and THEN software tools enable and operationalize those processes. Everyone gets hung up on the tool which is a mistake. Build a solid process and then assemble the best of breed tools to compliment your processes.
Let’s illustrate this with an example. As I write this looking out the window I realize I need to mow my lawn tonight. The process of mowing the lawn is really broken down into lower level processes that I can choose the best tools for me to perform the needed processes. Since I’m a bit of a geek I had to make a chart to illustrate this.
Each low-level process can be accomplished with a number of tools. I highlighted the options I use in red. For my needs these are best of breed. I care about speed and general cleanliness, so I use a riding mower and a backpack blower and I mow once per week. If I wanted a golf course quality lawn I’d mow three times per week and use the old school rotary mowers as seen at the golf course. The bottom line is that you pick the tools that best accomplish your processes and their goals.
Single Source of Truth
By assembling the best of breed tools, you are able to ensure your team is able to operate in the manner YOU need to. But what about my data, you may ask. I don’t want to have data in three different systems. Absolutely correct. You want a single source of truth!
Lionel Grealou, a Digital Transformation evangelist that I follow discussed this topic in his blog, noting that “SSoT is often mistaken for a single database or repository for all data; rather it implies an intelligent enterprise data model constructed for optimum data integration and control across multiple sources, avoiding duplication and redundancy.”
That is an important distinction. We are advocating for a single SOURCE of truth as opposed to a single database of truth. This means that there is a single master of a given set of data. Using modern software platforms that have robust AND OPEN APIs (or through integration hub providers) it is a straightforward task to connect different platforms (and their databases) into your PLM process.
Taking this approach ensures that data is authored and managed in a single location and shared to all those that need it. Users do not need to know where it came from they just know it gets to the right person, at the right time, in the right format.
Forming a Digital Thread
Let us unpack that a bit further. Using my lawn mowing example, if I have a requirement to mow my land in one hour. Those requirements may decompose into the width of my mower (50”) and the horsepower of the motor (22 HP). Those requirements can be passed to the systems engineering and mechanical design teams for their design tasks. The 50” geometric requirement will directly feed the mechanical design. The horsepower requirement will drive the system design and may result in reusing an engine or designing a new one. Again, I made a rudimentary illustration that I think explains itself.
The takeaway here is that we can connect our people and processes. When we do, we support their needs by allowing them to utilize the tools that best fit their needs. This should yield efficiencies and positively impact the form’s bottom line.
As a note – I would be remiss if I did not note that I realize that I have glossed over the specifics of data models, storage, and APIs in play here. They are important, however, for the purposes of this discussion they are not necessary.
Best in Breed for the Win
Returning back to our question. In response, I’ll typically ask what PLM system they are referring to. I’ll also follow up with how they are using it – most PLM users only use their PLM systems for PDM. Next, I’ll need to understand if they have licenses to the PLM systems requirements package (if there is one), if they have the capability to customize the system, etc. Some PLM systems have bolt on RM applications that still need to be connected to integrate data. The answer is often a blank stare followed by a complaint about their PLM system.
Ok. So forget trying to shoehorn requirements management and systems engineering into your old PLM system. Why not take the modern approach and utilize a model-based SaaS platform like Jama Connect for your systems engineering and pass the data to your PLM system?
The PLM paradigm is shifting from central to decentralized. The paradigm of connected digital services is also a departure from isolated SQL-based architectures running in a single company. The data is connected, web services keep all the history and provide access to a distributed version of truth. Such modern architecture is also continuously updated, which makes the problem of system upgrades a thing in the past and irrelevant as everyone is running on the same version of the same software. Furthermore, the cost of systems can be optimized and SaaS systems can serve small and medium-size companies with the same efficiency as large ones.
Hmmm… Accessible data with optimized web services with configuration management and cost efficiency. Sounds like a winner to me!
Yes, Jama Connect is Compatible with Your PLM
Putting all of this together is a matter of making the connections I suggested in the data flow image above. In my simplistic example, we could use REST API capability and federation to ensure a SSOT. Jama Connect data (requirements, system architecture, etc.) would be stored in Aras Innovator as federated data to be usable by the detailed design, mfg, and quality teams – yet not be editable since it is owned by Jama Connect. The test data (i.e. data files) would the reverse, federated back to Jama Connect to support the validation and testing processes but owned by Aras.
Obviously, this is a simple example. There are details in play like how much you have customized your environment, but the basic idea remains the same: Use best in class platforms and connect the data to those that need it.
If you would enjoy talking further, please drop me a line and we can get together, I’m always happy to talk shop! dewing@jamasoftware.com.
Within Jama, we pride ourselves on “drinking our own champagne” — using Jama to build Jama. It’s a rare occurrence in software development that you get to design and build the very product that is core to how you work, one that makes your everyday tasks more pleasurable. Our product development organization uses Jama to manage our requirements, capture product and design decisions, and flesh out product ideas and build backlogs. The communication and collaboration features in Jama are key to keeping our engineering organization aligned with the product and business departments.
While we all work in Jama, our engineering teams use an agile scrum methodology and their day-to-day sprint planning and execution is managed in JIRA. Core to our workflow is the seamless synchronization between Jama and JIRA. We’ve used our original JIRA connector for this purpose, but when we launched the Jama Integration Hub, based on the Tasktop Sync product, a far superior tool, it naturally became a priority for engineering to make the switch.
Rolling out the Jama Integrations Hub at Jama
When we launched this initiative there was much to learn about the Integrations Hub and how it fit into our agile workflow at Jama, so we decided to take an incremental approach to the change. We have a number of scrum teams so we set out to migrate them one at a time over a course of a few sprints, allowing us to incorporate learnings from each migration and refine the process and our usage of the Integrations Hub. The nice thing about the process of switching to the new Hub is that you can migrate your teams and workflow away from our original connector incrementally, so the two tools can work side-by-side until all teams are completely migrated over to the new Hub.
We started out by engaging with one of our own implementation consultants, Matt Mickle, to learn about the Hub and the migration best practices. We mapped out our own agile development workflow, and the Jama- and JIRA-specific workflows that would be integrated. We created a timeline and created documentation that we would refine as we discovered more best practices for our specific needs. We also set up a migration support team and escalation process in the event we ran into any issues post-migration.
With this important up-front planning we knew what a migration looked like, how long it would take and how it would affect the capacity of the team during the migration process. In a truly agile way we had enough to start our incremental approach.
What we learned in setting up the Jama Integrations Hub
After we started the first team migration to the Integrations Hub we discovered a few issues which we quickly resolved, and then added new efficiencies to the migration process (more on that below). We also quickly learned that if we wanted to take full advantage of the Integrations Hub’s templates we needed to clean up our existing JIRA workflows. Up to this point, we didn’t have a consistent JIRA workflow, nor a naming convention. Remedying this problem as part of the migration process had the added benefit of establishing consistency across our teams and actually made our own JIRA administration much easier. Once we cleaned up our JIRA workflows we were able to take advantage of the Integrations Hub’s templates, adding a Story Template and a Defect Template, which gave us huge efficiencies. Now migrating a project, or even setting up a new project, is a matter of simply creating mappings from our existing templates.
Another lesson we quickly learned was the timing of all the various steps involved in migration. Our goal was to have a streamlined process for migrating teams to the Integrations Hub with little downtime. We determined that we could creating the Jama and JIRA filters needed for the Integrations Hub’s mappings the day before the migration, saving time waiting for a schema refresh. Huge amount of time saved!
Our next challenge was scaling the migrations and administration of migrated teams in the Integrations Hub. We already had a few tips from Matt Mickle about consistent naming of mappings in the Hub. We came up with a naming convention that incorporated the team name, item type, and the type of mapping. That way we could just simply look at the mapping names to know what they were instead of having to open them up to see what they were mapping and which team they belonged to.
A better workflow makes for a better product
Today we have all the scrum teams in engineering migrated over to the Integrations Hub. We have a well-documented Hub set-up process and naming conventions. Our JIRA workflow for migrated projects is now consistent across teams, which we found actually improved our Jama workflow, too.
We also understand the Integrations Hub a lot better now and can take advantage of all the new features with each release from Tasktop. For example, the ability to scope mappings by project, introduced in the Jama Integrations Hub 4.3, is a very useful feature and allows for more flexibility in how we structure projects in Jama.
The biggest win for our team, though, is that now that we now that we have integrated our Jama and JIRA workflows we have better insights into our product development process via a transparent workflow from product requirements through test results. Moreover, the integration of the data from each tool allows us to seamlessly jump into each system without paying the tax regularly associated with switching between tools, losing context, and waiting for data to synchronize across systems. This is a big time saver for our engineering teams and makes it seem like a single interconnected workflow instead of separate systems that we’re using.
Tips for a successful migration to the Jama Integrations Hub
Map out your end-to-end development workflow. While we use JIRA, the Hub also integrates with Version One, Rally, and Team Foundation Server. Include in your mapping how your development tool workflow meets your Jama workflow.
Utilize Integration Hub templates. The Hub’s templates are a huge time saver and ensure a consistent process.
Use consistent naming in your filters and mappings. This makes managing several teams and mappings much easier and allows you to scale your integrations with your development tool.
Make your development tool workflow consistent. Once we did this we found it was much easier to scale our integration and actually helped bring more order and consistency to our own JIRA workflows across teams.
Document your migration procedure. We created a checklist to ensure a repeatable and consistent process which could be improved over time.
Create your filters ahead of the migration. By creating the needed filters for the Integrations Hub mapping the day before the migration and then refreshing the Jama and JIRA schemas within the Hub, it made our actual migration process much faster.
Work with your Jama Customer Success team. For us, inside of Jama, this meant having someone from consulting and support available to assist. For you as a customer, we recommend working with your Jama Customer Success team to quickly deal with any issues as they come up. Once you’re through the first few migrations the process will get faster and easier.
Our team would be interested to hear from you about how you’re managing workflows between teams, whether you’re using Jama or not yet using Jama. Do you have integrations between the various tools that your business, product and engineering teams use?
Today we are rolling out our Fall 2013 Release and with it, continuing to enhance the most collaborative and efficient product delivery platform on the market. With the newest version of Jama, we are tackling one of the most fundamental challenges companies face when trying to accelerate their time to market: change.
In today’s technology-driven economy, companies are being driven to deliver better products to market faster in order to survive, let alone grow and succeed. The most innovative companies in their markets today have one key focus in common: delivering a fantastic customer experience. They embrace frequent customer and stakeholder feedback loops and the resulting change required to ensure they’re completely aligned on delivering customer value. The need to change is an opportunity to do something better. Product delivery is an iterative process and companies who embrace this not only get projects completed on time and products to market faster, they deliver what the customer wants, learn, and continually improve. Companies that continue to look at change as “churn” that needs to be controlled and mitigated will be left in the dust.
How does Jama Fall Release help you embrace change as an opportunity and move to a more iterative development process? As your product moves through the phases of define, build and test, Jama helps you connect the people involved, so everyone knows what you are building and why. We’ve also enhanced our integration capabilities, providing two-way data exchange between Jama and the most popular developer tools.
All the new capabilities align to improve the flow of information and boost collaboration to ease and shorten product delivery cycles. Watch the video below for specifics on what is new in the Fall 2013 Release.
![[Webinar Recap] Optimizing Your QA Process by Integrating TestRail and Jama Connect®](https://www.jamasoftware.com/media/2022/01/2022-1-27-WB-Tasktop-Recap_Social-Image.png "[Webinar Recap] Optimizing Your QA Process by Integrating TestRail and Jama Connect®")
