Tag Archive for: communication

Traceability

Editor’s Note: This post about how traceability improves collaboration and decision making was originally published here on DevOps.com on September 23rd, 2020, and was written by Josh Turpen, Jama Software’s Chief Product Officer. 


Jama Connect® creates Live Traceability™ through siloed development, test, and risk activities. Provide end-to-end compliance, risk mitigation, and process improvement with our intuitive, award-winning platform.

Minimize the risk of delays, defects, cost overruns, and the manual effort created by fragmented development processes and legacy solutions. Learn more!


New software is being developed at an incredible pace to help make our lives easier. This doesn’t change the fact that humans are still held accountable for product development decisions, whether these are made with or without advanced analysis tools. To make informed choices, product development professionals need tools that allow them to see comprehensible information in real-time as change is happening, both within the team’s structure and throughout the system in which their product exists.

Modern traceability makes it possible to both manage and respond to change in a systematic, auditable and confidence-enhancing way. Below, we will discuss three ways traceability has evolved to support key decision-makers in a number of industries.

Modern traceability captures when you make a decision

Decisions often have varying levels of durability. Sometimes, when you make a decision, you know then and there it’s final. Other times, you make what seems to be a minor choice and you end up dealing with the repercussions for years to come. With this level of uncertainty, it is essential to have mechanisms that allow you to see when decisions are made. As I discussed in a previous article, “5 Ways Traceability is Changing to Bolster the Remote Workforce,” this process can be compared to a map. By leading a team through every step of their processes, modern traceability helps product developers reach their goals without any surprises.

Often, products are expected to be maintained for years. This is significantly more challenging when you can’t properly track where a ruling originated or a change was made. While the team may move quickly in the development process, the record should always live on to provide future context where it’s needed.


RELATED POST: How to Realign Engineering Teams for Remote Work with Minimal Disruption


Modern traceability provides people the context of what they’re working on as they go, not after the fact

Rather than rely on sharing often lengthy and disparate documents or running time-consuming general meetings, traceability allows teams to streamline their collaboration. Mapping out work items, including owners and contributors, gives people a reason to care and to trace those items carefully. It helps everyone know why they’re there, what they are discussing and how to address it.

Many smaller companies are fortunate to get by using Word documents and other legacy tools for their traceability measures. However, as these companies grow, so do the complexities. That’s why traceability has been evolving to account for the multi-dimensional nature of requirement, test and risk management. For a company that is seeing major growth to be truly successful, all related variables must work together continuously, at scale and across teams. Legacy tools simply do not provide the agile capabilities that modern traceability does.


RELATED POST: Requirements Traceability – How To Go Live


Traceability captures and tracks past decisions and allows users to access them

Traceability is all about relationships. Each product in development has its own particular set of customers, stakeholders and internal team members associated with it. Therefore, traceability is only possible if these individuals can be accurately connected to the items for which they are responsible.

Knowing who made a decision and what information they accessed is equally as important as the information itself. If you can’t quickly piece that together, your traceability is incomplete. The responsible thing to do is to ease the process by keeping useful records. It doesn’t need to be forced behavior if it’s captured along the way as a byproduct of doing your job.

Overall, accountability is incomplete and past decisions can’t easily be seen, learned from or built upon without robust, modern traceability tools. It’s much harder to legitimately hold someone accountable when they’re working in the dark. However, when done correctly, traceability can be used as a key tool to support genuine liability and allow for a streamlined process of complex decision-making.


Download our eBook to learn how optimize product development with strategic team collaboration.

DOWNLOAD NOW



communicating-change-blog-featured-image

Changing how your teams work is hard.  In my previous post, I covered the first three of my learnings in my time as a Strategic Customer Success Manager at Jama.  I’m now going to fill you in on how to approach communicating about Jama to your various stakeholders.

We all know we need to communicate, but communicating about change needs to be thought through.  It’s not enough to post a broad scale notification on the company’s intranet and hope that readers can “right-size” this information and accurately apply it’s meaning to their roles.  Do everyone a solid and think through the various categories of people who need to be brought up to speed and spoon feed them only the information they need to digest.

To do this correctly, this needs to be done in advance – then actually executed. I say this because once the process of rolling the tool out begins, things get muddy and you will forget to notify folks in the way you’d envisioned.  Think about each group of people you’re communicating with.  In my experience there are several groups:  leadership, those creating requirements, stakeholders, etc.  Some of these people will be defined by Jama license type, some will not.  Tell them what they want to know.  For example, how you communicate with your leadership will be different from somebody who will be simply reviewing and chiming in on requirements.  Below is an example of what I’m talking about.

Communication Plan

Audience Responsibilities Interests and Concerns What do they need to know? Communications Methods
Business Analysts
Product Owners
  • Define requirements in Jama
  • Execute user stories
  • Define high quality requirements quickly
  • Understand how best to leverage Jama to capture requirements
  • Obtain high quality requirements to build software
  • Have all of the information needed to build a story available in one place
  • Understand how best to leverage Jama integration to support development process
  • Ensuring stakeholders and dev teams are bought in to the new process – don’t want resistance to change to increase workload (e.g. business not willing to use Review Center, so stories have to be exported for review)
  • Don’t want to have to spend time in additional tools to get context for scope
  • Maintain momentum of use of new process – ensure teams can execute independently following new approach
  • Provide support to help teams navigate through challenging issues
  • Keep community abreast of key technical events (upgrades, enhancements, etc)
  • Improve individuals’ skills to allow them to become coaches themselves to develop competency in their peers – coach the coach
  • Affirm value
  • Team meetings
  • Intranet posts
  • Stand-ups
  • Individual reach outs
  • All hands meetings
Leaders and Management
  • Managing portfolios with multiple projects
  • Planning and funding products and projects
  • Reporting on progress and delivery of their products and projects to the organization
  • Achieving higher ROIs
  • Delivering more business value faster
  • Reducing costs of development and delivery
  • Maintaining team satisfaction
  • Very little time to meet or read e-mails
  • Need high-level, executive style overviews (don’t want all the details)
  • Investment in change is working
  • Products are getting out the door faster
  • Number of released defects are decreasing
  • Rework is decreasing
  • Intranet posts
  • Individual reach outs
  • Emails highlighting ROI improvements
Stakeholders and Requirement Reviewers Review requirements and provide feedback Don’t understand why they need to change how they provide requirement feedback
  • How to work with the new process and tool
  • Affirm value of new process and tool
  • Team meetings
  • Intranet posts
  • Stand-ups
  • Individual reach outs
  • All hands meetings

Another wrinkle of the communications plan is to think through the cultural norms and politics at play in your organization.  Actually think about the order of communications and who needs to know what and when.   Are there influencers you need to hit one on one?  Perhaps there is a member of the team part of the old guard who needs to be spoon fed information.  Don’t fight it – account for it and assure they get the information they need in a way they can digest it.  And don’t forget about external resources – partners and consultants that are helping you bring your products to market.

The last important thing I’d like to share with you about this is to share your wins widely.  Make your improvements and advancements in your process public knowledge!   Even small improvements in your process can have dramatic results over the long haul, so talk it up.  And not just in your team meetings and stand-ups either – be sure leadership is aware their investment is starting to bear fruit.  Not only will this garner goodwill with your management, but it will encourage further adoption and help silence latent naysayers.