The Elastic Leadership Book



        RSS Feed

Latest Entries

First time here?


What to do if some people in the team just don't want to take a task?

Recently I found this question on LinkedIn:

We just started using Scrum in our organization and today is the last day of our first sprint. In the beginning, after the second part of the sprint planning the tasks were identified and everyone had to tell what task will be working on.


But two members of the team just sat down on their desk and do nothing.

I've been waiting for an hour and after that I just assigned some tasks to them.

I'm afraid that this will happen again in the next sprint and the result will be that the team will just wait for me to tell every person what task to do.


It really depends on the what stage your team is in.

In the chaotic stage, you don't have time to wait around for people to realize that some team members are not taking responsibility. Talk to each of them personally and see if there is a good reason for them not to take that task . Either bend the process so that all team members are now able to take tasks, or get those out of order back into the team guidelines, until the chaotic stage is over. In chaos you can't afford to have people not on the same track as the others.

In the learning stage, ask the people what they are going to do about not being part of the task taking process. ask them to fix it themselves, and make sure they commit to what they are promising. follow up weekly or even daily. "grow" them to this habit, or "grow" yourself to realize maybe that habit isn't right for your current team. Sounds weird, but sometimes you need to remember to fit the process to the team, not the other way around.

In the self organizing stage, create constraints or situations for the team that will force them to face the choice of taking tasks on their own or not. For example, you can give requirements that no team member has specific specialization on, or the opposite. see what happens. you an also introduce people from other teams into the team, who might have a problem with this behavior and will speak up to the offending team mates on their own. The point is, at the self leading stage, you don't tell people how to do something. you just give them the boundaries in which to achieve it.


A good leader won't need to ask

A good team leader would not need to ask you about the good things you've done in the past year. They should be attentive enough to your personal progress, and helping you shape your learning, that they might actually know about more things you did great this year than you.

If you are that team leader, and you need to ask, it may be good to take 30 minutes of personal time, and review within yourself, what you think that person has done good this year. If you can't, try the following approach:

Ask colleagues of that person about one good thing they have seen him do this year (or month). compile a list of five such things.

Now, compile a list of actions that you will take,   in the coming month, and year, to make sure this never happens again.


Video: Elastic Leadership in software - InfoQ interview

during the recent QCON London 2011 Conference, Michael Hunger of Infoq interviewed me about what I later started describing as “Elastic Leadership” – The team leader changes her leadership style (dictator all the way through to coach) based on the current team stage.

You can see the full video interview here.

I look a bit tired, but I hope my message was clear.


12 Behavior Anti Patterns You Will Face As a Software Team Leader

Most of these, we covered today on the 1st day of my Lead Better course  that is taking place in Oslo, with live simulations. The purpose was to see how a team lead deals with these anti patterns when going through team chaos. How the team lead might act to these behaviors when the team is in learning mode, is very different than how I'd expect them to react when in chaos, as was simulated today.

Team Member Behavior Anti Patterns

  1. Extremely shy and afraid to say when he is done with a task. can be idle and helpless if you don't notice.
    1. Lead needs to give 'simple rules' to that member so they know exactly what to do in a situation when they are idle. for example "if you see that you're not doing anything, contact me immediately. We can't afford to have anyone not working right now"
    2. If it persists, the lead can also offer a more assertive statement such as "If you want to continue to be part of this team, you'll have to chip into the effort. I know this is hard for you, but I expect you to rise to the challenge and contact me if you don't have anything else to do"
  2. Lazy, who only does the simplest thing, so he can say he did what he was told
    1. Lead can be direct and demand more from that person, or alternatively remove them from the team until they can spend more time understanding why this is happening.
  3. Negative - constantly saying things like "I knew that would happen" or "really? that would never work"
    1. Same as with lazy
  4. Would only work alone. does not like working with other people
    1. If they do a great job on their own, and this is usable to the team lead to get out of chaos, there's no harm in letting that person work on their own.
    2. If it hurts the team, or continues chaos, see 2.1
  5. Is the designated 'architect' and refuses to do anything else
    1. See #4
  6. Constantly multi tasking on a different task
    1. Either reset expectations to mgmt about not doing that other task 
    2. or remove that person from ccurrent effort and reestimate effort to mgmt
  7. Only comfortable working with a specific kind of work (only on the GUI, for example)
    1. see #4
  8. Working really SLOWLY
    1. They might be perfectionists. see # 12
    2. If it doesn't hurt the team during chaos, no problem
    3. If it does, find work that they CAN do fast, or much better than everyone else
    4. If they can't do anything fast, put them on a low risk item, because teaching them to be fast takes time you don't have right now
  9. Two team members who argue without any resolution on some technical detail
    1. Argument isn't bad, until it's unproductive or bottlenecks the team, so..
    2. Ask them to choose which solution they want o try first
    3. Give them a time box to pick one solution to go with
    4. Select the solution for them (it's chaos time)
  10.  One team member follows another team member blindly, even when it hurts the current effort to get rid of chaos
    1. separate them form working on the same task together until chaos is over and you can handle it
    2. Ask influencer to stop influencing the influenced until chaos is over
  11. Working on personal projects not mandated by anyone (remember, this is during CHAOS!)
    1. see #4
  12. Perfectionist in a time of chaos - will make sure everything is the right color, when the wheels are not even working. 
    1. Explain that this is not the time for perfectionism (unless that's what's demanded!), but a time to ship so that chaos can be over fires are put out.
    2. Give them simple rules to follow on when to stop:"if you see yourself matching colors, stop and go fix something that's in the bug's list. do NOT WORK ON COLOR MATCHING in the next 3 days!"
    3. If that does not work, use authority to ask them to stop

(what other anti patterns do you know?)


Outside disruptions and anti patterns

  • Requirements keep changing
    • The lead needs to keep up or set expectations correctly
  • Impossible Fixed time, cost, and features - what would the team lead do in this case?
    • Ask which of three factors can be 'moved' - "I either need more time, or more people. If I can't have either, I will need to commit to less features. Here's what we CAN do"
  • "I need one of your devs for X time for a customer demo"
    • If it doesn't hurt current team tasks, no problem
    • If it does, explain that the team will need to re-commit to a different time schedule, or different feature set, if other people cannot be introduced into the team (even if they were, that also takes extra time to get them into the team and project culture)


Since today was all about chaos, it was interesting to see how afraid people can be to be a little assertive to get things flowing again. overall, many behaviors which would fit a team in the learning stage, were exhibited for a team in a chaotic stage. 

I feel that at least one person in the course has come out of their comfort zone more than a little during this task, and for that, I am very very happy.


Lead Better - Skills for software team leads, Course next week in Oslo

I'll be doing my "Lead Better" course in Oslo next week. There are 3 places left if you want to join us. 

If you've ever tried to convince your team to do unit testing or TDD, but failed miserably at getting them to do it. If you think "no way can my team ever be like those highly productive teams I read about", or even if you're just scared enough and not sure what to do next - this course can help you wrap your head around your job as a team leader in software.

If you're about to become a team lead, or have just become one, or even if you're an experienced team lead, this course can help master the things no one guides you about: how to drive people, to make a difference, to motivate, and influence the direction and behavior of the people around you.