How to stand ground when colleagues are neglecting the process?

Question

The problem I am facing:

1. My team members start working on projects without the functional/technical documents ready - even if our company process dictates these should be there before starting.
2. My team members accept cheap, unstructured solutions and will implement really bad hacks into software without thinking twice when project management notes they have 'limited time'.
3. My team members start working on projects that work together with an unfinished project from another team - which is untested and unfinished. (causing alot of extra work).
4. Improvements and entire phase(s) of software aren't properly planned, and often result in front-end / design is not finished when the back-end developer has to start work.

These problems have been discussed endlessly for multiple times since I have started working here. Everyone agreed and the bottom line was that we must enforce the process, that means the back-end developer won't start until everything is taken care of.

These issues keep happening - and I am getting really de-motivated up to the point that I am really annoyed with the work itself and some of my colleagues.

My team members complain alot - but only towards each other. They keep on going - whatever the situation is. The result?

1. I grow insecure, perhaps it's me?
2. Is this just how things are supposed to go?

My question? How can I say no against work ignoring the process if everyone else seems to mindlessly accept?.

That is without looking like some annoying developer who is just looking for something to bitch all the time.

Answer 1

Did everyone really agree?

I once had a situation, where we wanted to improve processes. We made a propoposal of a different Process, and everyone seemed to agree.

But then, everytime I wanted to follow this process, there was called an exception, due to 'more important matters', that always sounded reasonable at the first sight. So, in Effect, the process was never followed de-facto, but everyone thought 'in principle, we are following the process'.

The problem was: if you propose an improvement, theres noone who disagrees (who does not like improvements?). But if you present the costs, usually, there's much disagreement. And loosing the convenient way to do things is a huge cost for most people.

To demonstrate that, I phrased the Question differently: 'Please prioritize the all the things i am supposed to do (implementing features, removing bugs, following the improved process, cleaning the desk, arriving on time)'.

Following the Process ended up behind cleaning the desk and not beeing 5 minutes late. So, basically, they agreed to something completely different than I proposed.

The Problem may be, that they do not want to pay the costs for quality. That may lead them to rationalize you critizism as whining, but in my experience, it isnt. Technical debt may not be that visible, and it is easy to attribute it to circumstances, but eventually, reality ensues.

Hopefully, until then they realized it, or you switched Jobs.

Answer 2

Perhaps it's you

You seem to favor a very structured and organized way of coding, your teammates seem to have a more "get things done" approach. Now you mention that it leads to a lot of of "wasted time" so perhaps some structure is in order and there's no excuse for sloppy work. However, software projects tend to be fluid and enforcing too much structure will also cause alot of organizational overhead.

Perhaps you should all meet in the middle and try a more agile and interative, but structured, approach.

Answer 3

Joel Spolsky wrote some quite interesting stuff about it: http://www.joelonsoftware.com/articles/fog0000000332.html

Answer 4

Who is responsible for these people? Someone hired them and someone can fire them/hold them accountable.

"My company requires..." is meaningless without some enforcement.

You can't make time demands that doesn't allow for the production process.

Seems like this lack of control and unrealistic expectations are the reasons for the poor quality.

You can either: leave, become the lead developer, do nothing, or start working with those that feel the way you do. Make sure everyone knows you are going to follow the correct procedures until someone finds a better way and changes them. Sounds like "The Cider House Rules."

Answer 5

It sounds like you do not want your coworkers to follow a completely different process, you just want them to make different decisions in it. Sure, there are rules (guidelines?) about what they should do, and they ignore them. But the problem you describe is they have to make a decision (to start working on the project or rejecting a specification) and they decide to keep going. That decision won't change if you keep reminding them of the rules; they just don't care as much about rules as you do. They want feel to useful, and saying no doesn't make them feel useful.

If you want their behavior to change, then continuously reminding them about the rules is probably not very effective; it is more likely to lead to them ignoring you. Try to find a way to change the process to make them feel more useful while still following the process. Can you implement some sort of code review, checking each other's code and learning from each other to prevent hacks from making it to production code? Can you change the way specs (docs/ext.interfaces/front-end) are handled from a black-and-white finished/not-finished decision to a more cooperative process, where near the end of the specification a developer is asked to help finish? (And, you should accept that requirements will change)

Mostly it's not you, it's not them, it's the process. If you (and your PM) can find some way to organize things where people don't have to go against their character so much, the process will be followed much quicker.

Answer 6

This is about the point where I'd check in with a closed door session with my team lead. Hopefully you have a good enough working relationship with the lead that you can make that very informal.

The purpose of the meeting is to figure out why the team is doing things the way they are doing them. If everyone has gotten together, nodded, smiled and agreed to a new process, then why are they still not changing? Chances are good that it runs a lot deeper than simple not-caring or incompetence. It's likely that there are drivers at work that are not visible to the naked eye.

Start the meeting assuming that your coworkers would, if they could, follow a process that leads to less panic, less technical debt and greater product quality -- after all, who doesn't want that? So what's the unseen force?

It sounds like there's a lot of implementation/integration prior to the upfront work of design and UI prototype. Is the company short on people who can do that upfront work? Maybe you could volunteer. Is there a problem getting consensus with stakeholders? Maybe your team can find a new way of communicating with them or can take a new approach to documenting assumptions.

If you start with a one on one where you ask your lead why then you can open the door to a discussion that avoids defensiveness and focuses on problems and solutions.

Another trick might be to ask if you can pioneer a new way of doing things. Get backing from your team lead to force the issue a bit and let you take the approach you're advocating - it'll probably turn up issues as you buck the "system", so you want the management behind you. But if you turn out to be more productive and stress free, you provide a good case for changing the way of things, and you are likely to win advocates.