29

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.

  • 6
    I believe Tom is a Cowboy coder, so your question may be a dup of Advice for dealing with a cowboy programmer in an agile team. – Tiago Cardoso Oct 21 at 8:52
  • 7
    I'm a bit distracted by the fact that this is phrased in terms of workplace and supervision and not in terms of the impact on the project. Seems to be me that the impact on the project is that you don't have a project team - you have two project teams - Tom and everyone else. If Tom doesn't recognize the value of working with the team, then that should have an impact on his assignments and his career. I would never recommend someone for product manager who can't work with a team. – Mark C. Wallace Oct 21 at 11:51
  • 4
    Peer review, and just not accepting until it is right. No new tasks until the old ones are done. Ignore work not done on assigned tasks. Discuss why his generous estimate did not hold for the old, delayed tasks. Repeat. – Thorbjørn Ravn Andersen Oct 21 at 13:59
  • 2
  • 3
    This question doesn't have a general answer. It's probably going to start a good discussion, but as you can tell from the answers, every situation like this is different. It depends on Tom and it depends on the PM's skill. Really this question is a form of "How do I ensure my developers are doing the right tasks?" -- and the main job of a PM is to get that right for each situation. – Travis Wilson Oct 22 at 18:31

14 Answers 14

35

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.

18

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

  • 1
    100% this - not only is it likely to help with Tom, but it will also help your Testing. – Chronocidal Oct 22 at 16:15
  • You ask "you are branching for every story, right?", why do you assume "This will help your Tester" without asking "you do have a tester, right?" – Alexander Oct 23 at 13:39
  • 3
    @Alexander If they don't have testers, they have bigger problems than rogue developers. From #10 on The Joel Test: "If your team doesn’t have dedicated testers, at least one for every two or three programmers, you are either shipping buggy products, or you’re wasting money by having $100/hour programmers do work that can be done by $30/hour testers." – BryanH Oct 23 at 15:05
6

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!

  • I hope he is a 'super star' developer, but I would expect such a person to at least deliver his on work on time, with quality, and discuss with the rest of the team. The issue is that Tom is rarely on time his own features (those he signed up at sprint planning), they are also buggy, and he doesn't discuss with that rest on the deviation /additional things that he is doing. – polygo Oct 21 at 12:00
  • Being a team lead who had worked with such developers for some time, I know your frustration. I've encountered the same scenario many times, and most of the time what I do is give him responsibilities in out of his comfort area and get him involved in the management process as well. Also, inform the HR about the responsibility change. If you give him a bit more responsibility, that way he will have to deal with it. It will be a kind of a promotion for him and also, but with less burden to the team. if he continues to do that, it'll be worse in the future! – Kavindu Narathota Oct 21 at 12:11
  • 3
    @polygo: Thinking you're a super star developer is different from actually being one; but this answer explains Tom's internal thought process (and how you can get through to him) regardless of whether he is a super star developer in reality. If you argue with Tom whether he is or isn't a super star, you're going to be distracting the discussion from the more important point that in either case he needs to stick to the planning better than he currently is. – Flater Oct 21 at 14:00
5

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.

  • 1
    Yes, for me this is the 'correct' answer. At the end of the day, management is a dirty job that somebody has to do, while programming is a creative job. You can't stick 5 DaVinci's in a studio and hope that 'scrum' will organize them into producing 10 paintings a week. The methodology must be secondary to the team members, must evolve out of the team members, must be emergent. You can't impose Scrum on a team, just as America can't bomb democracy into the Middle East. It just doesn't work. Clearly Tom doesn't like being micromanaged into dealing with stupid issues like blue or green buttons. – Sentinel Oct 23 at 9:56
  • 1
    Being a project manager does neither need to be a dirty job. I believe that a good project manager should also be a creative person; someone who does not just listen to management, but also to their team members. – anonymous programmer Oct 23 at 11:50
  • I really resonate with this answer. I cringe when I read the other suggestions to just tighten up the process and try to hold the dev to his estimates and interrogate his failure to meet them. They are estimates after all. It may be that Tom is not doing his best and not being a team player, but tightening the process on someone who is already bucking the process is not likely to go anywhere good. Trying to understand why he feels like he needs to break the process and addressing the underlying fears is much better advice. – Planky Oct 23 at 17:25
  • Thanks for sharing a dev perspective, I understand now that Tom may feel that the PO/BA's requirements are not optimal, and that he as the most senior team member should have a say in the design. (Whether this is true or not is another qs) But I disagree that instead of bringing this up to discuss and reach a agreement, he just code what he think is right, because a team can't function this way. – polygo Oct 24 at 7:44
  • I will look into improving both the project process and also how to make Tom happier at work (allow him to express he inputs) – polygo Oct 24 at 9:44
