Tag Archive for: Best Jama Blog Posts of 2019

Our customers go to work each day with the goal of building amazing products.

Doing that involves adjusting to the competitive landscape and anticipating what’s to come. Our customers know they’re not going to reach new heights with tomorrow’s releases by following yesterday’s playbook — so they iterate and evolve.

Similarly, Jama Software, as a company, has to adapt to the rapid rate of change in the world of product development.

Over the past year, we’ve been making improvements across our product line, expanding our integration partners and broadening our services offerings to ensure our customers have the most effective platform for requirements, risk and test management available.

The new colors, logos and designs you’re seeing across Jama today are more than just an effort to look the part; they’re a reflection of a broader commitment to our customers.

Sincere Partners in Your Process

Whether you’re creating life-saving medical devices or mind-bending supersonic jets, there’s no doubt that you’re attuned to the expanding complexity of products today.

A recent report from Engineering.com found that more than 90% of design and engineering professionals reported that, over the past five years, their products had increased in complexity, due to factors ranging from additional electrical components to the growing intricacy of mechanical designs.

Despite those facts, only 15% of the roughly 300 professionals surveyed by Engineering.com rely on a dedicated requirements management solution like Jama. It’s no surprise, then, that the majority of respondents also experienced substantial product failures and, for those in regulated industries, penalties from governing agencies.

On the flipside, those who used a purpose-built requirements management platform, especially in regulated industries, not only received fewer instances of warnings, recalls, fines and production stoppages than those that didn’t, but nearly half reported experiencing none of those problems at all.

If you’re a Jama customer, then, you’ve already made an extremely wise choice in helping safeguard your organization from the risks of performing requirements management with outdated methods: unwieldy spreadsheets, underperforming homegrown tools, legacy software, or some combination of all three.

Strength in Numbers

It’s not enough to give our customers a powerful platform for developing products and hope it’ll be enough to take their work to the next level.

That’s why we’re constantly cultivating alliances with others in adjacent spaces of product development to streamline efforts and bolster the value of our combined solutions. Our recent partnership with ANSYS, which gives our customers a stronger way to perform impact analysis, is just one example. High-profile integrations with other leading development solutions, such as Jira Software from Atlassian, will also continue to manifest and strengthen the value of Jama.

For those in industries where safety is paramount, we’re also working to ensure you deliver not only the most innovative products, but also ones with fewer risks and hazards. Our medical device customers now have a straightforward approach to managing risk according to ISO 14971 with the Jama Connect Risk Management Center, which was released in January. Along with that new feature, we’ve also introduced Jama’s Medical Device Services to ease the path to regulatory compliance and ensure teams get ramped up quickly with Jama Connect™. Additionally, we’ve extended the scope of our certification with internationally recognized testing body TÜV SÜD, to include medical devices as well as railway applications.

Facing the Future Together

Through all these efforts, we’re working to ensure our customers can put less thought into the manual and mental labor of their development process, and instead spend more time innovating.

In our experience, the best innovations are always sparked by moments of pure imagination. Those fleeting seconds of inspiration are tough to come by when you’re watching the clock in lengthy status meetings, chasing down reviews, digging out of compliance paperwork or printing spreadsheets of requirements that could stretch across a boardroom 10 times over.

We want each of our customers to gain more freedom in their roles by making their processes more efficient, predictable and collaborative in real time. And as we continue opening up our services and integrations to other companies who are also relentlessly pushing product development forward, you’ll spend less time switching between tools for information, making Jama your ever-increasing single source of truth.

Spring is a good time for new beginnings. Freshening up the exterior of the Jama Software brand is emblematic of our approach to product development today and moving forward. We hope it makes you feel like the future is both bold and bright, and that we’re all heading there together.

Download the 2019 report from Engineering.com that highlights the value of a purpose-built requirements management solution: “Design Teams: Requirements Management & Product Complexity.”

Whether you’re just entering the automotive market or looking to improve your development process, you’ll need to become extremely familiar with the ISO 26262 standard.

In 2011, ISO 26262 was created to set the standard for the automotive industry and its suppliers around functional safety in electrical and electronic systems development. To address the industry’s rapid evolution and to ensure that these new electronic functions remain functionally safe in the new environment, the International Organization for Standardization (ISO) recently introduced a second edition of ISO 26262 in December 2018.

There are plenty of updates to sort through in the ISO 26262 2018 version, from building motorcycles to providing more guidance for the semiconductor industry.

Given that the first edition of ISO 26262 hung around for roughly seven years before it received an update, you can expect the most recent version to be the standard for driving quality and reducing risk in automotive functional safety for at least the foreseeable future.

What follows is a non-comprehensive overview to help familiarize you with important ISO 26262 second edition updates. However, it’s imperative that developers for the automotive electronics industry independently study and understand the updates and how their process must evolve to accommodate.

Expansion of the ISO 26262’s Scope

With the implementation of the second edition of ISO 26262, all road vehicles are now included – not just those with four wheels and a maximum vehicle gross mass of up to 3500 kg, as was the case in the first edition.

Motorcycles, trucks, buses, trailers and semi-trailers are now all covered in detail. Your development teams will need to familiarize themselves with the specifics. This webinar from Automotive World provides a good summation of the major changes with a particular focus on motorcycle and commercial vehicle development, and we’ll quickly touch on some of the key points.

Whereas passenger vehicles must adhere to an Automotive Safety Integrity Level (ASIL), the latest version of ISO 26262 introduces a Motorcycle Safety Integrity Level (MSIL). And, as such, the hazard analysis and risk assessment for motorcycles been altered to account for the differences. One thing worth noting is since motorcycles are so unique in their performance, there’s a larger emphasis placed on the responsibility of the rider versus the machine itself. For instance, whereas most cars are expected to still perform well in ice and snow, motorcycles are not, and so if a rider makes the choice to drive in those conditions, they are purposely accepting a higher degree of risk.

