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.