We hear a lot of interest around how Jama Software integrates with other product development tools.
Using Jama to manage requirements and JIRA to monitor tasks separately is a viable solution for many product companies. Those forward-thinking businesses who take advantage of the powerful integration between the two see much stronger management of complexity, traceability, requirements and progress tracking.
For a deeper explanation, we recently held a webinar, “Managing Hardware & Software Product Development Complexity with Jama & JIRA.”
In the webinar, Mike Frazier, Principal of Frazier Executive Consulting, and Kevin Andrewjeski, Senior Account Executive at Jama, walked through some of the key benefits of a Jama/JIRA integrated system.
Learn more about the benefits of bringing these two powerful solutions together in our post, “How Combining Jama and Jira Improves Your Development Process.”
At the conclusion of the presentation, Frazier and Andrewjeski fielded questions from those in attendance. Below you’ll find a slightly abbreviated version of the question-and-answer session. Learn more by watching the full webinar.
Q: We want to start using a more agile approach or more agile methodologies. Do Jama and JIRA support an agile methodology?
Kevin Andrewjeski: Jama, as a tool, is process-agnostic. We have customers that are very Agile — internally we use Jama in an Agile way. Also, we have customers that are hardware-focused. And then, of course, we have folks that are blended with hardware and software, with waterfall and Agile mixed in together.
So the tool is very configurable and flexible to fit into your preferred process rather than having your teams try to fit into some kind of a process that we are identifying for you.
Mike Frazier: To add to that, from a transition perspective, at Xilinx we used a waterfall approach for IP development. It might take a year or so to build out a brand-new piece of IP. But then, as we iterated that product — typically Xilinx would release its software on a quarterly basis, and therefore our IP could be updated on a quarterly basis as well — we decided to use Agile for some of those “incremental releases.”
What that did for us is it helped us do smaller chunks of work in a more predictable, smaller amount of time for those quarterly updates.
Now, I will caution companies about how it does require a mindset change, as I’m sure there are those of you that have transitioned from a waterfall approach to an Agile approach. It’s not at all classic, like a waterfall approach.
It requires people who need to be trained on what it’s like to develop an Agile environment. And if there are people within your company who are Agile program managers, take advantage of that.
If not, take advantage of companies that can help you develop your Agile skills. It’s not something you should do without being aware that it does require a shift in mentality for all the stakeholders involved.
Q: Product managers and systems engineers are the obvious targets of the requirements management tools and processes. What about the rest of the engineering team? Architects, designers, developers, for example?
MF: The beauty of it is if you use a tool like Jama to capture your requirements, and you’re soliciting input and feedback throughout, and using some of the abilities of the tool throughout the requirements capture process, and you’re engaging with your architectural team, potentially all the way down to lead level engineering teams, it creates more of a sense of inclusion. And it also creates that collaboration and communication.
I think maybe the typical thought process people go through is you create a marketing requirements document and you “throw it over the fence” to engineering for feedback.
What tools like Jama will do, as long as you include the appropriate stakeholders from not only engineering but other downstream organizations such as production or operations, and other organizations that typically aren’t involved in the requirements management process, you’re going to get all of that stakeholder feedback earlier in the development cycle and minimize surprises. So I think it could be used for all aspects of the organization.
KA: To add on to Mike’s comments, from a Jama perspective, it’s a way to encourage collaboration. So you may have core users in marketing, engineering, depending on your structure, that are really the people creating these requirements and managing these requirements but you might have a broader group of people participating in providing feedback and a clarification.
And so those users, that we term as collaborators, can actually participate in the system without a paid license so that you’re really encouraging that feedback and collaboration, especially cross functionally, with the ultimate goal of making sure you’re building the right product.
Q: Can you speak to some of the training, some of the education that you offer on how to create effective requirements?
MF: Jama does a very good job offering white papers and other information around how to capture good requirements. And then there are companies in the industry who focus on requirements management and product portfolio management as part of their offerings.
Me, personally, the way I get involved in requirements management with my clients is typically during the product development lifecycle. Most of my clients are looking for help on the front end of the development cycle, where they’re struggling with a scenario where you have one-third of bug escapes due to poor requirements.
Q: Does Jama provide a solution for the Jama/JIRA integration?
KA: Yes, the Jama to JIRA integration, as well as Jama to other tools, is something we sell directly. The technology itself is from a partner, not something we create internally. But if you buy it directly from Jama, we can help you get configured and installed as part of the implementation of Jama, so they’re coupled together.