Bad experiences: Compliance, certification, trust and processes

[Devminded]

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?

https://twitter.com/devminded

[Rajwinder Makkar]

My 2 cents :

To make a transformation in such a organization 

1. U need support and clarity from higher management 

2. U need trust of delivery organization (developers) on the team which is going to implement CD. Trust could be created while doing anything with them not necessarily cd/agile/ci or dev ops related.

3. Allot of patience.

4. External consulting firm who can evaluate ur current process and guide organization on "what" needs to be done for CD.

If after all this things dont work then probably either the company is not in a very competitive market , dont need quick time to customer and can live with water fall and old methodologies so dont bang ur head look for dice.com or similar , that way every body will be happy ;-)

-raj