Hello.
This is a post about friction and process and
I work as a senior developer at a company (made up of hundreds of people from 20 different cultures) that have been around for about 15 years and are now expanding into markets that are subjected to some fairly heavy compliance and certification laws. We are at the same time starting on a Continuous Delivery journey (though i don't see how that is going to work out since the CTO thinks that; quote: "Agile is just like mini-waterfall and I don't feel in control so we must do SAFe." and on top of that the attitude among developers is pretty much "testing is for testers, not developers").
As a sidenote: we are not making passenger jets, nuclear power plants, medical equipment or similar "people may die" things. There is however lots of money involved...
The issue
I have had this exact conversation with; compliance officers, CTO, architects and many more:
They: You must enter a ticket in Jira for every change you make.
Me: Does that include refactoring, improving the design and keeping the system updated and in a good state?
They: Yes, everything must be approved, scheduled, signed-off and have a ticket in Jira.
Me: Why do you need to have a ticket in Jira for everything? What values does it add?
They: Traceability (who did what, when and WHY).
Me: Version control gives me all that: Who did it, exactly what (in intimate detail) and the commit messages explains the how and why!
They: Everything has to have a ticket.
Me: But...
They: ...
Me: Ok, what value does it bring?
They: Traceability.
Me: What value... ah, forget it...
As this is happening our team are doing TDD, (starting out with) ATDD/BDD, pair-programming, strict version control, documenting functionality and compatibility, never let anything fall into the "legacy pile" by making sure we are keeping things up to date and releasable, working on a way of generating release notes automatically (aggregate changes, commits and test-reports between versions and uploading to ftp/wiki). These are all things that the team are imposing on themselves because we can see the value and how it benefits us.
From my point of view I can understand the need to figure out why something went wrong; to learn from it and do something about it so that the probability and impact for future failures is reduced. But it feels like what is happening here is a case of the people that are not actually doing the work are trying to assert control over the people that do. This probably stems from the fact that they don't understand how work actually works (but think they do) and feel uncertain about it. It seems like a local optimization; to make their life easier by telling us what to do instead of talking to us about the underlying need and reasoning and then let us figure out how to best provide that value in a way that benefits us both (there might a better way than tickets in Jira).
How do you deal with it?
How do you deal with compliance in an organization where there is little trust (in peoples skill) and the people in "authority" leans more towards rules and Theory X rather than Theory Y? I still haven't had it explained to me what the value of traceability is; except "so I know who to blame and punish" not realizing that accountability is not about "blaming for failure" - it has more to do with clear communication, learning from mistakes and promoting transparency, honesty and trust than it has to do with punishment.
So what real business value does traceability and "everything in Jira" provide and how will this even work in the context of Continuous Delivery?