Since trucks and buses, on the other hand, are primarily defined by their larger size and mass, those factors tie into their controllability and, therefore, exposure to risk. For example, when a large truck is loaded with cargo, it’s going to have few issues with things like wheel spin on a steep hill than when it’s completely empty. And because different trucks, buses and semi-trailers all have unique purposes for use (for instance, long-haul semi-trucks versus city buses) and are typically exposed to different conditions and environments, the second edition of ISO 26262 makes distinctions between the base vehicle types of each. In terms of controllability, for example, concrete trucks should be able to withstand something like an unpaved construction site, whereas buses don’t regularly encounter that sort of terrain.

Software Tools Confidence Levels

Development software that’s used to create components for automotive systems must be qualified to do its job in a functional safety design environment. The qualification and classification requirements are described in Clause 11 of ISO 26262, Part 8. Software tools receive a certified qualification report if they are fit for purpose.

It’s worth noting that Jama Connect™ has already been certified fit for developing safety-related products according to ISO 26262 (up to ASIL D) by internationally-recognized testing body TÜV SÜD. That means Jama customers can use the TÜV SÜD certificate as an argument for software solution qualification in projects, instead of having to spend time qualifying it themselves. Jama is the first vendor that is both SaaS and Agile to receive the certification. You can read more about the benefits of this distinction here.

Learn how Jama Software worked with TÜV SÜD on our ISO 26262 certification process, and how you can lower the costs and risks of complying with functional safety standards, by watching our webinar.

Functional Safety and Cybersecurity

In response to increasing security concerns in connected devices in automobiles, ISO 26262 now requires a management plan that incorporates effective communication channels between functional safety and cybersecurity. These necessary channels have been identified at both the functional safety management level and at the system level for product development.

Guidelines for Semiconductors

The first edition of ISO 26262 did not include specific guidelines for semiconductors used in automotive application. This caused some confusion and led many automotive teams to create their own functional safety requirements for their semiconductor suppliers.

Now, a new section provides guidelines on and definitions for semiconductor components and semiconductor technologies used in automotive application. This should not only eliminate uncertainty, but also create uniformity when it comes to the design, verification and validation of semiconductors for the automotive industry.

What’s Not Included

One thing that was left out of the second edition is “the non-systematic and random safety issues that will occur with autonomous systems using neural networks.” Semiconductor Engineering explains that this is because a new standard coming later this year – SOTIF, Safety Of The Intended Functionality – will include new automation technologies for things like autonomous vehicles not covered in ISO 26262:2018.

To further assist in mitigating risks in the development process and maintaining compliance with automotive functional safety standards, learn how to mitigate common ISO 26262 mistakes with our whitepaper, “Top 15 ISO 26262 Snafus.” 

NASA Jet Propulsion Laboratory employees, 1940s

In 1953, a woman named Elsie Shutt accepted a job as a programmer at defense contractor Raytheon, where she was astonished to find that the programming workforce was about 50% women and 50% men. “It really amazed me that these men were programmers,” she said later, “because I thought it was women’s work!”

Wait. What?

In a February New York Times Magazine feature, “The Secret History of Women in Coding,” journalist Clive Thompson uncovers the little-known history of the women who shaped the early software industry, and disentangles the complex of web of social, cultural and economic factors that led to programming becoming a field dominated by men.

The feature is an excerpt from Thompson’s forthcoming book, “Coders: The Making of a New Tribe and the Remaking of the World,” out March 26, 2019. Drawn from hundreds of interviews with developers, Coders is an immersive account of who coders are, what they do and how their work shapes our reality.

We sat down with Thompson, a columnist for Wired and a longtime contributor to Smithsonian and The New York Times Magazine, to learn more about the history of women in software – and why that history has been largely forgotten.

Software Pioneers

In the 1940s, digital computers finally became a practical reality. “At the time,” writes Thompson in The New York Times Magazine, “men in the computing industry regarded writing code as a secondary, less interesting task. The real glory lay in making the hardware.” The term software had yet to be invented.

As Thompson recounts, the Electronic Numerical Integrator and Computer (Eniac), the first programmable digital computer in the US, weighed more than 30 tons and included over 17,000 vacuum tubes. “Merely getting it to work was seen as the heroic, manly engineering feat,” Thompson writes. “In contrast, programming it seemed menial, even secretarial. Women had long been employed in the scut work of doing calculations.”

But these women were software pioneers. They were “among the first coders,” Thompson writes, “to discover that software never works right the first time — and that a programmer’s main work, really, is to find and fix the bugs.”

Computer scientists like Grace Hopper, Thompson says, also played a pivotal role in developing computing languages closer in structure to the words we use, thereby making programming more accessible and intuitive to people not familiar with binary code.

NASA Langley Research Center employees, 1947

In the ’50s and ’60s, the number of coding jobs rose sharply as companies began relying on software for payroll, data analysis and other applications. Women continued to be hired as programmers; some executives, Thompson notes, argued that a woman’s presumed expertise in knitting, cooking, sewing and other meticulous domestic tasks would make her a superior programmer. Thompson calls coding in the ’50s and ’60s “the rare white-collar occupation in which women could thrive.” But, of course, there were limits.

Elsie Shutt, the Raytheon programmer, was required by state law to leave her job when she had a child in 1957. Companies were hiring full-time female coders, but part-time work wasn’t on offer, even for highly qualified programmers. Shutt founded a code-producing consultancy and hired stay-at-home mothers to work part time. If they didn’t know how to code, she trained them. “What it turned into,” Shutt would reflect later, according to the New York Times Magazine feature, “was a feeling of mission, in providing work for women who were talented and did good work and couldn’t get part-time jobs.”

“You Can’t Do That”

By the 1980s, Thompson writes, early women programmers had largely been forgotten, and pop culture was sending a very different message: Computers were for men. The cultural model for a coder had changed. No longer a single woman or working mother, the prototypical coder was now — to use Thompson’s phrase — “a nerdy guy.” It’s a calcified stereotype that sticks with us. So what changed?

Part of the shift began happening as early as the ’60s and ’70s. With more men becoming programmers, women began to notice that their advancement opportunities were evaporating. Thompson explained what many women told him: “The time came for a promotion. The time came for more money, and she didn’t get it. When she asked the boss why, he said, ‘Well, you know, you’re a woman, and he’s a guy. And he’s going to need to look after his wife and kids.’”