4

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

4

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.

3

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

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.

  • 3
    Also, anyone who consistently delivers incomplete and/or buggy code should not be called an experienced developer. “Experience is what enables you to recognize your mistakes when you repeat them.” Apparently he has not even reached this tongue-in-cheek definition of experience. – WGroleau Oct 21 at 18:39
  • The OP has said that the company is averse to firing developers. But there are steps before that. The first step is an informal warning; and the steps after that are formal warnings, delivered together with your boss, which go on his records and will prevent him even getting a pay rise at his next review, never mind promotion. – Graham Oct 21 at 21:06
  • I saw that remark. But "averse" doesn't mean we never dismiss the incorrigible. – WGroleau Oct 22 at 0:22
  • 1
    Sure, but there are steps before that. Maybe they'd correct him - or at least prove he's incorrigible. – Graham Oct 22 at 7:35
  • “Make absolutely clear … If it doesn’t sink in” refers to those steps. – WGroleau Oct 22 at 17:28
3

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.

  • 1
    While this approach might work to keep green buttons out of the codebase, it is guaranteed to tank morale on the team. And it is unlikely to get more productivity out of Tom which I hope is the OP's goal. Not just to put him in his place. – Planky Oct 23 at 17:45
  • It won't tank morale, because plenty of companies use Agile correctly and successfully; and chances are the other engineers can also see the problem. So long as it's applied consistently and fairly (not just to beat up on Tom) then the OP's team will be fine. As far as Tom's productivity goes, he currently has negative productivity, because he's creating work for other people. This should give him the structure to improve, and if it doesn't then it gives ammunition to fire him, which is win-win. – Graham Oct 23 at 18:32
2

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.

  • Interesting point of view, but in this case how is possible "cut" the established culture? Which actions you can take? – Lorenzo Oct 23 at 8:58
  • 1
    @Lorenzo I re-read my answer and I provide a number of changes for the OP to take. In my experience, often people like Tom don't consciously understand their own behaviour. I suggest: Change 1. set up a meeting for a frank discussion to identify concerns with Tom's lack of progress. Change 2. Ignore the argumentative behaviour it is a smokescreen. Change 3. In future, advise the team that argumentative behaviour will cause a meeting to conclude. When Tom argues, conclude the meeting. Summary: attempting to better understand Tom, while also taking some control over the weekly sprints. – andrewbuilder Oct 23 at 10:26
2

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.

2

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 :-)

1

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.

1

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.

  • Yes. The team is co-located in the same office, and so far stories have been discussed in design sessions and explained in sprint planning. In fact, there's been no issues in understanding the stories from the other 3 devs (even though they are more junior). Perhaps, it is because they are junior, they seek to clarify any doubts with the BA/PO. Tom, on the other hand, perhaps been more senior, not only check in his doubts less frequently but making his own interpretation or design decisions instead. – polygo Oct 27 at 7:07
  • In the case of a button having a different color, did you enter a deeper discussion with him on why he changed the requirement on his own? How much do you generally discuss things like requirements with him? Is he involved a bit as in present during meetings or does he voice his opinion and takes parts in discussions? Are such meetings small enough (5 people or less?) – Raphael Oct 29 at 13:36
  • Yes, but not specifically on the button since these are too many other color deviations. In general, Tom argues that the wireframe by the BA/PO is just a high level direction so he will design what he sees fits. Tom has been involved in design discussions (but not all discussions as there are too many). I guess going forward I need to involve him more on this since he sees himself as also the product manager. – polygo Oct 31 at 3:12
  • It is always a bit hard to judge from a distance, but to me it sounds like Tom should maybe actually be a product manager. I was myself in similar situations in the past and sometimes struggled to implement what others told me to because really I wanted to be in charge of the specs. While I was probably a bit more compliant than Tom in the end and managed to work it out with my managers I was never really happy doing that. So I would seek an open and friendly conversation with Tom, asking him about his career goals and consider moving him into a product manager position or something close. – Raphael Nov 1 at 16:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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