"Tom that he needs to coordinate any deviations from the planned tasks" Nothing in the OP's question says that is necessary. All the OP says is that there is a "deviation from agreed requirements", but doesn't say if Tom ever agreed to the requirements, nor does the OP acknowledge that development is a process of designing for the acceptance criteria. I have never seen a wireframe that didn't end up different implemented.

@Flater I am not sure I agree. I think development should be a creative process and what seems to be happening here is that Tom isn't getting the freedom he needs. This means there's an incompatibility between him and the process in place. In my opinion the manager should try altering the process to give Tom the freedom he wants. So for example, the user stories could be left more vague with less micromanagement in the acceptance (blue vs green buttons). The process should emerge from the team members, not be imposed upon them.

@Flater I think fundamentally the issue here is that Tom was not involved in agreeing to the overall process. That primary agreement on the methodology still needs to happen.

@Flater I do understand. As a developer with decades of experience, I don't think I would usually accept the task "make a blue button" unless I was involved somehow in the design process or given to understand that the design was done by a professional designer. I don't see anything in the OP's post to suggest that was the case, so perhaps we need some clarification from OP. Either the professional design/er is ratified with me or I don't accept the task. I personally hate donkey-work like that, so I suspect Tom might be in that situation. Though admittedly that's not clear.

@Anaximander I agree, but only if we know that 'insubordinate' implies a hierarchical situation - but from what OP says they have a flat structure, so I don't think 'insubordinate' applies.

@Flater Well, just to clarify, I re-read the OP post and now I am convinced that the situation here is NOT that we have a rogue programmer, we have a dev who wants to be more creative. He's adding animations to things, he's adding his personal signature to the design, etc. He just needs to have more freedom in the creative process.This is a problem on the management side not the dev.Either the culture is such that requirements must be rigidly conformed to (safety critical) or it's fairly arbitrary. I think the latter, so give the guy his freedom and maybe move him more toward product design.

@Flater I think his role does include design. It should. I do think what we have here is that the OP is an inexperienced manager.

@Flater I most definitely agree that the fact he does not deliver is an issue. BUT, an unhappy dev is not a productive dev.

@Anaximander We don't know that from the OP post. That's prejudging. In fact, dammit, can't we get Tom to join this discussion and let him frame it from his angle?

@Flater Sounds like you have both very strong and very narrow opinions. Regardless, the OP claims he is PM , not CEO, and not only that, a PM on an agile team using Scrum. Scrum has no such role. Scrum has Scrum Masters, and their role is to cultivate the team, not to direct it.

@Anaximander Yes. I 100% concur. If I was the manager, that is the route I would go. Involve him, test him, see if he's insubordinate later. Then act.

@Anaximander No sorry I meant by prejudging that we don't know that we he is producing is not what the client wants. It might be that the PM's design process is a disaster and Tom is doing precisely what the client wants because he knows the PM's approach is awful.

@Flater OK we can agree for sure on that, but I think the fundamental issue here is that the PM is looking for reasons to shoot the dev down when in fact the PM should be involving Tom in a more creative process and giving him more creative freedom, not looking for online public support on why not to do that.

@Flater No, there's nothing in the OP to say that the user story is an expression of what the client wants. On the contrary, OP says that the BA is handling things and that there is a lot of uncertainty. You know as well as I do that on many projects, if not most, the goulash supplied by the user and the BA is often little more than garbage that the devs/architects end up having to translate into what the client ACTUALLY wants. In most projects I have seen, it's the customer who needs to be TOLD what they want. Yeah, I see you have a lot to learn. Out.

@Flater You don't need to know. You just need experience.

@Flater No, I don't know. But my reading of the situation based on the limited info is that this is a fairly typical scenario and it sounds like Tom probably does. He might be just a stubborn asshole, and if so, well the PM should just fire him or something, but if so, why is the OP asking for advice? Either OP is just venting, or Tom should be given the chance to work with the BA directly.

@Flater Anyway. Out!

