Skip to main content

How to solve a quarrel between the PO and a member of Dev Team?

Last post 03:43 pm November 6, 2020 by Daniel Wilhite
6 replies
12:28 pm November 5, 2020

I have joined my current company a few months ago, and soon took over the SM role on an ongoing project. The previous SM and customer's PO couldn't find the common ground on various topics. I'm hoping to try and make things right. Yet, I'm also meeting some impediments along the way, mine being with the so-called RockstarDev guy.

From my standpoint, the main issue here has been a lack of communication during the course of the project, and that now escalated. Nothing that couldn't be fixed, I presume, but nonetheless it's not easy for me to handle.

The contract with the client is a standard time and materials agreement. It also says that stated values are only estimations, and can be adjusted according to the project needs. The RockstarDev was supposed to partake during the 3 mo period (the rest of the team 12 mo), and his engagement was to be and ramped down during the course of time. Because of some client-side issues, some requirements for theRockstarDev to do his share of work successfully came a bit late, so for some time, he couldn't do his tasks as intended.

However, once he was given those required inputs he asked for his share of involvement to be reduced, and said that his attendance on our ceremonies is no longer needed since he's (quote) "used to work outside the team". So, his proposal was to be called upon only when necessary, to do his part of the work. The PO was really upset with this idea because he takes Scrum seriously (the ceremonies as well, obviously) and isn't willing to negotiate much to reach some middle ground with RockstarDev. The stakeholders (the client's senior management team) don't have a problem with RockstarDev gradually leaving the team, but I can see clearly that the PO is worried the project will be jeopardized with RockstarDev reducing his availability (he would still be involved, but (as I mentioned) refuses to partake in the ceremonies, saying his work is almost done and it makes no sense for the client paying him for coming there and having nothing to report).

I would love to smooth this out, to show our PO he can count on my help removing the impediments to the team's work, but am also aware that: a) the RockstarDev has a lot of experience and is needed to help the junior team members on other projects our company started working on recently, b) I don't want to call upon what is written in the contract, but his tasks, while not quite over yet, were in fact mostly supposed to be done after 3 mo, and were late because of the delay on the client-side, c) the PO is afraid that the project results are at stake here, and hence his success in the eyes of his superiors as well (reminder that they had nothing against RockstarDev leaving the team, since it will cost them less, but I imagine will expect the same success level from the Scrum Team, particularly their employee - the PO, as till now).

I apologize for the lengthy post, as I am aware that it only partially has to do with Scrum. However, I was wondering if you've had a similar experience, and how did you tackle it? Thanks so much in advance for your time and your insights.


07:04 pm November 5, 2020

Might RockstarDev have a point, given that critical inspect-and-adapt events are positioned as being mere "ceremonies"?


08:37 pm November 5, 2020

I've read your post 3 times and I'm still struggling to see where Scrum comes into play.  You are working on a fixed schedule from a contract.  The team composition is determined by that same contract.  You have a RockstarDev that is not actually part of the Scrum Team.  You do not take advantage of the Scrum Events for the purposes of inspect and adapt.  You organization seems to be against adapting to change as evident by the rigid timeline that RockstarDev is attempting to hold and his actions being supported. It seems that the entire project was built around RockstarDev's availability and talents.  

I have been faced with similar situations in the past.  The way it was dealt with was by suffering pain and discomfort, not meeting the contractual timeline and the company doing the work having to provide work for free.  The "backup musicians" had to come out of their comfort level and do work that they usually left to the Rockstar.  The Rockstar had to learn that they are in fact expendable and that their contribution isn't as important as they thought.  In the end, the contractual deliveries occurred, the client was happy with the results but not the timeline, the contracting company learned from the pain, lost money on the contract and adapted their practices. But they still never used Scrum. 

 


08:47 pm November 5, 2020

What I miss from your story is whether the Development Team are expected, empowered and willing to be self-organizing.


09:38 pm November 5, 2020

