The Elastic Leadership Book

 

 

        RSS Feed

Latest Entries


First time here?


Monday
May242010

Video – Code Leaders and Beautiful Teams

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

Tuesday
May182010

Leadership and the mature team

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:

  1. It fails to capture satisfactorily the much more powerful concept (borrowed from the study of systems) of self-organization
  2. 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 [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

Monday
May172010

The 3 maturity stages of a software team and how scrum fails to identify them

Many so called ‘Agile’ teams fail so miserably to deliver for the simple fact that the teams simply are not mature enough to be part of an agile process that requires self managing teams.

I’ve learned to recognize three states a team can be in in terms of maturity -

  • Chaotic Stage – the state where a team does not posses the skills, motives or ambition to become a mature self managing team.
  • Mid-Life stage – where a team possess some skills for self management and decision making , and can make some of its own decisions without needing a team lead.
  • Mature stage – where a team is practically fully self managing and a team leader is mostly a coach rather than a decision maker.

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.

Most teams are chaotic

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.

Maturing a team

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:

  •  
    • Resetting a Team
    • Rebooting a Team
    • Reorienting a Team
    • Redirecting a Team
    • Team Regrouping
    • Team Rebirth
    • Team Renaissance
    • Team Reframing
    • Team Reincarnation
    • Team Resurrection

Each stage needs a different kind of team leader

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, as do team dictators, who hurt more than they help truly mature, self managing-able teams.

The chaotic stage needs a strong, dictator like leadership

-- 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 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.

The Mid-Life stage needs a coach-dictator

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 concrete series of constraints that will slowly open up as 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.

The Mature stage needs a coach

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.

Monday
May172010

The Bus Factor - Why your ‘best’ developer is your biggest problem

From wikipedia, a “Bus Factor” is:

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.

How do you recognize the bus factor?

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.

How do you get rid of the bus factor?

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.

 

  • Use daily standups to share critical information
  • program in pairs every once in a while, or at least on key components of the system
  • do code reviews on every piece of code that gets checked in
  • do weekly half hour or one hour presentations by team members about interesting stuff they did this week
  • Ask the bus factor carrier to teach someone else from the team to do their work and vice versa. Tell them that next week they will be working alone on that material so they should get ready for that by working together on it.

The biggest bus factor is you

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.

Sunday
May092010

My team keeps breaking their promises. What can I do?

Execution – actually having the team get things done– requires people to :

  1. Say what they will do 
  2. Mean it (be committed)
  3. Do it

Everyone likes to do #1. Only some do #2. Great teams also do #3.

This post is about #2.

There is a vast difference between people being committed to something, and people saying something.

For example, you can start looking for words that are not committing to execution:

  • I’ll try to get that to you by Monday”
  • “Someone should get that thing fixed”
  • “I hope to get to that later”
  • “I think I can make it”

spot these things and see if you can ask people to actually commit to the thing they need to do:

  • “I will do this by Monday”
  • “I commit to getting this done by Monday”
  • “It will be done by Monday”

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.

Don’t under estimate peer pressure.

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? “

I can’t commit to something I don’t have control over

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 .

Failing commitments

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.