Home > Point2 - Process and People > Is Tardiness Contagious?

Is Tardiness Contagious?

December 11, 2009

Meetings are a regular occurrence in all office environments, and it is no different for an agile software development team. With the majority of of our teams following Scrum, the Daily Scrum, estimation, and retrospectives are just some of those many meetings. Even though my particular team has become quite efficient at running these meetings, there remains one problem that is common amongst almost all of them – people are always showing up late to them. This very problem was the focus of our last root cause analysis meeting (and yes, people showed up late to that one as well :P) as we hoped to identify reasons for meeting tardiness.


After drilling down into the problem, my team identified four categories that played a role in tardiness amongst members of our software development team.

Focus

  • Since we do 100% pair programming on our development team, a developer feels bad if they need to leave for a meeting that their pair is not in.
  • A pair is usually in some sort of flow while working on a problem and they often find it difficult to leave abruptly.

Complacency

  • It is generally okay for meetings to run long, so people start to think it is alright to show up late.
  • Meeting invitation notes (agendas, goals, etc.) are not read until a few minutes prior to the meeting start time, resulting in people being late.
  • It has just become the norm.  We have started accepting people being late as business as usual.

Scheduling

  • Coffee and bathroom detours are made on the route from desk to meeting location.
  • Meetings scheduled on the hour/half-hour are not disruptive enough to garner full attention.

Software

  • Since developers are pairing most of the time, they are rarely at their own desk to get the meeting reminders.
  • The snooze function and meeting reminders in Outlook and Entourage are not reliable.

It was no secret that this was a problem faced by all teams in our department (I can’t speak for other departments) so we came up with some action items that we could start to implement (on our particular team, at least).

  • Simply round people up prior to the meeting. This may only work if you are all located in the same area.
  • The organizer of the meeting should be the first person to show up, and welcome the attendees as they arrive. Many times people show up to a meeting room and no one is there, so they too wander off.
  • Identify the meetings for the day at the Daily Scrum.
  • Just start the meeting on time, regardless of whether everyone is there or not. People who show up mid-meeting will get the point.
  • A more extreme method which will not work all of the time is to simply cancel the meeting if everyone is not there on time.

It’s been a week since we’ve started tackling this problem and I can say that there has already been improvements made. Even though there is still a ways to go, we are confident that tardiness will soon become a thing of the past. The idea that we have become complacent to people showing up late just means that more and more people will follow this trend. If we can just turn that attitude around I think we can successfully make punctuality just as contagious as tardiness.

By Hemant J. Naidu

Advertisements
  1. Jason
    December 12, 2009 at 11:49 PM

    One common problem with scrum meetings is their time.. Team leads and project managers might like to have them at 9 or 9:30am, which often doesn’t gel very well with the high output developers on a project – granted I do work in hardware/software R&D environments where things might be a little different.

    It might be a different problem than what you are facing though, but the only way a daily scrum meeting would work in my environment would to be have it around 1 or 1:30pm as that is when some arrive, and others that start at 5 or 6am leave shortly after. But if someone is constantly delivering high output and high quality, we don’t care about the hours, or pair programming, yet we still feel we’re working in an agile manner.

  2. December 14, 2009 at 3:52 PM

    As a Team Lead, I always try and schedule meetings near the beginning or end of breaks such as:
    – first thing in the morning
    – right before lunch
    – right after lunch
    – right before the end of day

    By doing this it minimizes the interruptions for the team while they are working. Since we are always pairing, my team works the same hours (approx. 8am – 5pm) so we rarely have to worry about having an “odd man out”.

    I agree that having team members working different hours adds a completely different set of challenges.

  1. No trackbacks yet.
Comments are closed.
%d bloggers like this: