@WilnaMurphy: You can never cross the ocean unless you have the courage to lose sight of the shore. - Christopher Columbus.
@leadershipcoach: "If I had asked people what they wanted, they would have said faster horses." ~Henry Ford
]]>@aycangulez: "There is nothing so useless as doing efficiently that which should not be done at all." - Peter Drucker
Which software am I talking about?
]]>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.
]]>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" [1] 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:
Self-organization is at the heart of agile methods, indeed it is the 11th of the 12 principles [2] 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!
[1] http://5whys.com/blog/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.html
[2] http://agilemanifesto.org/principles.html
Mike Burrows
http://positiveincline.com
http://twitter.com/asplake
I’ve learned to recognize three states a team can be in in terms of maturity -
The trick most team leaders need to do is to recognize which stage a team is in, and to advance their team to the next stage.
I would easily say that most teams are chaotic – either in technical lack of knowledge (‘what’s source control?’), lack of motives (‘I just code X lines of code and try to avoid QA’), or lack of ambition (‘things are fine the way they are’)
You can’t take a team that doesn’t even do source control, and say “you’re self managing from now on, GO.” - no one will know what to do, or have any inclination to do it.
The process of bringing a team to maturity, where a team leader as a dictator is never needed, still lacks a name. I’ve been asking around for possible names for this process. some of them were quite interesting:
Different team lead tactics apply to each stage. For the same reasons Scrum Masters (who are nothing but active coaches) fail to really help immature teams, so do team dictators hurt more than they help truly mature, self managing-able teams.
-- if only to bring some much needed peace and quiet to a team that might be mostly struggling to keep its head above water all day long.
A dictator team lead is there in the first stage, to bring the team up to a specific state, where they also have the time and patience to learn new things. The team lead will help put out fires and put the team in a bubble so that decision making becomes easier until the team can make its own decisions. they will start doing code reviews and many of the things this blog advocates for.
Many of these same things will be seen with a very big question marks on the faces of many agile coaches out there. They fail to realize that a chaotic team still isn’t ready for a coach. it needs a direction, a back wind, and an open road to get going.
As the team lead feels that the team has reached some “safe shore” – they will move on to the next stage in the team’s life – the learning stage – the stage where a team will learn the skills needed to become self managing, all within a very concerete seieres of constraints that will slowly open up and the team progresses.
For example, the team lead will insist that code reviews be done on each check in, but will teach the team to do its own code review so that the team lead is no longer the bottleneck, and so that the team learns essential skills for code quality and decision making on what’s an acceptable piece of code.
Slowly but surely a team can progress to become fully self managing. At each stage of the team’s life, it learns skills that help it make its own decisions, until, at some point in time, the team lead does not need to make any day to day decisions. The team has all the skills needed to move on to the next stage.
This and the next, are the stages many scrum masters need in order to achieve anything. Sadly, most teams are not at this stage, and nothing but some good old fashioned dictatorship can help change things for those teams.
A team that can self manage just needs a coach for the personal team members, to grow them, to teach them new skills. They need someone to keep an open eye for interesting things that they may not have noticed, and they can use (not need!) a second look every once in a while if they are facing interesting dilemmas.
]]>an irreverent measurement of concentration of information in a single person, or very few people. The bus factor is the total number of key developers who would need to be incapacitated, as by getting hit by a bus, to send the project into such disarray that it would not be able to proceed
From my personal experience, I'd say that more than 70% of projects suffer from a bus factor of 1. It only takes one specific person in those teams to not be able to be there for the project to halt or slowly die in painful agony as people try to makeup for lost knowledge.
in your mind, go through each person in your team and ask yourself if
the project could go on pretty much as usual if they were fired tomorrow. (fired is important because people who leave in good terms can still play ball and get you through tough stuff they worked on through phone conversations).
If you say “no” or even hesitate about the answer, you’ve found the bus factor in your team.
Most of the collaboration techniques you’ll find in many agile methodologies like XP try to solve the idea of the bus factor, but you don’t have to be agile to use those techniques.
As a team leader, you might just be the biggest bus factor carrier of them all. What happens if you get fired tomorrow? can the team go on without you?
Your biggest challenge as a team lead, over a long period of time would be to make yourself dispensable – to make the team mature enough to continue on day to day things without needing you. Removing yourself as a bottleneck is one of the best things you can do for yourself and your team.
]]>Everyone likes to do #1. Only some do #2. Great teams also do #3.
This post is about #2.
For example, you can start looking for words that are not committing to execution:
spot these things and see if you can ask people to actually commit to the thing they need to do:
If someone can’t commit to that – that’s good. Maybe they are not sure they can – maybe there is something stopping them. But you won’t know until you can either get them to commit, or get them to say why they cannot commit to it.
Also notice how there is a specific end date. Committing to something with an end date make things more real, and also prevents whoever is depending on that thing from bothering the doer. “Is it done yet?” “How about now?” .
No need to ask. They committed to do this by Monday.
Doing all this talking in an open daily standup makes the commitment more important. it’s not just you and someone else. now it’s you telling the whole team you will get something.
If your team members don’t know how to verbally commit to something, you can teach them. You can actually ask them to say things differently:
“Can you say you will do it by date so and so? Is that something you can commit to? Why not? “
Of course, the biggest hurdle is that sometimes people really can’t commit to something if they don’t have full control of it. Expecting people to commit to something that depends on other people is less realistic.
If that happens, see what things that person can have control over. For example, if the task is about getting a bug fix to a client and making sure it’s closed by Monday – the dev might have control over actually sending the email to the client, but they have little control over when the client responds back. In such a case they can commit to sending the fix to the client .
There should be no such thing is a failed commitments. the moment one sees that they will not make the deadline, they should notify whoever they committed to, that they will no make it in time – this allows the team to see if something can be done to maybe still get that thing in time by reorganizing or changing priorities.
A failed commitment means you won’t live up to what you promised and you didn’t notify anyone beforehand that you will not make it in time. that is something that is fully under your control and should not happen.
]]>