Dealing with "narcissism"
Hi !
I am working in a small company, a subsidiary of a bigger one, were we we have a lot of young, new or rather unexperienced developers and neither the Product Owner nor the team had any experience with Scrum before. The Product Owner is also the CEO and usually does not have a lot of time because of this. We also had a lot of changes in the team, mostly because our mother company needed them or they have left the (mother) company. Even if this setup is far from ideal, it worked quite well. But then we got some new developers and a graphics designer and things began to change. The new devs tend to create a lot of stuff, additional features or "improvements", which are not required. They also have little knowledge about the existing code base, and tend to create their own stuff, even if things already exists. On the other hand we have a graphics designer, who thinks he should the the complete design because everything else would lead to fragmentation and "he is the professional". He also shows some behaviour, which seem to be narcissistic to me:
* He is very charming for the first time, but starts taunting when someone is under pressure or makes mistakes.
* He widespreads a lot of misinformation exspecially what regarding what the Product Owner wants or seems to intentionally get things wrong.
* He makes statements that imply, that someone (team members, product owner, me) has no clue but immediately qualifies them afterwards.
* If some part of the team has made a decision, he starts to ask a lot of questions if it would not be better to do it otherwise, but without providing a concrete solution.
* Feels immediatley attacked and nearly starts crying when some of his ideas are overruled by the team.
To my surprise this seems to be very appealing to the young developers. I do not agree with this, because user interface design is not graphics design in my opinion and I think usuability comes first and this job should be done by the devs in a evolutionary process. Also his passion for pixel precise perfection has led to delays in the past. However I am the ScrumMaster not a team member. What is the best way to deal with such a situation ? Should I provide such bahaviour a platform in the Daily ?
Regards
Stefan
Hi,
It sounds like you have identified a challenge (impediment) to the team being more effective, so I would suggest it is in your gift to help the team understand and deal with it.
1) Is there a code of behaviour agreed with the team
2) Has the team agreed on how disagreement/conflict will be resolved
3) Has everyone agreed to use Scrum
4) Has everyone passed the open assessment (purely as a tool to demonstrate rudimentary understanding)?
The dysfunction that you are highlighting is that of "Hero Developer" and a lack of team behaviour. http://www.diegocaprioli.com/we-dont-need-another-hero/
The opportunity that you have is to get the team to understand that the non-PBI features are waste, and that there is a duty to the PO to build only what they have asked for (as agreed in Sprint Planning) to the quality agreed (as per the Definition of Done). If that says pixel perfect - then that is what the standard is.
You need to get agreement from the team on behaviour, so that might be an exercise where they brainstorm how they will demonstrate the Scrum Values (Focus, Respect, Openness, Courage, Commitment). Brainstorm how they are demonstrating the first line of the Agile Manifesto (Individuals and Interactions over Process and Tools).
Once you have got the team to shape an understanding of how to work together, then you can remind them around their behaviours.
Until you have got agreement about behaviours it will be tricky to get the team to commit to the team way of working.
Regards
Simon
Hi !
Thank you for the fast response. These are actually good questions. We have identified a bad communication style in the last retrospective. But there is no concrete agreement yet. I am also not sure if the CEO, who wants Scrum fully understands his role. The new developers seem to be overwhelmed which such questions. They also have not agreed to use Scrum. Basically when I heard about Scrum the first time as a young developer, I thought it would be nonsense. After some practice I noticed that I was wrong. It is basically a chicken & egg problem here. The best option seems to me to let them make their own expierience. But for this one needs a very long wind and the project can eventually fail. However I think these are good pointers, so I will check them out.
Thank you & regards
Stefan
Hi,
there is a fantastic book that addresses a lot of what your are raising https://leanpub.com/teamleader.
The team issues are there, Scrum is highlighting them.
An article that I read a long time ago, and reread regularly is Djikstra's Very Humble Developer.
https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html
Give the team time to read it in a retro and then ask for 2 words in response. This will mean they need to read it - and that they can't withdraw in to silence. Leave until the next retro, and then ask if anyone behaved in a humble developer way.
It is worth a try!
Regards
Simon
I hope that
>...his passion for pixel precise perfection has led to delays in the past.
Do you have evidence of this delay, and are there any stakeholders who can articulate its consequences?
> However I am the ScrumMaster not a team member. What is the best way to
> deal with such a situation ?
What you need to do is to encourage empirical control of the team's ability to incrementally deliver value. A key part of that is gathering metrics and feedback for retrospective analysis. This includes metrics regarding the delays incurred in seeking pixel-perfection, and the consequences of that delay to the business.
> Should I provide such bahaviour a platform in the Daily ?
You need to ensure that the Daily Scrum is conducted in a disciplined manner. That means ensuring that the team is inspecting and adapting its progress towards the Sprint Goal, and that the timebox is respected. There is no room in a daily scrum for narcissistic behavior...or indeed anything which does not help in the alignment of the team's effort to the Sprint Goal.