Are you in a position to make changes to the deployment stream? For example Git can be set up so that all changes to master have to go through a pull request. Alternatively are you in a position where you can formally or informally punish people for failing to follow the processes in place?

While I'm thoroughly in support of good development practices, what actual tangible issues are being caused by this?

@LeeAbraham I have Gitlab admin access so could do that. That wouldnt prevent rubber stamping though. I could informally shame them by blaming them for the extra bugs in planning.

@PhilipKendall yet to have a release which doesnt require a hotfix within a day. A lot of the developers are new so they have no idea how things interact.

You might be able to do something around multiple "production" instances, though, so that at least demos can be isolated from the place all your existing customers live.

Are you saying your product owner, scrum master and other developers are pressuring you to not follow the proper procedure? That's pretty much the exact opposite of what people should do in each of those roles. Why are random salespeople, or any salespeople, communicating directly with the developers?

@Fildor: sure, if you only like working for large organisations. In a small company I would find it weird if various parts of it are forbidden to even speak to each other. But I certainly wouldn't find it weird if salespeople are forbidden from arbitrarily upsetting other people's projects!

@SteveJessop I have been not precise enough. "Approach with requests" I should have written. Agreed.

@Fildor: The set-up I work in (100-ish employees, 9 developers since we're not primarily a software company) is that sales can approach a developer to discuss anything, and even to request a proposal is considered. That developer then might decide to steer the proposal through the dev team as a whole, or might decide to tell that person to go back to square one and make the proposal directly to our Director. I don't think any harm is done by this, other than we have to allow developers a certain amount of slack time for kicking ideas around (which we think is worthwhile anyway).

The main thing that constrains this from becoming chaotic is not about closing down what sales are allowed to try, it's about impressing that when the dev teams says something can't be done, that means you have to suggest something easier instead. Hence the request is, "what can you do by tomorrow", not "do this by tomorrow". But we have senior management who trust us to know what we're doing, and the questioner doesn't, so to my mind that's the important difference.

@SteveJessop Of course, this also depends on the compay's processes. In a SCRUM environment, though, I consider any direct access of this kind a breach of process. Yes, if it's a "hey, would x be possible to do?" May be a valid interaction if it does not consume too much time. But anything larger than that should go through PO. Now if you do not implement SCRUM or found your way to do no harm or adapted to it - that's fine of course. I only have experiences with this to go out of hand and disrupt development significantly.

Yes, good point. We did not adopt Scrum precisely because we considered strict sprints too restrictive, and we didn't want to build in massive slack time or under-forecast as contingency against some very valuable short-notice project coming up (which at the time happened at least every other week, so it's not like this would be a rare event that justifies abandoning a sprint). We've been through a series of scale changes, though, and we are now at a point where we could have people on sprints if we wanted. Everything goes through the PO, it just doesn't necessarily start there.

This is so common - by far the norm - in software, that, it's confusing to not preface the whole issue with that concept. Let me make an example. There are many articles in running magazines: "How to deal with blisters." But. If someone wrote "Surprisingly, when running, I get these things called 'blisters' .." it is just very confusing, and leads to confused discussion.

How big is your software group? We had software quality engineers that enforced the policies. They were also supposed to help with reviews, but they were often not qualified to review the code.

It would never work for such a transparent boss, He is passing on all the pressure to the team. It should be his job to deal with the superiors. Nothing you can do will fix this problem.

I'm on the other side of it Eric. So many processes and red tape that by the time code I've coded, unit-tested, peer reviewed, tester-tested, deployment-team deployed -- it's been 6 months and I've coded 20 other things between and cannot recall anything about the code when issues come up. Be grateful you're part of a team that trusts you to do the right thing, that even allows you freedom to choose what you want to do...because it's not all rainbows when there's a process and everyone's following it. The process becomes abhorrently slow imo.

How long does it take, and how much effort is it to follow the correct procedure? Are people saving seconds, minutes, hours, or days by pushing straight to production?