@Sentinel Just noticed this heated discussion and I want to clarify that it is not possible to fire Tom, given that the company culture (there are worse people who didn't get fire). I am looking for feedback on how to fix the problem as it needs to be fixed.

@polygo Yes. See above. Give him the creative freedom he wants. Check if his productivity improves. If not, fire/relegate/move. But again, you should have been able to gather that info (as a PM) from the above discussion just by reading it. I wonder if your communication abilities might be an issue?

@Sentinel In fact, l at first I was doing what you recommended, stories were vague, Tom as the most senior dev was participating in design and also given a lot of freedom, but things are not really working...That's why I'm now thinking of enforcing more detailed stories, stricter acceptance, definition of done. Tom will continue to be involved in the design phase. Won't go to the firing Tom route as this is not possible in the company.

@polygo How do you assess that "things are not really working"? Based on what metric?

@polygo Is there a deeper issue here? Would it be fair to say that what you are really up against is the old "I am accountable but don't have authority" issue?

@Sentinel, things are not really working because - 1. Tom has delays and bugs on the stories he agree to take on during sprint planning. But, he also spend his time building additional things that are not in the sprint. 2. Deviation from requirements (while small), gets noticed by BA and end user and is causing feedbacks. Tom always argues on his deviation (which sometimes are right - since no system is above improvement) But other times wrong, product is a complex system and many times the design decision is made in a certain way because of analysis/iteration/compromise across stakeholders.

@Sentinel Tom's has always been involved in design. I am happy for him to get his input to the product. But I just feel that there should be a proper process in place. Right now it feels to be a lot of spinning of wheels. Yes, I need to foster more frequent communication across the team so that if Tom has a feedback, at least the rest gets to hear about it. Is just that sometimes he doesn't discuss with the rest, so I will need to be proactively engaging him about it.

(the above questions are intended to stimulate critical thinking, on a philosophical level, not to be 'provocative' emotionally)

@Sentinel I don't understand how you don't identify the lack of delivery at the end of the sprint as an issue. This isn't a matter of Tom being oppressed by a manager who doesn't want his input; this is a matter of Tom refusing to accept any boundaries to their freedom even at the cost of his ability to deliver.

@Sentinel: Every argument you make reeks of "developer good, overhead bad" up to a point of you foisting assumptions on the given example to suit your argument. If you (or Tom) want to be a one-man-development team on your own, go for it. But OP's company clearly is not the place to do so.

It seems you don't understand the value of a business analyst, which explain why you assume that developers must make their own decisions and should not be held accountable for anything other than trying.

I know what it's like to work without an analyst (or with an incapable one), and you do indeed need to rely on your own wits.

However, I have also dealt with several companies whose developers refused to give up that independence even if a proper analysis was presented. Their behavior fits exactly with that of Tom's, and they used argumentation exactly like yours.

Being able to work independently when you must is an admirable quality. Refusing to work in a team where the roles are divided makes you unhireable in most settings.

No. I am just challenging the premises and assumptions. I have no definite position yet. What I want to know is, why not delivering at the end of the sprint even matters?

That's not an argument, just a pure question. What's the metric? You haven't answered that question yet.

Rather than challenge these things, try to figure out for yourself how it's not in a company's best interest to pay their employees when they do not add value to the company's business.

Your cynicism about "useless meetings", "useless BAs" and "delivering is secondary to politics" is effectively perpetuating the shitty environment in which I surmise you've had to work.

@Flater I am not challenging anything, and I would appreciate if you just left the discussion between myself and Polygo as I think your approach is confrontational.

The only challenges I am presenting is to ensure I am understanding the premises and assumptions.

At the end of the day, I think the core of the disagreement here is the requirements

and to that, I think that actually, whether or not the requirements are an accurate reflection of the customer's needs and wants is largely irrelevant

Tom has a job, and that job is to deliver the requirements. If Tom is not doing that, then he is not doing his job.

If the requirements are wrong, then that is a problem, but that is no reason to not meet the requirements once they have been agreed and set

If Tom suspects that the requirements are bad, then he should build something that meets the requirements, but is modular and flexible enough to change as and when it needs to, to pre-empt the inevitable change requests that come through once the client realises that the product does not solve their problem

(which he should be doing anyway, on principle)

but all of these questions are secondary to the one actually asked

or at least tangential

Easiest way to do that is to just put Tom in the room when the requirements discussion happens