RSS Feed

Latest Entries

First time here?


The three stages of learning team leadership

or anything else, for that matter: Shu-Ha-Ri :

  • Practices
  • Principles
  • Values

*see related to this:




This blog is right now at the "Practices" stage: Lots of "Do this" and "Don't do that", with just a little "Principles" thrown into the mix.

The values? Those take time to develop. It's those "Values" that will make people write comments on these blog posts that don't agree with the post's sentiment, as they talk about a practice, instead of a value (when they coexist nicely).

For example, on my "Own your team and territory" post, i got quite a few comments that say "You must let the team learn how to do these things etc, which is more in terms of a "value" system.

But in the context of a "Learn initial practices" system, it does make sense, since that person has not yet masterd and feels comfortable with the accompanying princinples and values attached. when they will (and they will eventually) they can (and should!) start questioning their tactics - for at this point, in this context, those initial practices are the right thing:

= they are easy to follow

= they will bring some peace to the team and the lead so they can start focusing on more principles

= the values will have to be "earned" during time.


Test Driven Development is the same way:


  1. you start out with the 3 rules of TDD (practices - failing test, code to pass, refactor)
  2. you learn why they matter (the principles - test the test, think small, have partial work etc..)
  3. you learn the values of a SOLID designed system, and the ability to take and get quick feedback, and start aiming how and when you use TDD within those values.



One-Liners a new team lead should and shouldn't read

Alistair's blog\wiki has a set of specific one liners from programmers - to newly minted team leads.

The whole list is here.

My 3 favorites were:


Whatever their job is, help them be better at it.


You are now a junior person in a brand new career that you never were trained for – and keep in mind that the medium you are working in is PEOPLE.


People will bring you their issues with teammates – it will help to give your people some training in how to deal with those issues themselves.

Notice that they all talk about the idea that you are working with people, and that driving people to be better, and caching them to solve their own problems is important.


Now, here are a couple that I didn't like:

YOU ARE THE ABSTRACTION LAYER – you provide the Bubble of Happiness.

Only to a certain point. Once your team is ready to face challenges, it's OK, and even welcome to start letting them deal with real world stuff  - how do they handle outside interference? what happens when a higherup asks for a small feature really quickly? 

A mature agiel team should be able to handle these, but don't try to let them handle it if you're all still learning the territory. It's OK to have an "incubator" where the team lead only gets all the "heat" from the outside, but that doesn't mean that a team can't go and face their real customer and see what their all about.


Generating Internal vs. commercial value

Alistair writes about something which I've only thought about in small glimpses, moving on to my daily business: 

One of the basic ideas behind lean development is that you narrow the amount of process that is done at the company to only those things that add value. Continually trying to remove "waste" from your process is a key learning.

The big question is "What is value".

If your manager is big into "lean" they can say

"Don't work on refactoring - it doesn't add any value to the customer"

"Don't work on making the build faster - there is no customer value in that"

but we all know there certainly is.

It's internal value - that makes sure things are kept at the highest quality.

In "Lean Software Development" the toyota way is introduced. What I've gleaned from it, among other things, is that you "remove waste - but keep the things you cannot do without"

It is those things that make "internal value":


  • a constantly trimmed and refactored build process
  • constant refactoring of code base
  • code churning for readability
  • teaching people
  • coaching about problems
  • having fun at work


There is indeed internal value in these things, but as alistair says = there is the danger of saying that anything brings internal value. 

For an agile team - it is those things "you can't do without" that you take from more specific techniques like TDD, XP, Continues automation etc...


Spend at least 50% of your time with your team

To be an effective team lead, you need to actually spend time with your team. Otherwise, you won't be able to do daily stand-ups, do code reviews, or sit down and pair with a team member every once in a while.

And no, "I have too many meetings" is not a good excuse.

"But I do have too many meetings to attend each day!"

Then it's time to stand up for your team's rights  - their basic right is to have a team lead present to help solve problems and bottlenecks that the team can't figure out alone, and to have a lead that helps them learn how to overcome problems.

  • Go to your outlook schedule and book 50 % of each work day during the week under "team time". Make this a recurring meeting that no one can override.
  • Look at the list of current meetings you attend and start trimming them down to meetings you really do need to attend, and ones where the team or you are not getting any value out of. It's sometimes valuable to start asking the Five Whys for each meeting, and see whether you can find a way to solve the problem that the meeting is trying to solve. For example:
    • Meeting: "Daily meeting of department heads"
    • Length: 1-2 hours
    • Time I actively participate in the meeting: 5-10 minutes
    • Time I actively listen in the meeting: 30-40 minutes
    • Why do I have to be in this meeting? I'm not sure
    • What do people usually ask me in this meeting? general questions about my projects progress.
    • Why? Because they don't have any other way to know
    • Why? because there is no clear and visible progress on my projects
    • Why? Because I haven't made this a reality yet


Do you know what you should do now to avoid this meeting?

Be assertive

at the very least you could take these actions about various meetings where you only need part of the time to be inside or none at all:


  • Tell (don't ask!) who ever is running the meeting that you will no longer be available to be in it


If they ask "But then how will I..." then you know what it is you need to deliver in terms of knowledge so as to make the meeting unneeded.

If they ask "But then how will YOU..." then you will realize that you may not need that information, or are getting it in a different way, or that you may indeed need to be in this meeting, but for a shorter  period of time.


  • Tell (don't ask!) who ever is running the meeting that you will only be available for 30 minutes during the meeting (otherwise development will suffer).


After 30 minutes - leave the meeting. Stand up for your decisions. See what happens.



Is face to face pairing better?

Two people working on the same machine at the same time? crazy! only, not really. But i'll touch on why pair programming works so great in a different post.

This post is about showing a wholly different style of pairing with someone than I'm used to:

Face to face to pairing (they call it screen pairing)

In the post, Brian gives several reasons why he likes this sort of pairing to "traditional" pairing:

The work is more free-flowing and conversational. It’s easier to note the other person’s body language. It’s easier to stop coding, look up, and talk to each other. I found the switching between people more fluid, with fewer episodes where we were both going for the cursor at the same time.



Working on windows, what sort of software would you need to make this kind of pairing work, though?

Is it better than "normal" pairing? I can't say until I've tried, but I can see the upsides, indeed.

One downside could be that you could easily not pay attention to the other person. I also like to point to pieces of code using my finger rather than the mouse - it feels more natural and phisycal. So I'm not sure yet.

How do you pair today? have you tried this?