14

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.

Improve this question
4
  • This is the job of QA to make sure that the process is followed.
    – mouviciel
    May 31, 2011 at 9:47
  • We have management, sales, project management, and development team. QA is lacking - unfortunately.
    – Wesley van Opdorp
    May 31, 2011 at 9:50
  • The role of a process is not clear for everybody, and thus it is not applied as it should. This is why QA exists: to enforce application of process. Defining a process without people in charge to enforce it is like defining laws without police and judges.
    – mouviciel
    May 31, 2011 at 10:01
  • What did your boss say, when you discussed this with him?
    – user1249
    Sep 9, 2011 at 8:47

5 Answers 5

Reset to default
8

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.

Improve this answer
4
  • 2
    'following the improved process' is the only non-goal oriented option so the result is nothing unexpected. In this context it sounds more like "it's following process for the process sake" and not goal oriented activity (higher quality, productivity, etc).
    – MaR
    May 31, 2011 at 11:32
  • 'the improved process' is a short term for things like 'test at least superficially before deploy', and that is goal oriented: the goal is to reduce the work neccessary to clean things up afterwards, which is what inevitably happened. It's not that i pulled a process out of thin air and made it dogma. It was derived from recurring problems that affected productivity. What i call 'process' in this post was more or less to follow 2 or three items of joel's test.
    – keppla
    May 31, 2011 at 11:45
  • 1
    what I wanted to point out is that it matters how you sell "the process". I'd say "test at least superficially before deploy" would score much better than "following the improved process" in comparison to "cleaning desk".
    – MaR
    May 31, 2011 at 13:52
  • @MaR: i agree, i neglected that aspect in my post. At the job, i did not say 'please follow the process', but more something like 'we agreed, that we have to test first, to avoid annoying the customer further with a broken service, again. Why are we now ignoring that?'
    – keppla
    May 31, 2011 at 14:00
3

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.

Improve this answer
6
  • 1
    If the teammates do not like 'his' approach, why did they agree in the first place? Reading his post, i dont get the impression, that it was his proposal alone. And, even a fluid approch does not work without specifications, the difference is in my opinion not the absence, but the explicit provisional character of the specs.
    – keppla
    May 31, 2011 at 11:30
  • First off, not disagreeing to something is not the same as committing to something :) Perhaps his teammates doesn't see any other alternatives. Even if the process was managements idea it can perhaps need some adaption to reality to ensure buy-in of all parties. I agree that there need to be some specifications but unfortunately sometimes specifying something can be about as difficult as building it. An agile, iterative process can allow the specification to crystalize as they go along
    – Homde
    May 31, 2011 at 11:43
  • He stated explicitly, that his team agreed, not that they did not disagree. Please don't get me wrong, im not against agile processes, but they too are just that: processes, that need at least a basic commitment. If everyone ignores the Standup, noone keeps a Backlog, the 'specifications' are just a 'by the way...' one keeps getting while passing the manager, even an agile process dies. And, im my experience, that is not even painting a black picture. Not every company is google. Most seem to reseble dilbert more closely.
    – keppla
    May 31, 2011 at 12:03
  • 2
    I agree, they need to find a process that everyone can buy into. Tacid agreement isn't worth anything. They probably need to experiment and see what works for them, either that or his teammates are simply incompetent and needs to be fired :) I've noticed one thing about processes though that even if there's buy-in there often needs to be atleast one "process-nazi" that ensures the process becomes habit. Only works if the process has buy-in though
    – Homde
    May 31, 2011 at 12:08
  • ... Btw, I wouldn't use google as as good example of process. They seem to suffer from a severe case of engineeratis due to much structural overhead. Last I heard they were trying to get back to their startup roots
    – Homde
    May 31, 2011 at 12:09
2

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."

Improve this answer
2

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.

Improve this answer
2

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.