Return to 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 don'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).

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.

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. Sometimes it just feels that he never thoroughly read the acceptance criteria of the stories, did something different and try to argue his way out.

What is more is that Tom always like to add his own stories to the sprints (even though he couldn't finish the stories he agreed to). This would involve working on things planned for the future sprint, or adding things that are not required by the business users (like creating a login animation).

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. The company is MNC which doesn't really fire people unless they are really bad.

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

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.

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.

What is more is that Tom always like to add his own stories to the sprints (even though he couldn't finish the stories he agreed to). This would involve working on things planned for the future sprint, or adding things that are not required by the business users (like creating a login animation).

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. The company is MNC which doesn't really fire people unless they are really bad.

I am the PM of a 4 person team that is on agile. There is one developer (let's call him Tom) who always don'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).

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.

Almost all the time, Tom's deliveries will have some small deviations from the wireframe or 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.

What is more is that Tom always like to add his own stories to the sprints (even though he couldn't finish the stories he agreed to). This would involve working on things planned for the future sprint, or adding things that are not required by the business users (like creating a login animation).

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. The company is MNC which doesn't really fire people unless they are really bad.

I am the PM of a 4 person team that is on agile. There is one developer (let's call him Tom) who always don'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).

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.

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. Sometimes it just feels that he never thoroughly read the acceptance criteria of the stories, did something different and try to argue his way out.

What is more is that Tom always like to add his own stories to the sprints (even though he couldn't finish the stories he agreed to). This would involve working on things planned for the future sprint, or adding things that are not required by the business users (like creating a login animation).

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. The company is MNC which doesn't really fire people unless they are really bad.

I am the PM of a team that is on agile. There is one developer (let's call him Tom) who always don't follow requirements and like 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).

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.

Almost all the time, Tom's deliveries will have some small deviations from the wireframe or 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).

What is more is that Tom always like to add his own stories to the sprints (even though he couldn't finish the stories he agreed to). This would involve completing stories planned for the future sprint, or adding things that are not required by the business users (like creating a login animation). And he never inform anyone about his deviation from agreed requirements.

It is pretty frustrating managing the project because 1)you never know what will be delivered, 2) Tom keep changing/adding requirements himself. 3) Quality issues and buggy code.

Additional facts - Tom is the most experienced developer on the team. The company is MNC which doesn't really fire people unless they are really bad.

I am the PM of a 4 person team that is on agile. There is one developer (let's call him Tom) who always don'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).

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.

Almost all the time, Tom's deliveries will have some small deviations from the wireframe or 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.

What is more is that Tom always like to add his own stories to the sprints (even though he couldn't finish the stories he agreed to). This would involve working on things planned for the future sprint, or adding things that are not required by the business users (like creating a login animation).

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. The company is MNC which doesn't really fire people unless they are really bad.