As coding became more central to business operations, a demand grew for programmers who could stay late to maintain uptime. Women coders found that their bosses discouraged them – and sometimes even forbade them – from working late at night. As Thompson tells us, “They heard, ‘Well, you can’t do that. Yeah, you’re a coder, but you can’t stay late at night when the guys were there. It’s too dangerous.’ And there was also a sense that it was scandalous… A single woman working late at night with men who may or may not be married.”

As absurd as such logic might sound, these social mores created and enforced real barriers to women’s success, and not just in computer science. “One of the barriers for female lawyers advancing in the ’60s and ’70s,” Thompson says, “was you couldn’t work late at night because the male partners were married, and you couldn’t be alone with them.”

As computer science drew more professional respect and cultural attention, it ceased to be considered “women’s work.” We asked Thompson whether, if programming had continued to be dismissed as “scut work,” akin to typing or taking messages, the industry would comprise more women today.

“Quite possibly yes,” he says. “If programming had remained sort of a menial task, then it may well be that men in power would have left it to the women. Certainly, that is what many women who were around back then said to me. And they watched it happen.”

The New Coder

It wasn’t only social conventions that barred women’s access to coding. Somewhat counterintuitively, the increasing prevalence of personal computers in the home led to greater gender imbalance in schools and at work. As the first generation of personal computers — the Commodore 64 and the TRS-80 — emerged, teenagers began learning to program in their spare time. Thompson himself was one of these self-taught coders for whom personal computers became a gateway to more sophisticated programming: “I liked video games,” he says, “and I wanted to make video games and show them to my friends. You can learn a lot that way.”

But most of the teens teaching themselves to code were boys. In the mid-1980s, when college freshman began arriving on campus as proficient programmers, they were mostly male, too.

By the 1990s, Jane Margolis, now a senior researcher in the UCLA School of Education and Information Studies, and Allan Fisher, then associate dean of the computer science school at Carnegie Mellon, were looking into why women’s enrollment in computer science was so low.

In a study of 100 computer science undergraduates at Carnegie Mellon, Margolis found that young men had received much more exposure to computers than girls had; for example, boys were twice as likely to receive computers as gifts from their parents than girls were. Boys also received instruction and encouragement at home and in the classroom, but the same wasn’t true for girls.

Margolis told Thompson that every female computer science student at Carnegie Mellon reported that her father had taught her brother basic programming skills – but that she “had to fight her way through to get some attention.” Margolis and Fisher later published their research in a landmark book, “Unlocking the Clubhouse: Women in Computing.”

As Thompson writes in “The Secret History of Women in Coding,” “Girls, even the nerdy ones, picked up these cues and seemed to dial back their enthusiasm accordingly. These were pretty familiar roles for boys and girls, historically: Boys were cheered on for playing with construction sets and electronics kits, while girls were steered toward dolls and toy kitchens.”

An environment had emerged in which the students most likely to be successful were those who had already been exposed to coding – meaning, largely, men. And even as academic doors were closing to them, women were facing an uphill battle in corporate America, which had an increasingly specific — and exclusionary — vision of what a successful programmer looks like.

Unconscious Bias in Tech

By the 1990s and early 2000s, Thompson writes, “the pursuit of ‘culture fit’ was in full force, particularly at start-ups… Founders looked to hire people who were socially and culturally similar to them… Because almost everyone in charge was a white or Asian man, that was the model for whom to hire; managers recognized talent only when it walked and talked as they did.”

It isn’t just women who suffer the effects of unconscious bias, of course. A 2016 study showed that people of color were much more likely to be offered jobs if they “whitened” their names (for instance, by using “L. Smith” instead of “Latisha Smith” or “Wade” instead of “Wei”).

“Women’s contributions to open-source software are accepted more often than men’s are, but only if their gender is unknown.”

In its 2017 cover story, “Why is Silicon Valley So Awful to Women?”, The Atlantic reported: “Women not only are hired in lower numbers than men are; they also leave tech at more than twice the rate men do… Studies show that women who work in tech are interrupted in meetings more often than men. They are evaluated on their personality in a way that men are not. They are less likely to get funding from venture capitalists… And in a particularly cruel irony, women’s contributions to open-source software are accepted more often than men’s are, but only if their gender is unknown.”

Ellen Pao, a former junior partner at venture-capital firm Kleiner Perkins Caufield & Byers, famously filed a gender discrimination suit against Kleiner Perkins in 2012, training a spotlight on gender imbalance in Silicon Valley. In 2017, she told The New Yorker that while women were still vastly outnumbered in tech in the ’90s, the culture was nowhere near as competitive, money-driven or exclusionary as it became.

The environment, Pao says, changed after early venture-capital firms started investing in tech. “They happened to all be white guys who had graduated from the same handful of élite colleges,” Pao told The New Yorker. “And they tended to make investments in new firms started by people they knew, or by people who were like them.” Facebook’s 2012 IPO cemented Silicon Valley’s reputation as “the place to make a quick fortune,” Pao says, and tech began competing with hedge funds and financial institutions for the sharpest college graduates – further shifting the culture.

The result is a dramatically lopsided industry. According to the Bureau of Labor Statistics, only 26% of employees in “computer and mathematical occupations” in the US are women. Black employees represent just over 8% of this workforce, while Latinxs represent 7.5%.

If this sounds bad, brace yourself, because the numbers are even worse at the household names. In 2017, Recode reported that only 15-20% of technical employees at Google, Facebook and Twitter were women, while Black and Latinx employees made up a measly 1-4% of the technical workforce at these companies.

Not all bias is unconscious, though. In the summer of 2017 (yes, 2017), a Google employee suggested in an internal email that women are inherently worse programmers than men, citing bogus sociobiology to explain away the gender imbalance in programming. Although Google fired the employee for violating the company code of conduct, plenty of male Googlers defended him, emphasizing the deep-running assumption among many that the programming workforce reflects a pure meritocracy.

