Monday, October 9, 2017

Are There Too Many Meetings in Agile Software Development?

I happened across an article that was suggested to me by Google written by someone in the software industry complaining that there were too many meetings in Agile software development, particularly in Scrum.

In searching for the article so I could post the link here (with no luck), I found there's no shortages of articles containing people complaining about the amount of meetings as well as from those Agilists in defense of their framework.

In thinking about this problem, I boiled it down to three questions:
  1. Who are the people complaining about the amount of meetings?
  2. What is the core problem when people discuss meetings like this?
  3. What can be done within the Agile framework?

Who are the people complaining about the amount of meetings in agile software development?

Traditionally, when a company or team announces a desire to move to Agile software development, the framework of Scrum initially is on everyone's radar.  When you attend ScrumMaster Certification training, the basic list of meetings is this:
  • Daily stand-up
  • Sprint planning
  • Backlog grooming
  • Demo
  • Retrospective
Depending on your deployment process, you may have a release warroom-type meeting where the entire team is holed-up until code is released, tests pass, and all systems are green. (These "meetings" often suck)

When looking at the prospect of all those meetings that the team will have to embrace it's the engineers who generally start complaining to themselves about spending half of their week in meetings. 

Being a ScrumMaster, I can't blame the team for this. As I've written before, I too hate meetings. Usually they are poorly organized, little to no preparation had done by facilitators beforehand, unnecessary participants are invited and not allowed to leave, and they drag on forever! Engineers are paid well because they are good at what they do.... building things. They want to be at their desks building things, and they should be!

When teams start openly deriding meetings, ScrumMasters can often receive that feedback as personal criticism, since it's sadly one of our tasks to round people up for meetings (maybe it shouldn't be, in a perfect world). Perhaps this is why ScrumMasters call meetings 'ceremonies'. We're not fooling anyone though; these are meetings. If not handled correctly, indeed the team will blame you for the meetings being so awful, so pay attention!

This is why good ScrumMasters are adept at identifying the core issue, which really aren't the number of meetings themselves.

What is the core problem when engineers are complaining about too many meetings?

Yes, engineers need to be engineering but the plain fact of the matter is that meetings need to occur in order for the team to best know what they are trying to accomplish. You just can't get around that. There simply has to be planning; no one will be able to deny that.

The real problem behind the meeting complaint is not the number of meetings, but that too much time is taken up with poorly prepared meetings.

In my career, I've seen it all with regards to meetings. I've made all of the bad mistakes that are still sadly so prominent in software teams throughout the world. I've seen the "let's set apart mornings for meetings so we can work in the afternoon." I've been a part of the dreadful 6-hour sprint planning meetings that lead to so much soul-crushing.

These are dead giveaways that your software developers probably are frustrated at their companies.

This is one very important problem the ScrumMaster needs to be actively solving or risk losing the trust of their team.

What can be done about awful meetings within the Agile framework?

Keep. Meetings. Short. Live by this motto; embrace this motto; weave it into the culture of your team. When I work with new teams, one way I get engineers excited about my being there is the promise that "I am going to ensure our meetings are no longer than 50 minutes." After about 50 minutes, people start to fade and the meeting loses its effectiveness exponentially.

Many people (mostly team members) will be excited at your seemingly bold claim. Some (mostly managers) will be skeptical. (After all, it's not uncommon for certain professionals to validate their usefulness by the number and length of meetings they facilitate.)

How can this be done?

Well, you don't start immediately, especially if long meetings are ensconced in the culture. You declare to the team that this is the goal we will be working towards and hopefully within the quarter, all meetings will indeed be down to 50 minutes or less.

One of the key ways this will be accomplished is through the unsung hero of agile meetings: backlog grooming. If you have painfully long sprint planning meetings, it's probably because the team doesn't groom well or at all.

If the team is grooming in multiple short-bursts in the run-up to the sprint, your planning meetings should be really short. The team should already be familiar with the stories at the top of the backlog. They should have already thought through key areas in how they will approach their solution. User Acceptance Criteria will have already been defined and thus QA will have been planning their tests in advance. Estimates are already made and agreed upon so we don't sit there and haggle for 15 minutes on each story.

How often you need to be grooming is up to the team, but the goal is to get the things at the top of the backlog refined in such detail that at the start of a sprint the team can immediately begin working. I wouldn't worry too much about grooming stories that may come into view more than a sprint or two down the line. It's just not worth it at this stage because things are so fluid in software development.

While engineers may initially balk at the thought of having yet even more grooming meetings, you will convert them into believers when you are in and out of a planning meeting in 15 minutes.

Tip: in order to not disrupt the artistic focus of the development team, try scheduling grooming meetings right after lunch or at the end of the day. 

If you're grooming well and following a more 'kanban-style' approach, you may simply remove the sprint planning meeting altogether. Victory! (Just don't leave out the retrospective)

While all of this concern about meetings may seem trivial, it's really strikes at the heart of Agile software development which values the minimal amount of overhead in order to produce something of quality. Finding that balance is unique to every team, but rest assured if your team is spending over 25% of their time in meetings, not only are you not maximizing their value, but they're also likely unhappy with their jobs.

Ignore meeting optimization at your own peril.

1 comment:

  1. Hi there! I'm sorry for a perhaps dumb question, but could you please explain briefly what agile is really all about? I heard about it multiple times, but I still don't seem to understand it well. I'm about to get dynamics ax implemented soon, so I need to know that :)

    ReplyDelete