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

Question

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.

Answer 1

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.

Answer 2

Flater's answer is really good; let me add something that will also help: Acceptance Criteria (AC).

Acceptance Criteria

Every single story should have Acceptance Criteria, describing the functional effects of the story with a binary (true/false) answer.

If a story is incorrect or lacking details, then this is the fault of the team during grooming/planning. Stories that aren't developer-ready (e.g, not clear or lacking details) should not be put into the sprint.

This will help your Tester and your Developer. The tester will know what things to definitely test and the developer will know which functionality is required.

Example

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

Nope. Once a story is put in the sprint it is fixed and no changes. The time to change the story is during grooming and/or planning.

Acceptance Criteria might look like:

1. GIVEN the user is logged in WHEN they click the menu item to go to the settings page THEN they should see a blue (#0000ff) submit button.
2. GIVEN the user is logged in and on the settings page WHEN they click the submit button THEN the lights for Flood Control Dam #3 turn on.

When you review the story at the end of the sprint, you check the acceptance criteria. IF ANY AC ARE FALSE, THE STORY IS NOT DONE AND GOES BACK TO THE BACKLOG. The branch is not merged (you are branching for every story, right?) and that's the end of it.

If Tom argues the button should be green, then that is a new story and it needs to specify the business value (ask Tom to provide this and see what he says).

Answer 3

This is a problem most of the PMs face when there are really skilled Developers in their teams.

My answer will be a practical approach to handling this issue.

I hope you have been a PM for quite some time and have experience and have established yourself as a PM in the organization. Basically, you have a say in the organization.

Since Tom is an experienced engineer, try to get an understanding of his skill level and areas of expertise. Let's say he's an expert in Front-end technologies. When someone has 'superman-skills' in a given area, s/he tends to go above and beyond or not stick to the requirements because s/he believes that he's the expert in the given area. But that is as long as s/he in their comfort zone.

When it comes to your next sprint planning, try to get him a bit more involved in the planning tasks (since he has mentioned that he's looking forward to a change of fields). Also, when assigning development tasks, try assigning him at least 50% of back-end tasks. Try to take him out of the comfort zone. That way Tom will have to give more thoughts into the tasks in hand.

Try following this method, especially involving him in the planning phase. That way he will feel that he has more responsibility and think again before making any sudden changes.

To sum it up, give more responsibility in project management while making him busy with the development tasks. But don't overflow him with unnecessary tasks.

Hope this approach works!

Good Luck!

Answer 4

I work as a developer and can so clearly see myself in the shoes of Tom; I guess he reminds me of myself. I can see in your profile that you've written about Tom in July as well, so I realize that this is great concern of yours. Of course I don't know the details about your situation, but I will try to elaborate my own view.

It has happened to me that I have worked in a Multi-national Corporation. I was working in Scrum projects that were developing on applications that were basically very badly written and the organisation was clueless. The Product Owners doesn't even understand that the applications have bad quality, nor why.

In such projects, it happened that PM tried to enforce form and structure (e.g. the better we adhere to Scrum, the better the outcome will be). Since time and Sprint velocity are easy metrics, they are easier to measure than product quality and user satisfaction, Scrum seemed a good fit. But in the end, it just made people miserable. Some people demand structure, some people choke on it.

When I work on an uninspiring project and there is too much structure, I hate it; the structure removes the possibility to do the large stuff that is needed (refactoring, performance improvements, redesign, etc.).

In the end, the structure should just be treated as a means to deliver great software. It seems Tom is not satisfied with his situation, maybe you can try to find out why? He seems involved in the project in that he does try to improve the software by making his own contributions. I think that if he isn't satisfied, more structure might, maybe slowly, in the end either make the both of you miserable or lead to one of you leaving.

Maybe he needs to mature a bit, maybe you both do or maybe just the organization sucks? Is Tom satisfied and working his dream job? Are you? You've got the "Rubik cube" in your lap; your imagination might help you solve it; maybe you are both human and need to realize that?

At least to me, a great project manager is not someone who just enforces a tight structure, but someone who is involved, someone who genuinely cares about the quality of the project and likes to work together with both the users and other project participants; a good listener.

Answer 5

This is a behavioral problem and not specific issue which can be addressed by any framework or development methodology. As a leader with specific goals to be achieved in defined timelines you need to develop strategies which helps you achieve the goals.

You might be doing many of the standard suggested practices as well, but it will be helpful if you can review and try implementing below suggestions which ever is related and applicable.

1. Define Project Objectives and vision: Be specific and tangible in project definition of objectives and what do you need to achieve from this. Do the same with every individual task as well, define the objective of this task in tangible way. As quoted by you as an observed issue,

• No deviation from provided approved UI can be mentioned as rule to be followed.

• Include workflow diagram for feature process, with happy path and alternate paths

• Check list/ unit test cases against defined acceptance criteria to be completed and provided by developers for mentioned task submission

• Include these sub-component efforts in task development effort

• Be open for suggestions/feedback/arguments for changes and plan that in sprint planing. Do involve all related team members in the planing activity.

• Accepted finalized tasks will be freezed for development and changes on these must be planned in new sprint, following the life-cycle again as required
• Define sanitization/thumb rules for projects and tasks like error handling on data events should be captured with proper user message and should not break feature. APIs with larger data in response must implement Pagination, Components like buttons etc must not break accessibility guidelines implemented in product. etc. etc.

2. Define Project Communication and Regulation protocols: Define project governing rules, like Project communication model - how can team collaborate on task communications, sprint planning timelines, Acceptance Criteria Definition, Acceptance rule- In case of differences, majoritarian rule will be applied, etc etc.

• Project Communication definition, how and when all team members are supposed to communicate for all events of the project

• What are the inputs and outputs from each event/task and respective owners

• Rules/protocols for events like Release Notes: release to QA team,Client etc,; QA team report format and Mandatory information needed in each and every Issue tracking, Deployment document and guidelines, Downtime communication and integration assumptions, Versioning, Backup and Backlog documents.

3. Project Reports: This is very vital to be agreed with team upfront, about various reports that will be created, maintained and shared with different stakeholders at regular intervals in project. As different stakeholders has different needs, the reports published will be different, and it will reflect overall project health and status. These reports are connected with each other so deviations can be back-tracked from any level. In your case, you need not publish the individual team members performance reports directly to Project sponsors but every sprint retrospective meeting and sprint completion report which can be shared with project team members must have individual developers contribution.

• Published reports act as data source for all future decision making. No one wants a bad report to be seen constantly and frequently.

4. Retrospect every step and Stay neutral with focus on Project Goal:

• It can be true that few suggestions if not all, are genuine and good feedback.

• Try to understand root cause of this behaviour. Is it due to task assigned are not as per their KRA or team need inputs in any different way?

• Discuss and get on agreement on expectations in terms of tasks and behaviour.

• Be rational with suggestions, listen to reasons for extra efforts needed, tasks suitable to their role and individual's growth aspiration as well. Convert everything into tangible thing, like breaking task estimation into smaller chunks "use-case review"+ "development" + "unit testing" + "Release Notes preparation" + "Bug fixes and sanitization".

• Make team members own and manage few tasks, let them celebrate success as leader and make everyone involved by team building exercises

Answer 6

This sort of thing isn't as uncommon as you might expect. At the top level, you have basically three options:

1. Work with him to "behave" and meet the requirements within the sprint cycle. That's what most other answers seem to focus on (and therefore I won't add anything further), and should be your first recourse.
2. If, no matter what you do, you can't get him to adhere to the process, take him off the development team and make up a position for him (call it "lead researcher" or some such) where he can go off and work on his own to make the product better. That's probably your second recourse. This way he can play to his strengths, contribute to the product, and not get in the way of the development effort. His code would of course have to be treated as prototype; the real implementation would have to be fed, via the backlog, back to the development team using the regular process. But if it's good code, implementation should be easy, and you can track how many of his improvements make it into production.
3. If none of the other options work (for example, after a while it becomes clear that his efforts never make it into production, either because they're poor quality or because the customer / product owner doesn't want them), then you don't have any other choice but to fire him or move him off to a different project. This is probably your last recourse, but at least you'll have a lot of data to justify your decision. And hopefully it will not come to that.

Answer 7

Other answers have focused on the interpersonal skills involved. I'm going to suggest technical/process fixes.

The main problem is that you think you're on Agile, but you're not. You're on hacking random shit together over a period of time, and that's not Agile. Tom thinks he can blackmail you into accepting his changes because otherwise the sprint fails. What he and you aren't getting is that there's always another sprint.

If Tom's code doesn't work, or doesn't do what was agreed, take it out. Stick to your guns. If he wants to argue, then do lay down the "I'm your manager and my job is to make that call" card. And then make sure that his progress for that sprint is shown as zero. He may want to argue. Don't let him. As Terry Pratchett said, it's one man, one vote - and you're the one person with a vote. This is not a democracy.

Does this stop other people's changes going in? Then their progress goes in as zero too. Maybe he thinks he can bullshit you as his manager, but when his fellow engineers tell him to cut the bullshit then maybe he'll wise up. At the moment though, you're enabling him, and implicitly telling the rest of the team that they can get away with this. Don't.

You can make this easier on yourself though. You're using version control, right? Then ensure you're following best-practise for using version control in teams - which is that all development only ever takes place on a branch. You're the gatekeeper for what gets merged back (or someone else you trust). Until an engineer can show that it meets requirements and it's been tested, a change doesn't go back to the trunk. This lets people's development happen in parallel, in isolation. If Tom wants to mess around, his changes simply never go back to the trunk.

Answer 8

Let's consider Tom's motivation for his behaviour. He mentioned that he wanted to be a Product Manager and that suggests he clearly enjoys this kind of work.

Tom's behaviour is currently a problem, but I wonder if his motivation can be harnessed to add value?

For example, consider Behaviour Driven Development. Somebody like Tom would likely thrive on this kind of approach as it would allow him to discuss the product requirements while also having the technical understanding of what is possible to implement.

The main issue with Tom right now is that he is making decisions independently of the team. Perhaps by adjusting the way the team works or the roles within the team he can be brought back onside. This may then increase the team's capability to deliver value.

Answer 9

If he consistently misses deadlines, he must never be a project manager.

If he can’t be trusted to honor requirements, he must never be a project manager.

If he argues with management direction, he must never be a project manager.

Without denigrating the other good answers, I would add here that another thing to do with such a person is make the above three points absolutely clear to him.

And if it doesn’t sink in, fire him.

Answer 10

You’ve let a culture become established in your team. This culture once established, is much more difficult to change.

Regardless of whether Tom is acting as a team member, he IS still a team member.

So how do you modify Tom’s behaviour such that he maintains his sense of worth and still provides you with reasonable outcomes that align with the goals of the team?

Maybe ask yourself why he might behave in this manner...?? You’ve already suggested some reasons in your question.

You could request senior management support and/or intervention, but that will not be good for your career or Tom’s career.

So let’s work on the why???

Have you considered an honest and frank discussion with Tom? Maybe an informal meeting specifically set up for the purpose?

Nothing fancy - best not to reward unsatisfactory behaviour! I recommend an informal meeting in a small room that you’ve not used before. (Nothing familiar - you’re trying to break bad habits not reinforce them.)

This problem now requires some significant effort and a break from “normal” processes to effect change.

I repeat that the culture is established. Week after week, Tom’s behaviour is deemed to be acceptable, simply because you and the rest of the team have accepted it.

Tom, from the description you have provided in your question, despite his agreements to deliver stories by each sprint catchup, may not be aware of his shortcomings.

So an honest and frank discussion with Tom may be what is needed. Such a discussion will allow you to carefully present your concerns. He may or may not care or take any notice, but at least you will have taken positive action and identified the issues directly with him.

Tom’s response to this meeting may not be immediate. Give him some time to digest the discussion and implement his own personal change.

Tom’s arguments are irrelevant and are simply a mechanism to deflect the real issue/s and present an appearance of making a valuable contribution to the meeting. He may or may not be conscious of this behaviour.

There are many ways to deal with argumentative behaviour. My advice - shut it down as irrelevant and off topic as soon as it starts. If he takes no notice, close the meeting. While this could have drastic immediate effect for one or two weeks, in the overall project timeline it will only reinforce that certain behaviour is unacceptable.

Answer 11

You actually listed 5 problems:

1. Tom delivers buggy code.
2. Tom doesn't always complete his stories on time.
3. Tom makes up his own version of the requirements.
4. Tom creates his own stories.
5. Tom thinks he can do whatever he wants, because he's the most "experienced" developer on the team.

Is he aware of these? Have you discussed these issues/patterns explicitly or just let things slide so he doesn't realize the problems he's causing? If not, have that hard conversation first.

For #1 buggy code, don't accept his code until it's been tested. As others said, you do use version control, right? Perhaps testing Tom's code should be a story in the next sprint. It'll help to make the point that his code is substandard.

Also, Tom should be forced to fix his own code before it's merged.

For #2 being late, I don't know what to tell you. You need a stick or a carrot. I don't see one in your description. Keep an eye out for one.

I would document how he screws up, so if there's ever an opportunity, he could be removed. And I assume you have annual reviews, right?

For #3 changing the requirements, if he wants to make up his own version of requirements, cool. He needs to do this in advance when the story is assigned to him. Period. Otherwise his story isn't done. He needs to code the requirement he agreed to.

For #4 making up his own stories, his code shouldn't be accepted if he can't do #1-3. He can code it. Reject it.

For #5, the documentation in #2 should show him that everyone else is contributing more.

Now I want to point out that you don't seem 100% sure Tom is borderline incompetent. If your stories aren't well thought out, or you actually are leaving out features that Tom is adding in his stories, you're actually at least part of the problem. The answer would be different then.

Answer 12

I don't want to write a bible but just a couple of simple suggestion.

First: try to create more smaller task, more simple where is very simple to estimate the work load and the work time. If you have a big task, break it in two or more small sub-task

Second: Already suggested, create and define good acceptance criteria: if the result doesn't match the acceptance criteria, means the task is not completed. Of course Tom can argue the acceptance criteria but here you have to decide how lead the activity.

Remember that the requirement is the Input: if the input is not clear at 100%, the task probably can't completed. Try to understand how much you can improve the requirement.

And.. Talk to him :-)