“If biology were the reason [for the gender imbalance], it would be impossible to explain why women were so prominent in the early years of American programming, when the work could be, if anything, far harder.”

Thompson’s response to those who argue that biology is the reason we don’t have more women in coding is unambiguous: “If biology were the reason,” he writes in “The Secret History of Women in Coding,” “it would be impossible to explain why women were so prominent in the early years of American programming, when the work could be, if anything, far harder than today’s programming. It was an uncharted new field, in which you had to do math in binary and hexadecimal formats, and there were no helpful internet forums, no Google to query, for assistance with your bug. It was just your brain in a jar, solving hellish problems.”

“Shifting the Culture”

In a marked contrast to the United States, according to studies Thompson cites in his feature, women make up about 40% of students studying computer science and related fields in India. In Malaysia, 52% of undergraduate computer science majors are women. (So much for biology.)

Thompson, following other researchers, argues that parental encouragement and social norms are key differentiators in countries where more women pursue programming: “When you do find women in coding today, they often have some really good encouragement and role models along the way… They had parents and mentors who said, ‘Yeah, you should do this. This is great.’ Encouragement is a really, really big deal.”

“In other countries where it is seen as normal for women to do coding, they do a lot more coding.”

When more girls and women study programming, the concept becomes normalized. In countries where more women pursue coding careers, Thompson says, “there might be a bunch of reasons why that is. But the bottom line is that it just doesn’t seem weird. In other countries where it is seen as normal for women to do coding, they do a lot more coding.”

Thompson credits organizations like Black Girls Code, dedicated to empowering women of color to succeed in STEM fields, with opening people’s eyes, including the next generation of potential programmers: “We need to make sure the gateway [to learning to code] stays open,” he says. “It’s a big factor that goes alongside direct encouragement. You want to expose as many kids as possible who might otherwise feel pushed away from [coding]. It really is heartening that organizations and after-school programs are tackling this, because it isn’t something you solve entirely through school.”

Meanwhile, more girls are learning to code in school. In 2012, according to research by UCLA’s Linda Sax, the percentage of female undergraduates planning to major in computer science began to rise at rates not seen since the decline of the mid-1980s. Culturally, the history of women in STEM is rising in profile; Margot Lee Shetterly’s bestselling book, “Hidden Figures,” was made into a high-profile movie about NASA’s human computers, including Katherine Johnson.

But the veteran women coders Thompson interviewed remain skeptical: “What is harder is shifting the culture of the industry at large,” he writes, “particularly the reflexive sexism and racism still deeply ingrained in Silicon Valley.”

With more people of all genders flooding into the industry, Thompson cautions, organizations will need to push back against a temptation to divide programming into white- and pink-collar segments: front-end development for women; block chain and AI for men.

No Silver Bullet

In talking with organizations that have succeeded in increasing the number of women in their ranks, Thompson found that there was no single solution for gender equality, no one policy capable of reversing decades of structural discrimination.

As Thompson told us, “I asked Jane Margolis and Allan Fisher [who researched the status of women in coding at Carnegie Mellon], ‘So, you went from a small minority of women to 30-40% in a couple of years. How did you do that?’ And they said, ‘Well, here’s the eight or nine things we did.’ And no one of them was the single silver bullet.”

Thompson says that Margolis and Fisher tried everything they could think of to attract more women. “Ranging from things that seem obvious to ones that seem trivial,” he says. “And in some respects, it actually makes it a harder story to write and a harder story to read, because you want there to be a single answer. And it’s not there.”

Even for Thompson, the full story of the rise and decline — and, fingers crossed, the new rise — of the woman coder remains complex and subject to interpretation. “It’s still a puzzle to be understood,” he says. “I mean, I can tell the best story I can based on research, and the work of historians, and the woman I spoke to who lived through it. That’s how we understand why and how this happened.”

We asked Thompson what drew him to the little-known history of women coders, and why he felt their story was so important. “American society is always good at discarding recent history,” he says. “Telling stories of the heroic past is a good way to make sure we know what happened.”

Clive Thompson’s new book, “Coders: The Making of a New Tribe and the Remaking of the World,” out March 26, 2019, is an in-depth look at the past, present and future of programmers. Thompson is a Wired columnist, a contributing writer for The New York Times Magazine, and the author of “Smarter Than You Think: How Technology is Changing Our Minds for the Better.” You can preorder his new book here.

Jama Software is committed to achieving greater diversity and nurturing a more inclusive Portland tech community. We have taken the TechTown Diversity Pledge, a commitment by Portland tech companies to cultivate a diverse talent pipeline and foster inclusive work environments.

It’s in the name: Jama Connect™ gives you superior visibility into every stage of your product development process by connecting stakeholders with the right information at the right time. The result is better collaboration within and across teams, so delayed replies and ambiguous feedback won’t hamper your forward progress.

Our Jama Professional Services consultants work with users across a range of organizations and industries to help them optimize collaborative success and get the most value from the platform. To share more of their expertise, our consultants recently conducted a webinar on Jama Connect best practices that covered a range of topics, including creating groups and finding information faster.

Today, we’ll be sharing more insights from that webinar, this time looking at some of the common functionalities and lesser-known features our consultants recommend for teams looking to improve their collaboration within Jama Connect.

(For this post, we’re assuming a reasonable level of familiarity with Jama Connect. If you’re looking for a more granular guide, start with the User Guide or get your questions answered in our support community.)

Stream View

On the far right of your Jama Connect dashboard, you’ll see a link to stream view. Stream view lets you see all the conversations happening at a specific level of the project or across the items located within a project. You can join an existing conversation or start a new one by @ mentioning the individuals or teams you want to connect with. For instance, start typing “system engineers,” and you’ll see that group pop up. Now you can initiate a conversation with a specific group, and everyone in that group can receive a notification that you’ve made a comment.

This brings us to another feature in Jama Connect that makes communication easier: notifications.

Comment Notifications

There’s an easy way to control some of the feedback notifications you receive in Jama Connect, especially during the review process.

By default, when you comment on an item within a review, you start following that item, and whenever anyone else comments on the item or anywhere within the review, you’ll receive a notification.

