RSS Feed

Latest Entries

First time here?


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?


Step #4 - Start doing code reviews – Seriously

As one team lead to another, as someone who has actually done this with a real team, I can tell you that this is one of the few effective techniques to maintain a high quality bar in your code base, and to keep your people learning. It is also one of the best ways to stay in touch with the codebase even though you are a team lead, and have much less time for real coding.

Whatever you do, don’t listen to others or even your own inner voice telling you that it’s a waste of time.

Code reviews are nothing short of a magical process of growing people, code quality and confidence at the same time, and it has changed the way we work at Typemock immensely.

What's a code review?

One developer looking at another developer's source code - thoroughly.

What do you look for in a code review?

  • Logical bugs
  • stupid bugs
  • Unreadable code
  • Ugly code that should be refactored

What is really the purpose of code reviews?

  • Besides catching bugs really early on, you mean?
  • Keep code at a much higher quality
  • share knowledge of new feature, requirements and code between people in the team (the reviewer learns about code they did not write)
  • Raise skill of both reviewer and review-ee ("oh I'll show you a much more elegant way than doing this ugly for-loop - see?", "That looks great - what do you call this pattern?")
  • Let the team know that you, the team lead, care - about them, about the code, about quality

Who should do the code review?

  • At first – Just you.

Everything has to start somewhere - and as a team lead, I expect you to know good code, and to recognize bad code (here's a good book about this subject or even better - a whole bunch)

  • Other team members (when you feel comfortable with it)

How and when should you do a code review?

There are two phases to this. The first one is the one where you bring the team up to par with what you consider quality code - You will be the only one doing code reviews - and no code is checked in before passing your code review. seriously. This is serious business and you should stand your ground. I cannot begin to tell you how much good this will do to the team - but you must stand your ground and give this a try.

  • Sit down with the team, or explain this at the end of the next daily standup -

From now on, every code being checked in has to pass a code review first.

That's right - every check in will be reviewed by you personally.

  • Wait for the next time someone is about to check in their code
  • Sit with the, and find the changed code. You can use the "show changes" tools from  the various source control tools (aka sourceSafe, SVN, VSTS etc.).
  • Go through each file and read the code. Do this even if the file checked in is not code – a text file, a solution file – it’s amazing how many gems you can find)

many times when reviewing you’ll find classes that are not in use anymore, or fully commented out, code that is duplicated and forgotten to be removed and many more “gems”.

  • Ask important questions about every little thing that bothers you:
    • "Why are those comments there?"
    • "Can we make this more readable?"
    • "This needs refactoring to smaller methods" and so on.
    • “How could you make this code more readable”
    • “What do you think is wrong with this piece of code"?”
    • “What would be a better name for this method?”


  • As you comment on the code have the developer put a special “REVIEW” or “REFACTOR” comment on that piece code which is easy to find later.
    • do not hesitate to say it if you feel that they are not paying attention or that they are not writing down those comments.
  • When you finish the review ask them to make any changes and show you the code again before checking it in.
  • Do a quick pass on the changes that were made (you can pass on this step after a couple of days if you feel comfortable enough)

Train the team to review its own code

I’ve said this previously, but I’ll mention this again:

Your most important role in the team is to act as a coach – to teach them to solve their own problems.

To that effect, it’s important that you not become the bottleneck for the team. The goal here is to make sure every checked in code is being reviews, without the team slowing down to wait for you every time. IN order to achieve that, have a third person sit with you and the review-ee (that’s 3 people on the same machine) and write down a list of what you are looking for in the code. That list will later be used to coach others on code reviews.

Have that third person change between reviews so everyone gets to learn.

The next step

When you’ve code code reviews for say- a week or two, it’s time to let the team start doing its own reviews. 

In the next standup meeting, declare that from now on, everyone can review each other’s code, with your supervision. From now on you will be the third person sitting behind two team members as they review each other’s code. As a team member reviews the code, sit quietly and only speak when they prepare to move on to a different file. If you have something to say, that’s when you can say it:

  • “What about naming conventions in this file? have you looked at those?”
  • “I’m still seeing something in this code that I think you missed – care to try and find it?”
  • “Why did you choose to apply this refactoring instead of X?”
  • “Why would you name it X?”

and so on.

typically, within a couple of days you should feel comfortable with them reviewing each other’s code, and free you up for other things.


What did we end up with?

When all is said and done , 2 or 3 weeks later, you should be able to say:

  • My team knows how to write better code today than they did last month
  • My team learned a new skill this month
  • My team can raise the quality but still be fully independent in doing so
  • I feel that I know exactly how out code looks
  • I know my team members better than I did last month

Those are things that you should be very proud to say. These are the hope of any team lead – that their coaching actually makes a difference.

You might still want to reviews code every now and again, and make sure the bar is still set to your standards. If it lowers again, you can repeat the exercise.

You should also have a better understanding of the strengths and weaknesses of each team member in regards to coding, sharing information, pairing and overall attention to detail. These will help you a lot when it comes time to grow people. I’ll touch on this in a future post.


How to find hidden problems in your project before it’s too late

A team lead I met a couple of years ago told me of a very effective technique he used in new projects and teams where he didn’t yet know what’s really going on, the team members, or all of the things that needed to be taken care of. He told me what happened the first time he tried it:

It was 5 months before the supposed release of the project he had just gotten into. everyone looked very busy but he didn’t really know where to start. So he gathered the team in one room, including one of the stakeholders (project lead) and the QA manager, and asked them all one simple question:

“Imagine it’s the end of the project – 5 months from now. We’re standing in this same room, and the project has totally and utterly failed.

Why did it fail?”

As he said that, people around the room started talking about various things that are currently holding the project down, risks that needed to be mitigated, and quality issues that needed to be resolved. The QA manager said he didn’t yet get anything to test, and that the way things looked he will get them waay too late, which means the release will surely be late. The developers said that they have been rewriting the software three times over so far since no one seems to really know what they want. One of the developers mentioned that they are only working on the project half time since they are also working on two other projects at the same time – so he didn’t see a way this ends well.

The team lead wrote down all those risks and after 45 minutes he had a ready made list of things that really needed taking care of.

He knew what he needed to do.

What can you learn from this?

If you are a new lead on an old project, there is no hard in trying out this technique. It is a smooth and brilliant way of getting people to think of obstacles, and fleshing out problems before they arose too late to take care of.

Gather your team, and take a couple of stakeholders with you (stakeholders are the people in your company that will suffer greatly if your team fails to deliver the project). ask them the question.

You might be surprised by what you find.


Do you have your own cool technique? Share it in the comments!