May 14, 2021


News for Agilists

How Long is a Developer Day?. The impact of meetings on agile… | by Seamus Connolly | Serious Scrum | Oct, 2020

The impact of meetings on agile development teams

Photo by Shamim Nakhaei on Unsplash

There are only so many hours in a day. The same holds true for the developer day, especially as we embrace the concept of sustainable pace. For guys working a typical forty hour week, we can then divide that into eight hour days for a five day working week. This is a common assumption but does it really hold true?

In an ideal world, they would be the only meetings arranged during the sprint however reality does not always with the ideal. Accepting that meetings will take place, additional to the scrum events, we should have an approach to maximise the benefit of participating in those meetings. Key to that is identifying objectives.

Eisenhower Principle

  • Important activities have an outcome that leads to us achieving our goals, whether these are professional or personal.
  • Urgent activities demand immediate attention, and are usually associated with achieving someone else’s goals.

You can read more about the Eisenhower Principle here.

In making the decision on whether or not to attend a meeting, we should evaluate the objective(s) of the meeting and also seek to assess the importance to the individual or team with regard to achieving the goal(s) of the sprint. If you decide that attendance is not important for you or the team, could the meeting be recorded? Alternatively, perhaps meeting notes could be provided after the meeting.

Meeting Duration

Parkinson’s law states that “work expands so as to fill the time available for its completion”

Parkinson’s law can also be witnessed in meetings where tangential discussions can take place that fill the allotted meeting time. This is where focus can help. Identify the objectives for the meeting and stay focused on meeting them. Once achieved, end the meeting and give any remaining time back to the attendees. We can go on to see the reasoning for this.

Scrum Events

The time-boxes for the scrum events are as follows:

  • Sprint planning: 8 hours for a one month sprint, so 4 hours in our example.
  • Daily scrum: 15 minutes each day.
  • Sprint review: 4 hours for a one month sprint, 2 hours for our example.
  • Sprint retrospective: 3 hours for a one month sprint, 1.5 hours here.
  • Product backlog refinement: Should not take up more than 10% of the developer capacity for the sprint.

“Don’t throw the baby out with the bathwater

derived from the German proverb, “das Kind mit dem Bade ausschütten”

I have seen many teams artificially shorten scrum events due to a lack of appreciation for what they should be trying to achieve in those events. Observing the caution in Parkinson’s law, we should not use the full time-boxes for the sake of it. We should clearly identify our objectives in each of those events and then end the meetings once we have achieved them. The entire scrum team should be clear on the benefits to the team of the scrum events. The actual time required will depend upon the experience of the scrum team members. The Scrum Guides give a full explanation of each of the events.

Let’s take a look at what all of this means in numbers. Based on the two week sprint, eight hour day. Using only the formal Scrum events full time-boxes we have a remaining, average daily, available production time of seven hours.

Not too bad so far. Let’s add the 10% maximum for the refinement sessions; 10% of the remaining time that is, so approximately seven hours. In this example, that is split in to two sessions of 3.5 hours. I know! You may not need all of this time; bear with me.

So, what we have now — for an eight hour day — is almost a 25% reduction of the available production time each day on average. Something that compounds this impact is that almost invariably there are various other meetings that invite developer participation. We can add a few, just for illustration to help make the point of this article.

This is not intended to be an exhaustive list but hopefully serves to illustrate the potential impact of meeting frequency and duration on average available production time. In this illustration we are now below 75% of the average day available for production.

The Scrum Master can certainly coach the team and organisation on this theme but understanding the issue can help people to be more receptive to the point being raised.

“When the student is ready the teacher will appear. When the student is truly ready… The teacher will disappear.”

Tao Te Ching

This is one piece of the production time puzzle. What the developers do with that available time is another coaching point. A lean agile approach in reducing the impact of the seven wastes of software development will take us further in efficiency. The timing of meetings can exacerbate what we have already discussed even further. There is an inevitable wind-down before meetings and an adjustment of focus on returning after the meeting. A full explanation of the seven wastes is beyond the scope of this article, however I hope I have managed to give a picture of the context within which they reside.

Do you want to write for Serious Scrum or seriously discuss Scrum?

Source link