One question to find out if your stand-up meeting is useful


The original objective of the scrum stand-up meeting is to assure that all team members make a commitment towards their peers. That means is that you will do as you say.

The idea that by saying what you will do in front of your peers is that you will feel more social pressure to actually do it.

The idea of standing up is that the meeting stays within 15 minutes. The assumption is that we don’t like to stand for much longer.

The scrum stand-up meeting is not a status update meeting.

There are three questions everyone is supposed to answer:

  1. What did I accomplish yesterday?
  2. What will I do today?
  3. What obstacles are impeding my progress?

This will create more transparency with what’s happening in the team, right? This is not necessarily true.

Add the following question after everyone has had their turn and find out if your stand-up meeting was a waste of time. Aks several team members.

What were the answers of team member X or Y to the three questions?

When several people can’t answer this question your stand-up meeting was a waste of time.

What can you do about this? Here are some suggestions to make it more effective:

  1. Focus on collaboration.
    1. Who needs to work or talk to who? Make sure they both agree to do so.
    2. When using a scrum or kanban board make sure that team members actually discuss stuff that is on the board. Stay sharp that people don’t wonder off doing other stuff. Is your board representing current reality? If not, inspect and adapt.
  2. Adapt the meeting structure (and length) to support what the team needs.
    1. Allow asking different questions or having some discussion.
    2. Allow for a different timing when needed to support alignment, collaboration and information sharing.
  3. Focus on agreements and decisions.
    1. Make sure the team aligns on goals and priorities and make agreements.
    2. Make sure the team calls on missed agreements.
    3. Make sure existing agreements can be re-negotiated.
  4. When a team is strong on collaboration, you may even make this meeting optional.
    1. Facilitate the meeting every day anyway.
    2. Make it everyone’s personal responsibility to decide to join or skip.
    3. All decisions made during the meeting are binding unless re-negotiated and agreed upon with those present.
  5. If you want to stick to the original scrum questions find out why people can’t answer the suggested additional question. You may have a team culture issue here.
    1. Did they not pay attention (this time)?
    2. Is the information provided to them not interesting enough? If so, why?
    3. Is there too much or too little information to make it useful?

Happy stand-up next meeting!

The social aspects of Pair Programming


Pair Programming Illuminated describes a number of social aspects that can influence pair programming. I have been pair programming for more than a decade now and have experienced its pros and cons.

Pair programming is often sold as a way to improve code quality. I can assure you this is not always true. Lauri Williams and Robert Kessler have written a book that is one in its kind. They explain how differences in skills of programmers can influence the working atmosphere.

I have experience that not only the working atmosphere is influenced by the differences in skills, but also the code quality and that this can lead to low quality code even when very experienced and skills programmers are pairing up.

I have noticed that pair programming is not for every programmer. I have been studying social psychology for several years now and I believe I have found a confirmation of this thought.

Concepts from social psychology

There are two social psychology jargon concepts I want to introduce here: social facilitation and social loafing.

Social facilitation refers to tendency of an individual to show better performance when in close proximity of other people. The individual will more likely be stimulated to perform a task then when working alone. Even passive presence of other people can be enough to get into action. The task will also be executed with better performance. The opposite effect can also occur when then task is perceived as too difficult. In this case the task is likely to be executed less well than in the individual case.

Social loafing refers to the tendency of an individual to perform less well when he/she is part of a group compared to when working alone. This particularly happens when it is less clear what the individual contribution to the task is for that individual. This can be eliminated by adding elements that clearly identify the individual contribution.

There are two known effects of this: the free-rider-effect and the sucker-effect. The free-rider-effect occurs when an individual will put in less effort, because he believes someone else will probably put in more effort. The sucker-effect goes even one step further and occurs when an individual has the feeling that others in the group are behaving like free-riders. Why on earth would I put in more effort when others don’t?

What does this have to do with pair programming?

My personal perception is that it is better to perform simple programming tasks on your own. Individual team members will be more motivated and are more likely to do a good job when simple programming work is split and divided over the team. I have noticed that the lead time is usually higher when an easy programming job is done by a pair. In such a case pair programming is too expensive. The same job may easily cost twice as much than when performed by an individual.

Complex programming tasks on the other hand can better be performed by a pair. In this case the individual performance is of less importance and the combined performance will be better. The cost for performing a complex task will be lower compared to individual cost. When a complex task is performed by an individual he may experience pressure from the group and this can negatively influence the end result.

From this I conclude that pair programming for easy programming jobs can be better performed by an individual and that complex programming tasks (that may involve design and architecture work) can better be performed by a pair.