You can easily change your notification settings from your profile. In the upper right corner of your Jama Connect instance, you’ll see your name; click on it to access your profile. Select the Review Center tab. You have two notification options: “Email me updates to items on following” or “Automatically follow items I have commented on.” Uncheck the second choice. Now, when you comment on a review, you will no longer automatically be following that item.

If you’re already keeping tabs on the comments in Review Center, you probably won’t need email notifications outside of Jama, but this is an opportunity to customize how you receive information about your process.

Subscriptions Notifications

Subscriptions allow you to loop a group of users — like the systems engineering team — into notifications about new defects or updates to defects within the project. You can also subscribe yourself to any item in Jama Connect that’s relevant to you. For instance, if you subscribe to a set of defects, every time a defect is added or updated, you’ll receive a notification.

Just as with comments, you can control how often you receive email notifications. To do this, go back to your profile, click the “Subscriptions” tab in the upper right. There, you’ll see everything you’re subscribed to, and you can unsubscribe or customize how you’d like to receive notifications about updates or additions to items on your subscription list.

You’ll see that immediate subscription notifications are the default, but you can change that to daily or weekly notifications. One of our consultants suggests that daily digests are the most helpful: Weekly notifications contain too much information that isn’t pertinent, while immediate notifications clog up your inbox so that it’s easy to miss what’s most important.

Categorizing Feedback

There’s a single, powerful tip for improving the feedback you give and receive when participating in a review. We’ve all received emails or other communications where it’s not clear what the sender is asking for: Are they asking a question? Do they need action from you?

Jama’s Review Center includes a feature that allows participants to categorize their feedback as a question, a proposed change or a potential issue. Adding context to your review comments helps ensure clear, efficient feedback, and empowers the moderator to filter and manage feedback by its assigned category.

For a deeper dive into maximizing Jama Connect, check out the Ask Jama webinar or explore the Jama Connect User Guide, which is full of tools to plan and track progress and performance.

In 2001, gathered together in Snowbird, Utah, a group of 17 like-minded software developers brainstormed ways to quickly build software and get it into the hands of end-users. Out of this meeting the Agile Manifesto was born.

The iterative and incremental methodology of Agile has generally been accepted as a modern approach to software development and has high adoption rates across many industries. However, with fluidity and responsiveness to change at the forefront of Agile’s methodology, many organizations believe that Agile is not compatible with highly regulated industries. Lack of planning and documentation, they wrongly believe, are reasons why Agile cannot work for those building products under regulatory compliance.

The truth is that using Agile for product development within regulated industries is actually true to the Agile Manifesto. Here’s why:

Agile is a Set of Values, Not a Set of Rules

The full Agile Manifesto is a succinct and comprehensive overview of the framework’s principles, and the gist is quite simple. Agile is a methodology that encourages teams to iterate; to communicate with stakeholders, customers and suppliers; to not go crazy with documentation; and to be good human beings at work. Pretty simple, right?

So why do many organizations in regulated industries believe that Agile is not feasible?

While dealing with audit requirements and regulatory compliance, the idea of fluidity and “responding to change over following a plan” may have those in regulated industries cringing. But where in the Agile Manifesto does it say that planning and documenting have no place in your software development process? It doesn’t.

The truth is, adopting Agile values just means you are agreeing to open communication, iterating and focusing on delivering a product. Values are just one part of the product development process – organizations in highly regulated industries can adopt Agile values but still select a stricter framework and strategy to adhere to regulatory standards and document their processes.

And while documentation is not discouraged in Agile, teams are encouraged to view working software as a better indicator that the product meets requirements rather than reams of documentation.

Why Choose Agile for Regulated Industries?

Waterfall has traditionally been a popular choice for highly regulated industries. And yet, the number of organizations adopting Agile now due to very low success rates with Waterfall is rising. With fixed requirements and rigidity as the basis for Waterfall processes, there’s very little room for change and flexibility as requirements evolve.

On the other hand, teams who have adopted an Agile methodology are highly focused on creating products that meet end-users’ needs. And Agile gives them the flexibility to be both iterative and fluid.

Agile methodologies also allow for (and encourage) communication between customers, stakeholders and suppliers. You’ll be able to see in real time what’s working and what’s not and, in turn, keep tabs on what your customers want. By constantly reexamining customer needs and wants, Agile teams are more likely to deliver a product that meets users’ expectations. This, simply put, can be your competitive advantage.

Agile not only makes good business sense but may also help your employees feel happier and more fulfilled at work. Adopting the Agile methodology empowers your engineering and product development teams to change as they need and to use their professional judgement. It allows them to have open communication, to know that what they’re building is useful, and to feel that they are being respected and heard.

Leveraging Jama Connect™ for Agile Documentation

When adopting Agile in highly regulated industries, it’s important that you work closely with auditors — internal or external — to clearly communicate your documentation processes. This is where Jama Connect™ comes in.

Jama Connect is your single source of truth when it comes to complex product development. It allows you to document and communicate your requirements and what you’re setting out to build, and gives you a record of who, what and why things changed along the way. Plus, if you decide to make a change or switch directions, everything is fully reversible.

Real-time collaboration within Jama Connect gives you a platform to discuss change by connecting comments, decisions and reasoning throughout the project. With closer communication (in accordance with Agile methodology), teams experience increased productivity, a shorter design process and critical context for improved decision-making.

Jama Connect provides your team with valuable information to help them decide when and how to make changes.

Is Agile Right for Your Team?

While Agile is compatible with all industries — even those with strict regulatory standards — it all comes down to choosing a methodology that is right for your team. A good place to start is by identifying what values are most important to you and your organization and examining your processes to understand what you want to achieve.

Download our whitepaper, Agile for the Enterprise, to learn more about successfully implementing Agile in regulated and governed industries.

Under strict timelines and budgets, healthcare innovation companies must develop safe products that are regulatory compliant. With stiff competition and increasing demands from patients and physicians, many organizations find themselves searching for ways to gain a competitive advantage.  

One of the ways software application companies can find that edge is within their product development processes. For instance, exchanging versioned Word and Excel documents during development to manage requirements, track progress and stay compliant isn’t enough to keep up with the growing complexity, risk and speed of today’s competitive marketplace.  