Answer 13

Are you sure that you are "on agile"? Or do you mean that you plan in units of 2 weeks?

To me your problem sounds like you (or the product owner) might not explain the purpose of what you are working on. Keep in mind that "agile" was originally restricted to being co-located, meaning the product owner would be easily approachable for questions of clarification. Also, collaboration and swift changes to requirements would be emphasized over following the documents.

I do not know your project, but taking your example let us assume Tom is right and it actually makes sense that the button should be red. The user story said the button should be blue, but maybe that is complete bogus. Let us further assume the button is an emergency button and the specs said it should be blue because there is already a red button triggering the main function (since the corporate identity's main color is red). Therefore, blue was chosen as the color for this button. In this case, Tom is probably right and you should thank him for building something better than the user story said. The only real improvement would probably be that he highlights this during sprint planning or similar so it does not end up being a surprise and the change is properly tracked / everyone is aware of it.

Let's stack a bit here: What if Tom is right in his view, but really he is not. The button's function was not so clear and it seemed to his team that it would be an emergency button. In good faith, he changed the color to red because that is usually the color for emergency buttons (not blue as the acceptance criteria had specified). It turns out that it actually is more of a "call operator" button, not really an emergency button, so the color blue would be OK after all. That fact was not communicated though to Tom and his team or was somehow vague.

I have often heard project managers say things like: "We do not have time to explain everything to everyone." I would ask back: "Really, do you?" If you do not even have time for that, what do you have time for? Or as Steve Jobs has famously put it: "It doesn't make sense to hire smart people and then tell them what to do. We hire smart people so they can tell us what to do."

Keep in mind also that the required collaboration of agility means that teams do not perform at 100% of the performance, but instead they may take weeks or months to properly synchronize. In my opinion, you have to account for that e.g. by keeping teams together for longer times across projects or other means.

Answer 14

The alternative approach frequently used in the past is to design architecture so that it would be many weakly coupled modules, and assign a module per developer or two. This gives much more individual freedom than everyone working on everything under then necessarily strict rules and supervision, and does not necessarily result bad software as each developer feels fully responsible for his module. If the developer performs poorly, only one module is buggy - less damage and easier to fix than him making random changes overall.

When the developer leaves, a module is initially taken over but most likely will be rewritten by the new developer. Of course, the approach is unusable if you want to change people in a company on a quarterly basis but you write you keep them.

If this cannot be easily implemented in the main production code, usually tests (unit and integration) are very easy to organize this way. Put him on writing tests the way he likes. Even really poorly designed tests sometimes fish out serious bugs in the perfectly designed code.

Answer 15

Tom is the most experienced developer on the team (approx 10 yrs exp)

It sounds to me like Tom is pretty good at his job.

No developer should implement things in any other way than the way they believe is best for users. If you haven't shown Tom why his way is objectively worse you've not done your job. Don't moan about Tom for that - get him the rationale or evidence that makes it clear, not just to him but the next developer after you and Tom have long gone who picks up a related piece of work, that your way is better. It won't take him long to change the button colour if you were right and everyone will have a better understanding of why the button colour has been chosen.

Go Tom. You're my hero buddy, keep using your brain and doing your best for users.

Answer 16

Even when Tom is "the most experienced player on the team," a team wins the game only "as a team." You decide how the next play is going to go, then all of you, working together, execute the play exactly as agreed. The work is only "done" when the team accepts it, as verified by automated tests which check it against the agreed-upon standard.

If Tom has aspirations of ever becoming a project manager, as opposed to simply wanting a promotion, he fundamentally has to learn this. If one member of the team who isn't the Quarterback wants to pretend that he is, then suddenly the rest of the team does not know what to expect and the whole thing quickly falls apart.

I suggest that you try to get Tom more actively involved in the planning stages. It may well be that he is a "cowboy coder" who is accustomed to literally "making stuff up as he goes." That's okay if you're a lone wolf, but not when you're part of a wolf pack. He needs to realize that you can plan a software "sprint" completely and in detail ahead of time, and that it works better that way. Wolves can survive on their own, but they eat better when they're part of a pack.

Answer 17

I have been in your shoes and Tom's shoes before. As one of the answers has mentioned it is a behavioral issue. We all have it. In order to solve it, you need to understand it first. I am researching this phenomenon as one of my research streams. Here is a link to a short analysis of what is going on in Tom's mind : https://pdfs.semanticscholar.org/1d05/81f47657ddefd0289e74e8fd6267a077116f.pdf I hope it helps.