Submitted by Trashbox on
in
Forums
Hi,
How should I react as a Scrum Master when in a team of mostly pragmatic people, I have a very detail-oriented "devil's advocate" kind of guy?
The Product Owner is afraid, that the negativity will affect the teams performance over the long run and has correctly stated, that Mr Detail does also gets the least work tasks on the Scrum board done. The project is under high time pressure as we will barely be able to implement the absoult minimum of requirements for our first release at the end of this year.
I can see that the negativity could take some of the teams enthusiasm away and that the others seem to perform better. But I do see some positive effects of his style, too:
While others simply implement a given feature the easiest way possbile, this guy looks if there is a coherent apporach in the system to similar problems and refactors stuff. He also focusses (maybe too much) on good documentation.
The management of the inside customer (where the product owner is from) has stated, that they may want to replace the guy. My management (the internal IT department) definately wants to keep the guy.
Until now I tried to present the advantages of his behavior to the customer while giving him feedback, that he should keep his work as transparent as possible and not work on complex refactorings and quality issues, that are not on the Scrum Board. Therby increasing his visible performance.
I am unsure how his performance really is. I also am not sure, if he adds to diversity and prevents the team from taking a too narrow perspective or is just holding the team back.
I would appreciate your thoughts and suggestions.
Thanks
Matthias
Refactoring: It's all about balance
BLUF: Work with the team to create and enforce a consensus about what, when and how to refactor/document. Help the team to strike a balance, and to get out of the "one guy cleaning up after everyone else" setup. This should improve the team dynamics, and make this guy's performance more comparable.
I see two main topics here. The first is how to balance refactoring with technical debt. The second is this specific guy's behaviour, including perceived negativity and possibly lacking performance. I will concentrate on the first topic in my posting, as it's the one I feel most knowledgeable about.
Not refactoring (and not documenting) at all will slow you down well before you reach your end-of-year deadline. Or, expressed positively: In a half-a-year project, there will definitely be some refactoring opportunities and some level of documentation that will pay off well within that timeframe.
On the other hand, refactoring (and documenting) everything that could possibly be refactored (documented) will slow progress to a crawl immediately. Some refactorings would pay off only after a year, or five years, or never.
One guy refactoring while everybody else is recklessly charging ahead will simply not work. Also, the team dynamics of "one versus all the others" are as unhealthy as it gets. This one guy probably feels he is the lonely person who has to clean up after everybody else because it is the right thing to do and nobody else is doing it - that is, they are not doing their job right. The rest of the team probably feels they have to pull part of this guy's weight on feature development, while he is "goofing off" doing not-so-important stuff. As I said, not healthy.
So, you and your team need to strike a balance on how much and what to refactor/document, and how to organize that. There must be some sort of consensus about this in the team, and the actual refactoring/documentation must be spread evenly across the team.
In the teams I'm part of, it works roughly like this:
1) You are encouraged to do minor, local refactorings as you go along. This is the little boyscout rule: A good boyscout always leaves the campsite a little cleaner than he encountered it. But, there has to be a balance: You don't do 4 hours worth of refactoring on a task that was planned to take 2 hours. In other words, "timeboxing" is the magic word. If a refactoring would lead you to go over the estimated time of the story/task, you talk with your team lead about whether it's worth it to do the refactoring right now anyway, or wether it should be postponed, e.g. until the next time somebody is doing some larger task in that area.
2) Larger refactoring opportunities go on an internal backlog. The team estimates and prioritizes those, and discusses with the product owner if and how many of the highest value stories should be scheduled for the next iteration. The question to ask in prioritization is: How much is this specific piece of technical debt actually hurting us, i.e. slowing us down? If it's just ugly, but slowing nobody down, it should not get refactored.
Once there is a consensus, it is "just" a matter of enforcing it. As enforcing team rules falls directly into your area of partial role power as a scrum master, I, personally, feel it would be OK for you to give feedback on this topic.
Then, if everybody is doing roughly the same amount of refactoring and documentation, the performance of this specific individual should become easier to compare with that of his teammates.
In conclusion, a word about the "negativity" you mentioned. Just pointing out opportunities for refactoring does not need to come across as negative ("Hey guys! I just found a neat new way of doing X! If we spend some time on the code here, we can save ourselves tons of trouble in the future!"). If it does persistently come across as negative, this individual's boss could probably work with him on improving his communication.
Sorry for the long posting - I guess it's just a topic I have a lot to say about. I hope some of that is helpful to you!
Good luck,
Falk
--
Falk Bruegmann
3-6-4-7
I also have a Devil's
I also have a Devil's Advocate in my scrum. When properly channeled, he's an invaluable member of the team that keeps us from flying off the road at high speed. He surfaces edge cases that no one else has thought of, etc. How I channel his strengths:
Adjusting feedback about:
Reinforcing feedback about:
Steve Jobs impact - immediate and longer term value.
The above advice is very good. The only thing I can add is I wonder what it would have been like trying to manage Steve Jobs - crazy attention to detail and opinionated and judgmental? Not saying this guy can deliver the results that SJ did t but it strikes me the conversation between you and he could draw on these advantages but trying to get him to add practical solutions to the things he is seeing and the detail he is getting hung up on (as I take it).
The coaching element from you should be on two levels - his immediate performance but his longer term value to the organisation and profession - one key thing that comes to mind is developing some analytical control in him that asks the questions "Just because I can see it does it mean I should say it".
A real risk in teams is shooting the guy that maybe not so easy to go along with group think or "hey I will just fit in and create no waves".
Not an easy issue and I am sure there is much more complication but think these kind of team players are valuable but they take work and a lot of that control work needs to be done by the individual under the managers guidance or "reflection".
Steve Prothero
Truetoyou
Thanks!
Thanks a lot for your valuable suggestions. I will put them to work in the next days
Update
Hi
I just wanted to give all of you an update, since your comments really helped me. The situation has improved a lot and the team is performing at a very high level. It looks like we will make the deadline.
I first gave him positive feedback about his focus on quality and overarching architecture improvements. A few days later, I gave him the adjusting feedback you recommended about working tasks that aren't on the Scrum Board. I told him, that he should have a short discussion, if refactorings or additional features come to his mind while working on a story. Then the team or the product owner decide what get's done and what not. By this, a lot of nice-to-haves have been moved to the backburner and his performance on the board tasks increased.
He directly implemented the feedback. Interestingly, it also affected his devil's advocate behaviour. He is now acting a lot more pragmatic and positive. The product owner wants to keep him in the team now.
Thanks again for your help!
Matthias
Wow! Impressed by
Wow! Impressed by everybody's input especially falkb
BLUF: How to get a devil's advocate to see the big picture.
Devil's advocates look for problems. They are very much needed for jobs where safety is critical (medicine, pilioting) or the cost of a mistake is high (accounting). However when these traits are taken to an extreme the person loses sight of their goal.
Continue to focus this person on the goal by asking questions like "Why is this important" (make sure you do it w/ a smile & a curious attitude).
Possible answer: Because this needs to be done right.
Next question: And when it's done right then what happens?
PA: It's efficient. It runs fast. It's perfect.
NQ: Efficient and fast... why are those important?
PA: ummm, because then the customer will be happy...
NQ: ohhh, so it's all about the customer?
PA: Yes.
NQ: Ok, hypothetical situation... Suppose that you're a customer anxiously waiting for the release of some new software or video game. I tell you that you can either 1) have what you want now knowing that the program is at 99% but not perfect. The issues aren't anything you're likely to notice... some of the pictures could be improved... we can optimize some of the code and give you an extra 5 frames per second... but to do that you'll have to wait 100 days. What do you want to do?
You're going to have to go through this process multiple times with your devil's advocate type people. And the more times you do it the easier & faster it will get. You'll eventually get to the point that they'll "get it" after only the first question, laugh and say "You're right, that's not really very important at all."
---
gabriel
Please like my Facebook Page if you agree with this comment.