Such was the case for MediSync, which innovates new methods and care models to help large medical groups achieve nation-leading clinical and cost outcomes for physicians across the United States. MediSync’s offerings for improving medical group performance spans support and consulting for group practice operations, solutions for chronic disease management, transition assistance to value-based pay models, and revenue optimization.  

Founded in Cincinnati, Ohio, in 1996, the company has grown its product portfolio and customer base to include more than 170 leading medical groups. MediSync’s mission is to innovate, disrupt and transform healthcare. 

Challenges with Growing Complexity  

MediSync-managed medical groups are consistently recognized for best-in-class chronic disease outcomes for their patients including perennial commendations in AMGA’s “Measure Up, Pressure Down” (hypertension) and “Together2Goal” (diabetes) programs as well as CDC’s “Million Hearts” (heart failure) program.

MediSync sought to translate its care methods into software applications to scale deployment, standardize execution, and share its expertise with medical groups across America. MediSync needed to build new capabilities in software development starting with the identification of a top enterprise software executive to lead the initiative.   

Ray Kaiser, Vice President of Technology at MediSync, joined the team with more than two decades’ worth of experience in developing and delivering enterprise level applications and business processes. He began by starting a SaaS division that builds applications that would integrate and leverage client Electronic Health Records (EHR) to enable care providers to better serve their patients and achieve nation-leading clinical outcomes. 

Ray’s new team began by using standard office tools such as Microsoft Word and Microsoft Excel for product development planning. Almost immediately, these tools proved to be outdated and inadequate for the complex needs of an integrated healthcare software application. He saw that the team had difficulties with versioned documents, spent way too much time conducting in-person review cycles and generally struggled to keep everyone on the same page.  

Streamlining Development with Jama Software 

Kaiser examined multiple product development platforms and ultimately decided on Jama Connect™ because it was easy to use, fully configurable and had cloud and integration options that MediSync’s projects required.  

“Jama was so easy to use that our main challenge was going from paper to electronic,” Kaiser says. “Initially, we really weren’t sure how to apply and adapt our processes to Jama. But what we found was that we could just put it all into Jama and modify it as we needed by adding fields and relationships. It was all reconfigurable and flexible.” 

Over the last year, MediSync has leveraged Jama to achieve substantial time and cost savings through better collaboration, the ability to access the platform anywhere and improved security.  

“Even today, after using Jama for well over a year, we’re still finding things that help us to drive continuous improvement and to make us more efficient,” Kaiser says.  

Reduced Time and Effort Among Improvements 

Of all the user experience analysts and business analysts at the company, Michelle Seitz, Senior Business Analyst, uses Jama the most.  

“If I’m not in meetings, I probably spend 75% of my time in Jama creating reference materials using the tech document feature, storing configuration data and making sure we have all that inter-repository,” Seitz says. “But more so, creating requirements for our software project.”  

For her, the most significant benefit of Jama is the reduced time and effort it takes to complete review cycles.  

“My favorite part of Jama right now is when I get a collection of requirements to send out for a review,” Seitz says. “It is so much better with Jama. It’s the first time I’ve had a product that works as seamlessly as Jama does to produce a review and get feedback without having to do all the track changes and stuff that we used to have to do in Microsoft Word.” 

Gaining Value Through Efficiency  

Both Kaiser and Seitz agree that Jama has become the backbone of their product requirements planning process. Kaiser believes that Jama has saved 80% of planning time that previously would have been wasted on meetings, sorting through versioned documents and emails, and consolidating feedback in review cycles.  

“It’s definitely been a big help in facilitating and communicating with everybody,
Seitz says. “The team loves it when they see a review come across their email from me. Then, when I give them only a couple days to do it, they usually hop on it under our tight deadlines.” 

With so much on the line as they prepare to launch their new products, the team agrees that the switch from a paper-based system to a digital one was well worth it.  

Between the saved time and reduced frustrations, MediSync is cleared to focus on creating better outcomes for patients with chronic illness. And MediSync already has several new products on the roadmap to build with Jama. 

As Kaiser put it, “I honestly don’t think anyone on my team could go back to a development process that relies so heavily on using Microsoft Word and Excel. We are far better with Jama Connect.” 

Learn how Jama Connect helps medical device development teams spend less energy on compliance and more time on innovation with our webinar, Accelerate Medical Device Development While Reducing Risk.

The Jama Support Community is a forum for Jama Software users to interact and collaborate with other users and with Jama support engineers. It’s full of resources for everyone from novices to masters, including tutorials and webinarshelp guides and FAQsfeature requests and announcements and a robust knowledge base. For today’s post, we spoke with one of our Jama Support Community power users — frequent contributors with great questions and powerful insights into using Jama — about how their organization uses Jama and the value they’ve seen from the Support Community.

Srilatha Kolla works on the DevOps team at at Hill-Rom Cary in the Raleigh, North Carolina area. Hill-Rom’s Clinical Workflow Solutions team develops medical devices that protect patients by anticipating the care they will need and communicating that information to their healthcare providers.

The process of developing these Class II and Class III medical devices is heavily regulated by the FDA, and Kolla’s team needed to achieve full traceability in order to satisfy these requirements. Hill-Rom was using IBM Rational DOORS for their requirements and test case management prior to 2012, but it didn’t meet their traceability needs, among other shortcomings.

Kolla, who started her career as a developer at IBM, was on the Quality Engineering team at Hill-Rom when they began looking for a superior solution. Her QE team evaluated several options before choosing Jama Connect™ in 2012.

Since then, Kolla has moved to the DevOps team, where she’s responsible for deploying and managing processes to help development, requirements and quality engineering teams build, test and release products that are safer and more reliable. Her team is closely involved from the requirements stage to coding, testing and verification of the product, and she’s responsible for managing the solutions, including Jama Connect, that her team depends on.

Kolla’s DevOps team serves as the Jama administrator at Hill-Rom, but the development, requirements and quality engineering teams, she says, also “live in Jama Connect day in and day out.” Among the organization-specific best practices her team has developed is a multi-project structure, which works better for them than a single, more complex project structure.

