Forums

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. If you have left the first and last name fields blank on your member profile, your email address will be displayed instead.

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.

Non commited developer
Last Post 06 Jun 2014 11:21 PM by michael. 4 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Allan Ferreira
New Member
New Member
Posts:2
Allan Ferreira

--
05 Jun 2014 05:46 AM
    Hi all,

    I was having an internal discussion in the company I work for and we end up talking about what is the proper way to take a developer who is not commited with the work from a Developement Team. Personally I believe the Developement Team itself is ultimately responsible for chosing whether or not a not commited developer should leave the team. Though this could be seen as an impediment, the Scrum Master is not responsilbe for arbitrarily change the team. He or she should consult with the team and explain the situation and possible outcomes (project delay, project failure, etc...)

    So, I would like to hear your thoughts about these two following questions:

    1 - Is the Scrum Master or the Development Team responsible for take a non commited developer out the team ?
    2 - How should the Scrum Master consult with the Development Team (given he or she has already tried to change the developer behavior and it did not work)?

    Thanks
    michael
    Basic Member
    Basic Member
    Posts:132
    michael

    --
    05 Jun 2014 07:26 AM

    Hi Allan,

    Sorry to hear about your current situation, but its not uncommon.

    1. Textbook, the team is responsible
    1. Real life,I would guess that the team would rather you deal with it, even though the team is self organizing will
    use the leverage its an impediment, and that's one of your many tasks, so you should sort it out.
    (Much easier to let someone else deal with it, as its behavior, not a nice task to deal with)

    2. Textbook, Manager has a duty to employees for these matters.
    2. Real life, When its a behavior issue this is not SM or Dev team issue, this falls into management to sort out,
    they also have a duty towards, training and evaluating staff, training with dealing with this situation.
    You have tried to change the behavior and its not working, and at some point could be a flash point in the team.
    Seek some legal guidance from managers first as you want to be on the right foot first, nothing formal.
    Remember where there is blame there is a claim, and its supposed to be a team ethic.

    It could be they are having issues at home, work, many other things, your a SM not the answer to all problems.
    This is for management to get to the bottom of the why, so they too also have to help with the situation.
    Thats my thoughts, good luck and keep us posted.

    Michael
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1537
    Ian Mitchell

    --
    05 Jun 2014 07:34 AM
    Esther Derby has talked about "coaching a person off the team". I'd suggest that this might be the best thing for a Scrum Master to do in these circumstances. It would be interesting to hear what others think about this approach, and how it might be implemented.
    Allan Ferreira
    New Member
    New Member
    Posts:2
    Allan Ferreira

    --
    06 Jun 2014 07:51 AM
    Hi guys.

    Thank you for your thoughts.

    @michael: your considerations are really interesting and, fortunately, I'm not dealing with that situation. :) It came up in a conversation I was having with co-workers
    michael
    Basic Member
    Basic Member
    Posts:132
    michael

    --
    06 Jun 2014 11:21 PM
    Hi Allan,

    This will be a situation you will come up against in your lifetime of change.
    Its always good to try to look at the bigger picture, times have changed in terms of removals.
    There may always be some form of attempt on legal action if its done wrong in today's day and age.
    Imagine how cheesed off you would be if this happened, especially if you are named.

    The theory is you would give them the best possible chance with trying to change their ways.
    It could be something really simple, it could be something not so simple.
    Always be prepared for the eventuality it may not work and what next, well in advance.

    Worst case, always be prepared.
    Coaching and evaluate if its working, is is working for everyone in the team?
    Last thing you want is solve one problem and create three others.
    Is it working for everyone?

    Worst worst case, always be prepared a bit more, what could happen (Could be worse)
    It's when this doesn't work that is a nightmare scenario, by that time you would sense
    from the rest of the team its a serious problem and as a team would suffer due to the distraction.
    It would be really visible and could get to real flash point situation, if ignored.
    This will affect how you are as a team and that's the last thing you want.

    Worst Worst Worst case scenario, be even more prepared.(Can it get much worse)
    Lets just assume Management don't want to deal with it, they want you to remove them?
    Could be Management don't have the ability to deal with it, this is also a situation.
    There will be legalities if you do, and as SM this really isn't one of your services.
    You may find yourself on the end of some legal action is one real consideration.


    Why I suggested an informal chat with Managers is so that they can check out what the next steps are.
    If you wasn't running scrum Manager would be responsible for hire, fire and performance evaluations.
    Here there is no difference, for scrum to succeed must have full support in the organization.
    Managers are also critical to the success, after all they hired the developer.
    Doesn't matter how you operate, behaviors and being able to spot them can make a difference.
    Everyone laughs and says it is more psychology, perhaps it is and it does help a bit.
    In an ideal world its scrum so everyone knows the rules, consider what if those rules are broken.
    Work situations are different and so are people and their personal situation.

    Michael


    You are not authorized to post a reply.


    Feedback