If you’re wondering about choosing Kanban or Scrum for your team or organization, I’ve found this post to be very enlightening on the differences in attitude and change provocation between the two. I’ve also found that integrating them into a single process can be very healthy.
Don’t exclude people in your team. It’s important that all people in your team are treated as equals and with respect. It may feel like a “duh” moment, but people get offended, deeply if they are left out of the loop.
Also, what kind of message does this send to the rest of the team?
“It’s OK – you can ignore or exclude that person too!”
If you have a team member that you find it hard to deal with, the last thing you want to do is exclude them from important discussions, team standup meetings, or even lunch.
You will only be making it worse.
Be brave and confront your fear of getting that person on board. Whatever your problem is with them, remember it is your problem with them. you have to solve it, because no one will do it magically for you.
No, firing is almost never the right answer. Firing someone means you’ve given up on yourself about growing that person and making them the dev that you want them to be. You get to fire people after at least 4 months of trying. Make that your hard line. Stick by it.
In those months – you will make that person part of the team, and teach them (if you need to) how to act as part of the team. You excluding them from the team activities (even one or two every once in a while) just helps them get more entrenched in their belief that they should be different and not act as part of the team.
Here’s the video of a talk about team leadership and beautiful teams I gave at QCON London this year. You can download the slides for this presentation here.
This talk is mainly about the first stage (out of the three team stages) – where the team lead takes charge of guiding and coaching the team.note: the original video for this presentation can be found at: http://www.infoq.com/presentations/Code-Leaders-Beautiful-Teams
The following is a guest post by Mike Burrows.
Until last year a developer, project leader and development manager in investment banking, Mike is now an IT Director in the energy risk management industry, still leading projects, still writing code. His blog (positiveincline.com) covers open source development and his recent Kanban implementation.
Roy's post "The 3 maturity stages of a software team and how scrum fails to identify them"  rings true to much of my experience as a team member, project leader and development manager, but still it touches a red button of mine! I'm grateful to Roy for his very gracious offer to let me respond to it.
My red button? I worry about the Agile community's recent focus on self-management. Don't get me wrong: self-management is a good thing, but in its current popular usage it has two problems:
- It fails to capture satisfactorily the much more powerful concept (borrowed from the study of systems) of self-organization
- There seems to be a move in the community to minimize the role of leadership
Self-organization is at the heart of agile methods, indeed it is the 11th of the 12 principles  behind the Agile Manifesto. Definitions vary, but in this context it describes the ability of a system (here the project team) to create for itself ways to increase its own effectiveness.
Looking at the team from the outside, we see "emergence" - new behaviors arising without external intervention. In the Scrum context this might happen as a result of team retrospectives (the 12th principle) or simply through the individual contributions of team members. Either way it's important to recognize that some of these new behaviors (i.e innovations) may be highly non-standard.
Leadership (whether from within or without) takes the team to places it would otherwise never have reached, perhaps never even have considered. This can be in terms of the team's internal structures or its external goals, but in the absence of leadership it is a rare thing for a team to take itself out of its comfort zone, to redefine its approach to the outside world, perhaps even to completely reinvent itself.
Here's the paradox: good leadership encourages emergence, but the leader must also be ready to take the team out of the ecological niche it has carved out for itself, however effectively. Yes, self-management is needed at every level (or the leader has time only for management), but we need also the humility to recognize its limits. Now there is true maturity!