RSS Feed

Latest Entries


First time here?


Monday
Apr112011

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.

Thursday
Apr072011

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.

 

Monday
Apr042011

Elastic Leadership 

 

  • Elastic leadership is about team context. It is about understanding that you need to lead the team differently, based on which phase you discover the team is in. The phases  can change from day to day or week to week. You keep adapting to the new phase, or you will  keep them from growing.
  • Elastic Leadership is about team transformation.  You continually drive and transform the team to get better than they are, up to the next phase. From chaos to learning. From learning to self-leading.
  • Elastic leadership is personal transformation. You may find it easy to be a command and control leader, but you'll need to learn how to teach and delegate when the team starts out it's learning  phase. In the self leading phase, you'll need to to let go of actually telling people what to do, and only change their surrounding constraints - are you ready for that? can you go a whole day without telling anyone in the team what to do?
  • Elastic leadership is personally scary. you are afraid of losing your friends, you are afraid to fail, and you are afraid of getting out of your own comfort zone to accomplish the various types of leadership for each team phase. 
  • Elastic leadership is highly effective because it looks the current situation straight in the eye, and does something to improve it. Because you assume things change constantly, you are prepared to also change things constantly, and change based upon any needs the team has as they arrive. you do not close your eyes in the face of hardship. instead you embrace it as a learning opportunity.

 

Saturday
Mar192011

Slides: Team Leadership In the Age of Agile

Here are the slides I've used during my latest talk at QCON london 2011 :

In this talk I explore the three maturity stages of a software team, and how a team leader can adjust their leadership type based on the current phase the team is in. I also explore common mistakes and techniques team leaders can take to make sure their team gets on the road to craftsmanship and maturity in software development.

 Some of the topics covered include stuff I've written about before:

 

 

 

Thursday
Feb032011

What are you going to do about it?

A couple of Days ago I finished the first “Lead Better” course for software team leaders in Oslo. It was the first time I had done this course out of Israel.

It was a great feeling to get the following email today from Michal, one of the participants of that course. In the email he also refers to an Integrity and commitment based technique I wrote about before, and that we covered deeply during the course.

 

Hi Roy,
 
I participated in the course “Lead better” 2 days ago in Oslo.
 
I committed to you that I would ask at least one time the magical phrase “What are you gonna do about it” to my teammates and let you know about results.
It happened sooner than I would expect. More, the problem was solved very quickly.
 
On a standup meeting one of my teammates said:
-          “we need to test the new configuration somehow”.

-          So I immediately asked “What are you gonna do about it?”

-          ... seconds of consternation... “eeehhhmmmm, I will figure out something”

-          “By When?”

-          “Today, an hour after scrum meeting, I will reconfigure the platform and let you know about the results.”

-          “Great” :)

 
And it worked! In an hour I got him with a rest of a team discussing details and in another hour, the platform was reconfigured and fully tested! It would never happen so fast if he had not commited to do so :)
Thanks.
 
Michał Wikliński