As an FDA-regulated company, Kolla says, Hill-Rom values Jama Connect for its traceable requirements and test case management: “That’s what we depend on highly.” She’s also a fan of the Review Center in Jama Connect. The Review Center enables teams to collaborate without hunkering down in the same room or emailing a Word document back and forth. Stakeholders can also review and sign off on requirements within the Review Center, which comes in handy when you need to reach consensus between team members quickly.

Kolla began using the Jama Support Community to get her questions answered. She wanted to see how other people were using Jama to address the same product development challenges her team was facing. As Kolla says, “We’re definitely not the only ones using this platform.” ­­

Like many Jama customers, Kolla’s team uses Jama Connect in conjunction with Jira, so she turns to the Support Community to ask relevant questions about Jama’s functionality and interconnectivity with Jira, Microsoft Office and other tool suites. Given her team’s focus on traceability, Kolla has often sought Jama-related input from other users on things like item management, defects, Test Center, Trace View, Coverage Explorer, Reuse and Filters.

Stay tuned for more posts on how Jama users are leveraging the Jama Support Community to get the most out of the platform. In the meantime, connect with Sri and other fellow Jama users on the Jama Support Community

Collaboration in product development helps improve quality, reduce risk and speed up development. For this reason, Jama Connect™ has context-based, actionable collaboration built into the platform. Reviews are a formal, effective collaboration method that guides teams in fulfilling regulatory requirements.

Our customers use these capabilities to collaborate with external stakeholders. For instance, Jama allows you to invite reviewers simply by email (Jama licenses include more than enough reviewer licenses for this purpose). This works extremely well in practice. In fact, one medical device developer, RBC Medical Innovations, was able to shed hundreds of team-member days during development to save $150,000 in cost savings per project.

Firewalls, Policies and Processes are Preventing Collaboration

One concern that many organizations have is IT security. In order to collaborate with external stakeholders, your Jama instance must be made accessible on the internet, or at least shared with collaborators via a secure connection (e.g., a VPN). Even if this is possible, decision-makers may have concerns — justified or not — about IT security.

Further, the other party (i.e., supplier or customer) must be willing to accept Jama as a collaboration platform. As such, the same concerns around security must be addressed on their end.

Lastly, even if all parties are interested in collaboration, one of them has an advantage: the one who has chosen Jama Connect as the collaboration platform. After all, that party not only gets collaboration, but also takes advantage of the complete Jama platform for end-to-end traceability, workflows and many more capabilities. The other party – the supplier or customer – can only collaborate on the content that has been made accessible.

The Alternative: Controlled Data Exchange via ReqIF

Data exchange between organizations is nothing new, and many organizations have collaborated for decades, typically by exchanging documents. While this approach technically works, it results in unstructured data that provides no traceability, no understanding of changes between versions and no easy way to provide structured feedback.

The automotive industry, traditionally working with hundreds of suppliers, has been a pioneer in this space. It’s not unusual to find tens of thousands of requirements in an automotive specification, so managing these requirements is a challenge. In response, the industry developed an international standard for the lossless exchange of requirements called Requirements Interchange Format (ReqIF). The standard was finalized in 2011 and has proven so popular that every requirements management tool today, including Jama Connect, supports it.

A requirements exchange with ReqIF has some similarities to the old (and dreaded) document exchange process: One party exports a ReqIF file and hands it to the other party. The transfer can happen via a portal upload, automated exchange or even as an email attachment.

But here’s where the similarities end: A ReqIF file contains structured requirements data consisting of individual requirements with visibility into structure, attributes, related elements and traces. It is loss-less: The data and structures that you see in your product development environment (like Jama Connect) stay completely intact.

ReqIF also supports incremental updates. If one party creates another version and exports a month later, you could import that version into your environment and the tool would show you clearly which elements, attributes and traces have changed. For instance, you could use suspect links to re-validate only those items that have changed.

Collaboration via ReqIF

ReqIF is commonly used to solicit feedback from a supplier. A producer could export the requirements for a supplier, including attributes for providing status feedback and comments. The supplier would then import the ReqIF file into the tool of their choice, where they could fill out the supplier attributes and send the resulting export back.

In addition, they could start integrating the imported requirements into their own development system. For example, they could establish traceability from the customer requirements through to design while keeping the process invisible to their customer.

Image Source: IREB Magazine

There are other use cases that ReqIF supports as well, but for all of them, the foundation is a controlled asynchronous exchange of structured requirements that keeps individual items, attributes and traces intact.

What about OSLC?

When talking about ReqIF, Open Services for Lifecycle Collaboration (OSLC) is often mentioned as well. This is another standard, but one for connecting product development tools. It has some similarities to Jama’s REST API, in the sense that OSLC is also an API for connecting tools. While the REST API supports all activities of Jama Connect, OSLC only supports a small set of activities related to requirements. But since it’s standardized, many tools provide out-of-the-box adapters, including Jama Connect.

However, OSLC is not the answer to enabling cross-organizational collaboration between teams, suppliers and customers.

Bottom Line: How to Collaborate?

If you are using Jama Connect, the built-in collaboration capabilities are the most effective way to work together.

However, if you are working with people outside your organization, your customers and suppliers may not be able to collaborate using your Jama instance. In those cases, a ReqIF-based collaboration could be a great alternative.

Learn more about the benefits of upgrading your requirements management process with our paper, “Getting the Most from a Requirements Management Tool.”

 

Development teams need the most effective solution to manage product development complexity, but can’t afford to restructure their entire process and workflow.

That’s why integrating leading product development solutions like Jama Connect™ and Jira Software is the best answer. We recently explored some of the benefits of bringing the two solutions together in a recent webinar, “Managing Hardware & Software Product Development Complexity with Jama & Jira,” and wanted to share a few of the advantages with our readers.

The Document Dilemma

In the past, Microsoft Excel or Word may have done a passable job at housing requirements and specifications. However, even those who believe those types of tools were once effective have long since realized that they are no longer practical when it comes to complex product development.

