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

@Sentinel: The issue isn't that the wireframe must not be altered (I agree with you, there's always some imperfections that need to be ironed out durin"g the development stage), but rather than Tom is making alterations independently without actually coordinating with anyone. If Tom finds an actual flaw in the design spec, feedback is appreciated, but rogue development is not. "doesn't say if Tom ever agreed to the requirements" It's not a developer's place to selectively agree to the specifics of the task they were assigned and independently override anything they don't agree with.

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

@Sentinel: When Tom started the task, the goal was already set (make a blue button). That is Tom's task. The design phase has finished. Having Tom redo all the work because they want to do it their way is wasteful and meaningless, and it shows a complete lack of being able to function as a member of a team. You are effectively advocating for rogue developers based on the hope that they will do a good job in the end.

@Sentinel: In essence, not every developer/employee gets a say in every company decision that is made. That's the reality of it. And to be honest, if Tom is unable to see anything other than his way, I'd be even less inclined to (optionally!) include him in the decision making process, as he seems unable to compromise and designs are often a compromise between different stakeholders.

There's two sides to this. On one hand, you have an employee who is invested in building a quality product. Bringing this employee into the design phase (if they aren't already part of it) might gain you a source of new and useful ideas for improving the product. On the other hand, you have an employee who is insubordinate and refuses to follow direct instructions to the point where they are not producing the product that you have committed to providing, which means that their output is not something you can give to the client, and therefore wasted. This cannot be allowed to continue.

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

@Sentinel: "flat structure" is not synonymous with "panocracy" (what Joe Average would generally refer to as anarchy). Just because you don't have a direct superior doesn't mean that your job isn't limited to a subset of the work that needs to be done. If Tom's role does not include design, Tom is being insubordinate in regards to their role, both as a developer and as a scrum team member.

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

@Sentinel: I get the feeling you're cherrypicking the issues to fit your interpretation. At the very base level, Tom is a developer who does not deliver, at times he doesn't even deliver his own interpretation of the task. The inability to compromise or follow someone else's decision is much more of an issue than "trying to help" is a benefit here.

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

@Sentinel The issue with "giving him his freedom" is that he's building what he wants, which is not what the client wants, and at the end of the day, if you don't build what the client wants, then you don't get paid for it, and sooner or later you'll all be out of a job. I agree that this developer should be allowed to put forward all these ideas he has for the product, but if the client says no and asks for something else, then he has to give them what they ask for, not something else. If giving the customer what they want makes him unhappy, then maybe he's in the wrong line of work.

@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?

@Sentinel: I also vehemently disagree that Tom should somehow be involved in the design process by pure merit of wanting to be involved. I want to run the company but that doesn't mean the CEO now needs to share their desk with me. This is not how a company operates. Tom is hired to do a particular defined job, and he's not doing it because he's busy doing something that no one asked/wants him to do. You concluding that Tom's manager must be the source of the issue is frankly insane. I have nothing against developer input but it needs to be cooperative, not dictatorial.

@Flater If this guy has many ideas, and he has arguments to back them up, then involving him in the design process has the potential to be helpful. Either his ideas are good, and will be used, or they're not, and he has an opportunity to have this explained to him so that he can understand why it has to be built some other way. Either way, he ends up agreeing with the requirements that are agreed with the client, which means he actually follows them rather than doing his own thing. Of course, he might just reject the explanations, but at that point it's more clear-cut insubordination.

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

@Sentinel Also, I'm not prejudging anything, I'm just saying that he needs to give the client what they want, and you said "an unhappy dev is not a productive dev", to which my response is that if he is not happy when giving the customer what they want, then perhaps he would be happier doing something else. Happy or not, he's already unproductive, because although he is producing something, it's not something the company can sell, which means from a business perspective, whatever he's doing right now is just waste.

@anaximander: I agree but that's the point I've been making all along (check my answer). If Tom is objectively correct then his contribution would be very much appreciated, but it needs to be communicated/coordinated. I very much appreciate developer input and am open to re-evaluating customer requests based on valid feedback, but the approach Tom is taking is throwing major red flags for their ability to function in a team.

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

@Sentinel: "we don't know that we he is producing is not what the client wants" The requirement/user story is expected to literally be what the client wants. You're suggesting that the explicit request of the customer (blue button) is not confirmation of what the customer really wants, and since Tom has decided it should be a green button, that's probably what the customer really wants? You are blindly assuming that whatever Tom says is objectively correct for every party involved, which is not productive. You're projecting your own story onto the given example.

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

@Sentinel: Following your logic, if the BA doesn't understand what the customer wants, Tom cannot know it either. Your answer is based on the assumption that Tom somehow knows the truth, yet you're not bothered by the fact that he does not in any way confirm his suspicion with anyone (PM/BA/customer/...) You seem to not have read the part of my answer that explicitly states that developer input can be valuable, but not in the way Tom is going about it right now.

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

@Sentinel: And somehow you know for a fact that Tom is more experienced than anyone else involved? That's a bold and wildly unsubstantiated claim. You are making up your own story and then projecting that onto the posed question. This does not contribute in any meaningful way to OP's question. I am done discussing this.

@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 though not all discussions. 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.

Let us continue this discussion in chat.