What to do with developers who don't follow requirements?



  • I am the PM of a 4 person team that is on agile. There is one developer (let's call him Tom) who always doesn't follow requirements and likes to argue that he is right.

    What has been happening almost every sprint - In sprint planning, Tom agreed to do story x (and give a large buffer to the amount of time he estimated is needed to complete the work).

    Firstly, during the sprint itself, Tom never once finish the item x properly. Sometimes he finished about 80%. At sprint review he just said that the item is not done. Other times he delivered X but with a lot of bugs, and we have to add additional stories to fix it.

    Secondly, almost all the time, Tom's deliveries will have some small deviations from the wireframe or accept criteria of stories and he loves to argue (if the wireframe puts a blue color button, he will produce a green color button and spend time justifying why his color is better). And he never inform or discuss with anyone about his deviation from agreed requirements.

    Thirdly, Tom also like to add his own stories to the sprints (even though he couldn't finish the stories he agreed to). This would involve 1) working on things planned for the future sprint which is still fine, or 2)adding things that are not required by the business users (like creating a login animation), which causes delay to the entire project.

    It is pretty frustrating managing the project because 1)you never know what will be delivered every sprint 2) Tom keep changing/adding requirements himself even though there is a proper requirement gathering between the BA and end user. 3) Quality issues and buggy code.

    Additional facts - Tom is the most experienced developer on the team (approx 10 yrs exp). The company is MNC which doesn't really fire people unless they are really bad. Tom has mentioned a few times over drinks that he wanted to be a product manager instead of a developer.

    Edit: Thanks for fellow stackers who helped to point out a similar discussion with (Advice for dealing with a cowboy programmer in an agile team), I would like to mention that there are some slight differences with the problem that I'm facing. That post was about a cowboy developer with scope creep (enhancement or gold plating), whereas this is about a developer whose main issue is not following requirements. Definitely, both are cowboys and some of ideas in that answer could be use to handle this issue. However, based on suggestion of a few posters below have mentioned. Not following requirements seems to be a behavior that is tackled somewhat differently.

    Update 1: Thanks for all the helpful advices. To also answer some of the queries - Tom is INVOLVED in some of the design discussions since he is the most senior dev. However, he is not involved in all discussions as there are too many discussion and we have a BA working on it. This is also a complex product and the requirements/ architecture/ understanding of the project are changing fairly constantly (at least in the first 6-7 sprints). Thinking of it, this uncertainty may be a contributing reason why Tom feels entitled explore on his own.

    Update 2 soluton: Currently, the uncertainty in project requirements has greatly reduced and stories have also become more detailed. The solution that I've come to, based on the various advices, is a 2 pronged approach - 1) process improvement, to start to ask more specific acceptance criteria and stricter adherence to them. This is together with the discussion with Tom about being timely and having quality on delivery of agreed stories. 2) At the same time, proactively engaging Tom to get his input or feedback on the stories and product and facilitate the communication with the team so that deviations are identified early and discussed. Will update on how things go about in the next 2 weeks.

    Update 2 result: Have gone through one sprint with the mentioned actions, the results have significantly improved. Having engaged Tom with more frequent short design discussions ensure that he is bought into and undestand the reasons for certain requirements. This together with more detailed acceptance criteria helped to reduce deviations / better focus of Tom's work to improve delivery. The new problem that we identified through the meeting is that Tom is very insistent on designing the software in his way (at the Business requirements level), so he somehow becomes the 'product owner', sidelining the real BA/PO.



  • Tom is an unguided projectile. Regardless of why he does what he does (whether he believes himself to be better or simply lacks proper guidance), the core issue here is that he not only second-guesses any information/objectives that you give him, but he will independently decide to follow his own instinct.

    if the wireframe puts a blue color button, he will produce a green color button and spend time justifying why his color is better

    The reality is slight different based on whether Tom's argument is right, wrong, or inconclusive.
    I've worked with developers in either case. Sometimes, the story itself has flaws (e.g. bad or confused analyst) and the developer is actually right. If you treat a developer who is correct the same way as you would a developer who is wrong (i.e. by sticking to the story as written), you're going to lose the respect, trust and goodwill from the (correct) developer.

    Assuming Tom is objectively wrong, his deviations should be squashed immediately. If your developer refuses to accept anything other than their own idea, you have a conflict of character and this may become unresolvable based on how stubborn Tom is.
    However, take note to not do this unless you definitively know Tom is wrong. If he ends up being right, it's going to reflect badly on you/the team/the company and over time this can lead to notable hits to morale.

    Assuming Tom is objectively right, and you don't want to suppress his positive feedback for future issues, the focus should be on telling Tom that he needs to coordinate any deviations from the planned tasks. There may be cases where Tom is right and there is no impact on the development effort and the PO agrees, in which case Tom actually gets what he wants. No system is above fault correction, but it needs to happen in agreement with the product owner (or whoever the story originated from).

    However, that doesn't mean that "Tom gets to do what he wants as long as he is right" is the end of the discussion.

    If Tom goes rogue and deviates on his own, he bears the responsibility on not delivering what was asked. As far as your story is concerned, it's irrelevant whether Tom was delayed working on a green button (= something that wasn't asked) or because he wasn't working (in either case, it's Tom spinning his wheels during his working hours). What matters is that Tom didn't deliver and Tom did not make anyone aware of the expected delay.

    Unless you/the PO agreed to having a green button instead of a blue one, Tom delivering a green button means he did not deliver the task, regardless of whether green is better than blue or not.

    A developer who doesn't deliver a task isn't inherently an issue, as there may have been unforeseen complications or simple developer inexperience. But a developer who repeatedly fails to deliver or coordinate with their own team is not performing their duties as a team member.

    At the end of the day, Tom does not get to singlehandedly decide the color of the button. His job is to do what was asked. If he has relevant feedback, he's allowed to bring that to the table (up to a point), but he cannot make decisions, most definitely not on his own.

    The problem seems to have gone on for long enough that I would personally suggest ignoring any and all of Tom's arguments after he has deviated; purely on principle. What matter is that he didn't deliver, and he wasted effort on something that was not asked/planned. The bottom line is that Tom must at all times be working towards the goal that was planned, not the goal that Tom has decided for himself.



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2