Is your JIRA Workflow putting your business at risk?

I recently stumbled across Clint Gibler 's excellent summary of a presentation by Alexandra Nassar titled "The Art of Vulnerability Management" in which she describes the challenges she faced in improving the vulnerability management process at her company and her approach to resolve the process issues.

TL;DR - She built a custom JIRA workflow to bring transparency and measurement to the vulnerability management process.

Of course, it's never really that simple, there's a lot of effort and groundwork that needs to be done before jumping in to build a new JIRA workflow. And that's where Alexandra's presentation shines as she shares the discovery process and steps she followed to build a successful vulnerability management process:

First, Understand the Lay of the Land

Before trying to build a new workflow or fix a perceived process problem, it's important to fully understand the existing process frameworks that are in use, how people feel about them, as well as fundamentals like where the data lives and the tools people use.

Next, Determine How the Workflow Should Work

When designing a workflow, it's important to consider real-world case examples, both common and edge-cases, and apply them to your workflow design to ensure that the new workflow is capturing all the necessary attributes and state possibilities.

Then, Measure - Build Tracking Dashboards

Transparency is key to all Agile processes. We can't inspect nor adapt to what we can't see. Make the workflow visible with a tracking dashboard that provides the high-level data you need to further improve the tools and processes you're managing.

Finally, Driving Cultural Change

This is such an important step it's hard not to scream it at the top of my lungs. DRIVE CULTURAL CHANGE! You've introduced new tools and new processes, but the job isn't done. You have to communicate the change and work to gain acceptance. Make people feel included in the process, get feedback and respond to it. But most importantly ensure everyone knows why the change was so important, how to execute the process properly, and what the expected outcomes will be.

So what? A summary of a summary of a presentation from 2019? What's the value add?

I want to take a moment to step back from the specifics of Alexandra's presentation and Clint's summary to look at the big picture and the value I'm trying to add to the conversation:

JIRA is a double-edged sword.

It can help you, or it can hurt you, and which one it is depends entirely on how careful and thorough you are in understanding the needs of all the users and stakeholders of your development process, how well you lay-out and design your JIRA workflow, how you measure your progress and success, and how you drive the necessary cultural change to ensure compliance with the process.

An unfortunate number of companies seem to launch JIRA with little to no user training and spend all of about 10 minutes thinking about what the workflow should look like or how to measure progress, then only add or change process workflow in a piece-meal way as they run into inevitable problems or come up with band-aid solutions outside of JIRA like excel tracking docs to make-up for missing process functionality.

Process is important!

This is not about creating more process or making existing process more rigid or onerous. Good process should feel effortless and invisible. I think the reason many people hate process is because they only notice it or think about it when it's bad (and it often is very bad). When process is good, you don't even really notice or think about it much. It stays out of your way, as it should.

JIRA is just a lump of clay.

JIRA won't define your process for you. But at the same time, when you use JIRA, you are inevitably part of -a- process that has been defined in some way, in some cases by default settings or by some remote admin who doesn't know anything about what you or your team need. JIRA is just a lump of clay that needs to be moulded into a vessel that holds water.

JIRA is powerful because it is so highly customizable. If your JIRA process is painful and broken and issues are getting dropped or lost somewhere, this isn't because JIRA is a bad tool (it is bad, but for other reasons not elaborated here). The reason it is broken is because you haven't fixed it. This is the big lesson from Alexandra's presentation. She found a broken process, analyzed it, designed a solution in the form of a newly customized JIRA workflow, and drove the necessary cultural change to implement the process.

Cyber Security is everyone's job.

A leaky, broken JIRA process or workflow can result in un-patched software vulnerabilities or delays that can put your company at risk. In Scrum we like to say: "Scrum won't fix your problems, it will show you your problems. You're supposed to fix it!" This goes for the processes as well, if you see a broken process fix it! It might even prevent a cyber attack!