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

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

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. 

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

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

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.

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.