[mr-ron]

What is normal about this that Ive seen is work and tickets is often written into controls that are required for things like SOC compliance. And documentation often requires a pull request.

And again read what I said, that engineers can and could be empowered to make these tickets, which can be minimal at best.

Done right, its not a limitation at all, and instead adds accountability.

[knightofmars]

"...things like SOC compliance." This is an important point. If you work in a regulated industry or work with software used in a regulated industry you need a "paper trail". Having to document and follow a process is often frustrating to people who work or have worked in industries that don't require it. That said, a poorly implemented process in a regulated industry is even worse. As you're overloading teams with busy work and likely still failing to meet the requirements of the regulations you're following. Regulated software is not a place to "move fast and break things" that's what prototypes that never see the light of production are for. Build it without regulation to figure out how to do it and then build it again following the documentation process. It may sound odd but having a second chance to correct errors of assumption from the first time around is quite valuable, buying information when done right is a great tool.

[mr-ron]

SOC compliance is indeed a beast. I have my own theories on how valuable this benchmarks REALLY is, but if teams are in a financial org, it is super common to have controls that have the potential to really hamstring teams.

Which is doubly important to really understand the vision of agile / scrum, and not just follow the ceremonies by the book.

[sanderjd]

Could you point me to where in the regulations it says you must have a duplicate paper trail? A PR is already a paper trail...

[rleigh]

A PR is most emphatically *not* a paper trail.

It's recording a software change, who made it, and when.

That isn't even close to the bare minimum for some of the regulatory requirements.

You're coming to this with the perspective of a typical software developer. I can sympathise greatly. But the regulations aren't about software development. They are about risk management and product quality, and putting in place processes to ensure projects deliver solutions which are safe and robust, due to having the appropriate controls in place. This isn't just about the software implementation. It goes all the way up to the specifications, designs and requirements and it requires testing and validation work at every level.

I have only in the last few years been working in such an environment. It was eye-opening. Compared with the free-for-all which is most software development, this is actually about engineering robust systems, in a very systematic and rigorous way. That does include some overhead in the processes surrounding the development work, but it's there for a very good reason.

[sanderjd]

I'm very familiar with this kind of compliance environment. I spent quite some time working on a committee focused on similar issues (privacy requirements in my case) and I certainly understand the value of auditability and the existence of requirements like this.

We are talking in this thread about a very specific subset of this: Does it make sense to require a Jira ticket for a change to internal system documentation.

I don't have experience with SOC in particular, but I would be very surprised if the regulations specified "you need a Jira ticket for every change to every kind of documentation". That would certainly be a very big lobbying win for Jira! But I suspect it is more like "you need to be able to audit and trace the purpose of all documentation changes". The trick in designing the processes used to comply with such requirements is figuring out how to balance compliance with process friction. If you are in charge of this sort of thing and your instinct is to never challenge the usefulness of busywork and ignore feedback on its impact, like the kind of feedback in this thread that is being ignored, then you are not doing your job well.

[eropple]

> Done right, its not a limitation at all

Context switches are limiters, IME. Smash somebody's stack and you've made them useless for half an hour.

[mr-ron]

This is why tickets can be used to protect the engineering team. You dont want people ad-hoc adding scope, or interrupting work for engineers.

You want engineers to have focus time, on a clear actionable item, that is set up for success, and will add value.

Allowing engineers to work on whatever they want, or change scope on what they want, without saying 'why', can end up creating a lot of wasted work.

[eropple]

Tickets can, theoretically, be used to protect a development team. I agree with you there. But they usually aren't, and most folks are living in the land of what-is, not what-can-be.

[mr-ron]

Yes I agree and thats why Scrum / Agile gets a bad rap around here.

[ozim]

Even not SOC compliance just liability of a company.

If stuff fails and company gets sued - they will have to prove that they "follow industry standards" because if they don't follow industry standards then all kinds of bad stuff can follow.

IF you get ransom-ware and have an insurance - see the exclusions - you have to have EDR software on each server otherwise insurance won't pay.

Not following industry standards in terms of code - the same no insurance company will pay if they catch you on just doing stuff.

So running a business all kind of BS and it is not optional and just slinging out code is not enough.