@ Ian Mitchell - Well, I wouldn't say that they were mere ceremonies since I believe that they really do serve their purpose and the rest of the team are all coming and participating regularly. It's just that he considers them to be repetitive and expects to be excused because he doesn't have much to report (I know that the Dailys arent' about "reporting" to anyone, it's just an expression covering the part "what were/are you doing, are there any impediments"). From my understanding, he got sick of reporting the same impediments that were occurring for some time (the client not being able to deliver the inputs he needed to get his part of the job done, so he got tired of it and now when he actually has all the necessary inputs, he wants out). So it's kind of a challenge for me to determine what to do now. The client admitted that they didn't provide him with the inputs needed, when they were needed, and wants to continue the work. His attitude is "too late, I want out". 

@ Daniel Wilhilte - Thank you for your answer, much appreciated. The basic idea of RockstarDev being on the team was to provide his advice and expertise when needed, especially taking into consideration the fact that some members were inexperienced in Scrum, and he has a lot of projects under his belt. That being said, I do understand now that he isn't interested in taking part in our ceremonies and actually wants to work as a loner. He noted that he doesn't want to obstruct the team in doing the Scrum the proper way, and said the PO has a habit of micromanaging the team (I am still figuring out if this is true). He also said that PO's refusal to adapt to the change (him leaving) is not very agile).

The rest of the team is performing really well (the Reviews are almost always a success, and I'm trying to make the Retros as engaging and self-inspecting as I can). As for my company, they are willing to provide the client with the necessary expertise regardless of the fact that it states in the contract that he is at their disposal for the 3 months (it also states that these are only estimations, and are succumbed to change if needed). But since we are short on people, the RockstarDev is not happy with the project and wants off, I guess they are also trying to handle it with the least possible damage. Maybe it is for the best that he is released from the project and so we can continue performing and learning more about Scrum without him, but I don't see the PO being happy with that solution at all. Obviously, there's a lot more work for me to do, and this learning process is just getting started. I just hope that I make the right moves and help get this otherwise great project back on track.


11:30 pm November 5, 2020

The way you've described him, it sounds like you have a senior developer whose work is critical to the team. If I was the PO, I would focus on the actual product, rather than the Scrum events which are in jeopardy. At the end of the day, meeting or no meeting, is the work getting done? Will the client get what they paid for? Remember, delays happen. Just because the Client Executive estimated 3 months, doesn't mean it will happen in 3 months. I mean, the Germans are some of the smartest engineers in the world and their newest "airport" - it's really just a new terminal =D - was built 9 years behind schedule. Let's focus on the product and the quality instead of the schedule.


03:43 pm November 6, 2020

I'm going to get really frank and this is entirely my opinion and in no way represents anyone else in this forum or scrum.org. 

RockstarDev needs to get over himself.  He is acting as if he is the only think keeping the company together. He isn't behaving as a team player and it appears he is more concerned about himself than the success of the company.  He doesn't like the situation so he feels he should be able to distance himself so that if something goes bad, he won't be included.  He is a loner and does not want to contribute to anyone else's success. And if there are problems encountered he will find ways to place the blame on others.  In an agile environment, that can be toxic.

Honestly, if I were in your place, as part of my service to the Product Owner and Scrum Team, I would help people understand how someone like him is not going to make the team better or improve team cohesion.  In fact, his desire to be a loner and the most important person will cause the team to be less communicative, less thoughtful, and less creative.  Everyone will look to the RockstarDev to make all the decisions and tell them what to do.  The team will be better off if he was allowed to quit the team.  Then they could collaborate on the work, help each other learn things that they need to do the work, improve their skills across the team, and deliver something that they will all be proud to have done. 



If this person is as good as he seems to think he is, he would have been able to help the client come up with the information.  I have worked with many extremely talented people that when faced with a lack of information would formulate possible solutions and propose them to the client.  This helps the client to see potential solutions that they may not have considered. It will allow the client to provide feedback and correct direction.  But this RockstarDev chooses to blame the client for his inability to do any work and blaming them for his failures. 



Consider the project a journey.  If someone asked me to find them a way to get from where they are to Paris, France but stated that there would be additional information provided about some limitations and specific stops to be made in route I would still be able to start working on the journey plan.  I could easily map out multiple routes and start working on logistics for common portions of the journey.  I could share the routes with the client and they could then provide additional information as it was available so that the routes could be adjusted.  In doing so, some of the routes would surface as unacceptable alternatives.  This is how agile software development works.  Do something, inspect the results as new information surfaces, adapt the work, do something and repeat the process over and over until a result that is needed has been accomplished.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.