Meetings are toxic


Today’s office space is for many people not more than an interuption factory. When you ask people when they come in early or leave late, a common answer is that these early or late hours are the only hours they get some real work done.

Meetings are the word kind of all interruptions. I am also confronted with this challenge. I hate meetings. Especially the once that fall in the category of pure waste. Pure waste to me is when no customer is willing to pay for that time.

I am always looking for the goal of the meeting and what problem the meeting is supposed to solve. There can be one or more goals for a meeting, but if you need to have one it is best to stick to just a single goal to keep things simple.

Here are some problems I see with meeting:

  • They are regularly about abstract things instead of real things.
  • They typically convey a poor level of information. Either too low, too high or irrelevant.
  • They easily drift off-topic.
  • They either require too much prep-work that people don’t have time for.
  • They regularly have a too vague or no agenda at all. Nobody knows the real goal.
  • They include at least a single moron who gets too much time to waste everyone’s time.
  • The worst of all… they procreate. One meeting leads to another meeting that leads to another meeting etc.

Here are some objectives that may help you to focus and limit the time you spend in meetings.

  1. Information sharing – when the objective is to share specific information
  2. Problem solving – when the objective is to solve a specific problem
  3. Decision making – when the objective is to engage in meaningful dialogue in order to reach a decision
  4. Education – when the objective is to learn new things or acquire new skills
  5. Ideation – when the objective is to generate new ideas and develop new ways of thinking
  6. Network – when the objective is to share ideas or meet new people
  7. Produce – when the objective is to work together to develop a specific output
  8. Promote – when the objective is to introduce a new offering or promote a new message
  9. Celebrate – when the objective is to commemorate a milestone or accomplishment

Keep it short: 15 minutes or 30 minutes and no more. Any longer and you end up wasting time. Prepare to make meetings effective and efficient.

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 Three Signs of a Miserable Job


In the book “The Three Signs of a Miserable Job”  Patrick Lencioni outlines that many working people are in a miserable job. In this post I want to share the basic idea behind his book.

The cost of people not liking their job is staggering. Productivity collapses greatly when employees are unfulfilled. It does not end at work. There is also a great social cost. Even emotionally mature employees share their work misery, frustration, cynicism, weariness into the lives of others. It becomes impossible to appreciate the joy of life. The emotional and psychological damage can be profound and irreversible.

The following three factors will make any job miserable. They seem obvious and maybe even easy to resolve. However, they remain unaddressed in most organizations.

  1. Anonymity – People need to experience that they are known for their work. We need to feel understood and appreciated for our qualities by someone in an authority position. When we don’t feel heard or think we are invisible, generic or anonymous within the company we will not love our job.
  2. Irrelevance – We need to know that our work matters to someone. When we cannot make a connection between what we do and someone else’s satisfaction we simply won’t find lasting fulfillment in our job.Someone needs to appreciate it and we need to know about it.
  3. Immeasurement – It is important that we can gauge our personal progress and contribution. We cannot be fulfilled when our succes depends on the opinions or whims of another person. Our motivation heavily depends on our ability to self assess success or failure. When we perceive that we cannot control our own fate our motivation quickly deteriorates.

Patrick tells us that we will feel miserable with even one of these factors present. What I read is that we our job needs to be meaningful to us and that we need a way to know how we are doing. How about you? Are you in a miserable job? How can we take ownership of these three factors?

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.

 

Student Syndrome


The first time I heard someone mention “student syndrome” was during a training of Mike Cohn about seven or eight years ago. Student syndrome is what happens when someone estimates how long it will take to get something done, adds some slack, starts late using up the slack and then finds out that the task indeed will take longer and consequently finish the task late.  This looks somewhat like to image below.

Student Syndrome

For some reason this remains to be an attractive way of planning for many people. Recently, I heard a respected and experienced project manager, let’s call her Karin, even make a suggestion that unintentionally motivated a team member, let’s call him Mike, to show this behavior. Mike needed to finish some work and expected it to take about an hour. However, it was close to the end of the day and Mike would have a day off. This basically meant that the work would not be done before the Sprint Review meeting and a User Story remained unfinished. Of course that could not be the case if it was up to Karin. So Karin decided to address Mike and pointed out that with a bit more commitment the work should be done before the Sprint Review meeting. The suggestion was to come in a bit early after Mike’s day off and finish it just in time for the review.

I guess we can agree that this was a proper corrective action to address to Mike that he’d committed to finishing this User Story the day before. Karin addressed both commitment and accountability. What she did not anticipate however, is that she invited Mike to potentially suffer the same consequences as Student Syndrome. What if Mike had not even taken into account some slack? One small setback and the User Story would still not have been finished in time.