It’s likely you’ve been there — staring at a worksheet with 100+ rows and 10+ columns of data. In an effort to add clarification, you also have a Word doc with a list of specifications. You send the documents via email for your team to read through, and then attempt to comprehend and submit actionable feedback that will impact the outcome of the entire project.

You dread getting the responses back because you know everyone has a different method for submitting feedback and version control will be a nightmare. Even with tools like SharePoint or wikis, collaborating via documents makes it impossible to get timely and actionable feedback from multiple team members in a way that maximizes efficiency.

The Answer: Database Solutions

Database solutions like Jama Connect and Jira Software ease the pain of managing complex product development.

These solutions are purpose-built to help you execute specific pieces of the product development lifecycle, and are known to outperform competitors in those functional areas. Here’s a quick glance at how the two platforms complement each other.

Jama Connect
Answers the questions: What are we going to build? Why are we building it?
Areas of focus:
The upstream definition process — making sure you’re doing the right things to successfully build the right product.

Jira Software
Answers the questions: How are we going to build it? When are we going to do it? Who is going to do the work?
Areas of focus: Task tracking and making sure those tasks are being completed.

Integrating Jama and Jira Creates a Juggernaut

Bringing together Jama Connect and Jira Software allows you to work in the solution that best fits your workflow, not the other way around. They are both flexible solutions that adapt to your process — whether that’s Waterfall or Agile or something in between.

They can also be used together in a variety of industries and applications, from semiconductor to medical, from aerospace and defense to automotive, and even IT organizations building strictly software projects.

Jama Connect is used for business objectives and epics (i.e., requirements), as well as status and relationships in the stories phase. It puts all the content in one location so the versioned document dilemma you’ve experienced disappears. Within the system, you can:

  • Collaborate with ease using communication and review capabilities
  • Seamlessly capture and manage decision history and version control
  • Ensure requirements are tied to test cases with coverage analysis upstream and downstream

To complete the loop, Jira Software tracks tasks and progress. It’s the bidirectional synchronization between the two systems that allows you to maintain consistency and alignment throughout the development process.

Defect Management: An Integration Use Case

The integration between Jama Connect and Jira Software is also a powerhouse when it comes to defect management.

In addition to capturing requirements and specifications, Jama Connect also employs test management and houses the tests planned to validate those requirements and specifications.

If tests fail and will create a defect as a result, that information is passed to Jira Software for those defects to managed and fixed.

Furthermore, team members who work in Jama Connect can change the priority of a defect in that system. The information is then available to team members who work in Jira Software. Team members working in Jira Software can continue doing their burn downs and execution, with visibility into where the defect originated and what high-level requirements might be impacted.

By integrating best-in-breed solutions, day-to-day users of each specific software don’t have to bounce back and forth between different tools or change their workflow or process. Yet they can still benefit from sharing the necessary information between both solutions.

A Closer Look

We get many inquiries about Jama’s integrations, and most frequently they involve Jira Software. To hear more about the key benefits of using these two first-class product development solutions, watch our webinar.

The Jama Support Community is a forum for Jama Software users to interact and collaborate with other users and with Jama support engineers. It’s full of resources for everyone from novices to masters, including tutorials and webinars, help guides and FAQs, feature requests and announcements and a robust knowledge base. For today’s post, we spoke with one of our Jama Support Community power users — frequent contributors with great questions and powerful insights into using Jama — about how their organization uses Jama and the value they’ve seen from the Support Community.

Harald Hotz-Behofsits is a product owner at Frequentis AG, an Austrian tech company with staff in 50 countries. Its core business is mission-critical software for the air traffic management sector, but Frequentis also builds voice communications and information systems for defense, public safety, public transportation and the maritime market. After graduating from university, Hotz-Behofsits worked in the Austrian office of Scientific Games until joining the team at Frequentis in 2001.

As a product owner, Hotz-Behofsits works on an agile software team tasked with developing mission-critical software in accordance with international standards. His team needs a product development platform that generates documentation to support traceability from requirements to design to test cases to test results.

Frequentis relied on IBM Rational RequisitePro until 2012, when the team grew “quite unhappy” with its drawbacks, says Hotz-Behofsits, and began looking for alternatives. Jama Software popped up on the company’s radar early on, and in June 2013, Hotz-Behofsits became Frequentis’s first Jama Connect user. Five years later, Frequentis has about 400 projects in Jama Connect.

Hotz-Behofsits cites Jama Connect’s “intuitive user interface” as one of the things he likes most about the platform: “It’s easy to get new people on board,” he says. Hotz-Behofsits’s team uses Jama’s REST API and Jira integrations and makes heavy use of Velocity reports. The team also exports data into Office templates. Jama Connect’s Review Center, Hotz-Behofsits says, gets “daily use,” with what he estimates are 5,000 to 6,000 reviews. Review Center gives teams context and visibility by illuminating the relationship between stories and activities. In addition, Review Center helps teams achieve traceability by demonstrating what happened and why throughout the product development process. Hotz-Behofsits also relies on Review Center to understand how defects have been detected and addressed during the development process.

Hotz-Behofsits uses the Jama Support Community for “inspiration and innovation.” “By sharing solutions,” he says, “everybody gains.” Questions asked by other users, he says, can spark new ideas. When users share their insights or workarounds on the Support Community, everyone has the opportunity to experiment with and even improve upon others’ solutions. Just as the Jama Connect platform empowers collaboration between stakeholders and across teams, the Support Community allows users working in different roles at different organizations to collaborate on how best to leverage Jama for success.

As a seasoned Jama Connect user and a regular presence in the Support Community, Hotz-Behofsits recommends that new users of the Jama Support Community start by querying the existing content, since the chances are that at least some of their questions have already been answered.

Hotz-Behofsits would recommend Jama to a colleague who needed to manage requirements, test cases, test activities, traceability and – “of course” – the review process. For Frequentis, Jama Connect has become a crucial platform for achieving traceability across requirements, clarifying work order (i.e., why something was changed when), and reporting and addressing defects.

Connect with Harald and other fellow Jama users on the Jama Support Community.