Until recently, manual traceability from compliance reporting has held back large organizations from becoming software innovators. Now, enterprise toolchain integration is helping organizations across heavily-regulated industries, such as healthcare, automobile, finance and government, to automate the sophisticated flow of work from ideation to operation, helping them obtain one source of truth into a product’s development.
What is traceability in software delivery?
In the current world of enterprise software, traceability is the holy grail chased by many organizations. However, traceability can also mean very different things depending on who you talk to. For QA engineers, traceability will mean ensuring the completeness and thoroughness of the testing process. The expected result will be the ability to trace requirements with test cases, cycles, plans, resulting defects, etc. For system engineers or business analysts, any discussion of traceability will revolve around traceability matrices which will also tie into the testing pieces. For automation engineers, traceability will be more focused on the pipeline health and visibility into what’s happening there – learn more about different approaches to traceability.
For many organizations, traceability is not a choice but a must-have as they are heavily governed and possibly audited. Consider the medical device industry and what it takes to have a new device approved by the FDA: to receive regulatory approval, organizations must provide clear traces of requirements throughout their development lifecycle – not just initiation, but also through execution, testing, and maintenance. Consequently, it is crucial to provide proof of what work is being done and where this work goes.
Why is traceability important?
Imagine a world where you knew what goes into your releases, when work is being released and you had true traceability of work from the moment it originates regardless of the origination source to the moment it’s released. You could have many different reasons for needing this:
- Your organization is heavily regulated and audited that requires strongly documented proof of why any work is being done
- You have hundreds of teams building features and you want to be able to tell what features are delivered in what releases
- You want to have team level visibility in what work is being completed and when
A brief overview of how to get there
Your journey to end-to-end traceability is all about tracking where work originates right through to delivery (and back through the customer feedback loop). To be able to do this you first have to start by understanding where you’re at. You need to have a good picture of how the work actually is getting done to be able to make improvements and connections and introduce processes and functionality that will help.
These are key questions to ask yourself to begin understanding your entire workflow:
- Where does work originate from? Typically, work arrives as features, epics or service tickets and maybe even security vulnerabilities
- Where does it go? How does it get to developers to be worked on?
- What’s the development process?
- What is the release process, how are features released?
Consider building out a diagram, we refer to these as Value Stream Architecture diagrams. They help us to gain a general overview of how work flows through the organization. It’s a very simple view but extremely powerful when it comes to having deeper conversations about the process at hand.
Once you have a good understanding of where you are at, we can begin introducing elements that will help with the overall traceability goal. The way I’m going to be going about it is from a software delivery circle perspective on the right.
Most of the stages in the circle should be self-evident as to what they are. For full clarity, when I refer to the Plan stage I am including anything from writing requirements to planning your sprints.
The core pieces to achieve traceability are:
- Be able to collect data from every stage of the process and
- With every stage of the process, pass along a piece of information about one of the previous stages so that the relationship between the stages can be determined
Let’s expand the software delivery circle to understand what I mean by the above two statements:
With every step in the software delivery process, I will be making sure to get a piece of information about this step, as well as a piece of information about one of the previous steps. For example, let’s just look at the Plan and Code pieces:
- I am going to be collecting information about the work items that the development teams are working on from the work management tools and
- When the developers submit code, I will collect information about those code commits, as well as for what work items the code commits relate to (to point back to the previous step in the process)
I will then have information about the two steps in the process and with each step, a reference to the previous step. If you examine the above picture further, you’ll see that it’s the same concept is repeated for the rest of the software delivery process.
Take a deeper dive into building end-to-end traceability
The many benefits of automated traceability
Automated traceability provides visibility that was previously not achievable without a ton of effort. Now you can answer those key questions from before: where does work originate and how does it flow throughout the process.
On top of that, it’s worth noting that there are many other side benefits you and your teams can take advantage of:
- End-to-end integration will eliminate duplicate data entry and avoiding data errors by automating your manual steps.
- Your users don’t have to copy and paste information between various systems, thus, the human error is taken out of the picture as well as delays introduced by manual “keeping systems in sync”.
- Ability to scale – while manual creation of traceability is possible, it would be unattainable at the scale of any organization with over 500 software professionals
- Ability to trace issues – avoid manual steps needed if a compliance problem was discovered or if an audit turned up a problem. Creating such a report may take 2-3 weeks to produce manually, it’s essentially out of date by the time it is done.
- Also, In our experience implementing traceability with large companies and government agencies, I can say that putting in the work yields some dividends not only in the form of achieving traceability but also in improving employee happiness. For example, compliance was so important to a department in a top 10 bank that it used two experienced and senior managers to do nothing but walk the floor, asking questions, making notes in spreadsheets to manually create a portion of the requirement-test-defect traceability report you see above. They couldn’t use less experienced people because you had to deeply understand that the software development process and the relationships across teams. When asked how much time they spend each week on this, they indicated with disdain that they spent 80% of their work time filling in spreadsheets to manually creating traceability reports and the other 20% hating their jobs.
Benefits at various levels of the organization
For practitioners:
- End-user traceability – if you allow for the quick wins and enjoy the side benefits of this large endeavor, you can ensure that even your end-users gain for their day-to-day. For example, years ago, when I was a product manager for Tasktop’s development teams, I used to look for review links on Stories to see if a certain piece of work has been merged into the master so I could grab a nightly build and start signing off on the dev work – all without having to bother anybody or wait for our developers in Vancouver to get online 3 hours later. See an example in the next section.
- Remove manual duplicate data entry – I don’t think much comment is needed here, ask anyone if they’d rather have the hours back they spend duplicating data
For managers:
- If you’re responsible for multiple development processes and pipelines, this same approach can help you have cross-system visibility in one single place. For example, for an automation team manager, you can start viewing your release and build health across multiple systems in one place.
- Tedious manually built reports can be a thing of the past – if you’re currently responsible for collecting data for reports and you’re having to manually collect pieces from many different sources. This can help alleviate some of the delay and errors due to the manual aspects of data collection
For executives:
- Time, cost savings from automating previously manual processes – this will enable your teams to work on true value add features for the business rather than manual work e.g., duplicate data entry
- Avoiding audit/compliance issues by producing more reliable traceability reports
- Collecting the data in this way will allow you to have deeper levels of information for the investigation of issues. For example, if this is all done manually, there is no reliable way to backtrace to the core issue point
- Increased confidence that the quality of the traceability reports will actually stand up to an audit or a compliance check
Customer Success with Automated Traceability
Hear from Erik Knutson (Build Engineer, Federal Reserve Bank of Atlanta) and Karlis Broders (CTO, AA Projekts who work in the government space) on how their simplifying end-to-end traceability with automation and integration in the below webinar:
Let us help you make traceability as easy as possible
Start your journey with a one-hour design session with a Tasktop Value Stream Architect to make your software delivery work more visible and traceable.
