Effective Meetings

,

Too Many Meetings: Recognize the Signs

We have received a lot of feedback on our post: Scrum Events – The too many meetings problem. Many people are reaching out to us and provided feedback on the frustration stemming from meetings.  

Meetings in the United States are a big problem.  Nearly 37 billion dollars is wasted annually on unnecessary meetings, and in the Agile community, Scrum meetings are getting the blame.  Our stance is that Scrum is not the issue but rather how companies are their conducting meetings.

Below is a list of the 9 top meeting “smells” to recognize and avoid in meetings:

  • Lack of clearly documented Agenda.
    • If a meeting invite doesn’t have an Agenda, I automatically question the importance of the meeting.  Why should I attend a meeting that the organizer doesn’t think is important enough to generate a clearly defined purpose?

My rule: No Agenda NO Meeting.

  • Lack of definition or goal.  What type of meeting will this be?
    • Status:  Share Information, Provide Status, Give Update.  Participants generally will restrict their participation to questions or clarification about the subject at hand.
    • Advance Thinking: Define and\or analyze a problem, planning session, evaluate options.  Participants are asked to advance the knowledge on a meeting topic.  Decision is not necessarily required.
    • Make Decisions:  Address issues, determine solutions, and bring to closure.  Decision required
    • Obtain Input:  Sponsor is looking for group input.  Decision is not required
    • Retrospective: Strengthen Relationships, Improve Process. Determine what is working? What is not working? What improvements can be implemented?
    • Team Building: Strengthen Relationships, build Mutual Understanding, build community.
    • Skill Development: Training, Increase subject matter knowledge.
  • Lack of defined roles.
    • How do you expect meeting attendees to participate in a meeting?  Are they a subject matter expert (SME), note taker, active participant, observer, or other?  Give those who will be attending the meeting an opportunity to prepare for the meeting based on the Agenda and the Role that they are expected to perform.
  • Scheduling too much time.
    • When a 30 minute conversation blocks off an hour of your day. Did the participants get off topic? Was proper preparation completed in advance before the meeting was scheduled?
  • Meetings that continually go over their time limit.
    • Did you invite the right people? Was proper preparation done? Does the meeting organizer have the necessary facilitation skills?
  • Scheduling meeting to ‘discuss’ when a quick conversation is enough.
    • “Discuss” is never a valid meeting topic.  If you just want to discuss something how about we go to coffee or sit in the break room and have quick chat.
  • Meetings with more than 8 people.
    • Meetings with too many participants can be difficult to manage.  If you are scheduling a meeting with more than 8 people check to make sure the right 8 people are invited.  Ask yourself if the proper pre-meeting preparation has been completed to make the meeting valuable for everyone.
  • Meetings that could be covered in an email or quick conversation.
    • Why waste time with a meeting that could be simply done in an email? If you are not sure, start with an email. Better yet, a quick face to face conversation.
  • Meetings to review previous meeting (rehash)
    • We have all been to meetings that rehash a previous meeting.  Why? Was the first meeting not enough? Did we not send out notes for the meeting? Did new information develop?

Always ask why

Every company has issues with too many meetings.  If you would like to develop skills to help your staff have more productive meetings, check out our Facilitation course.

,

Shake Up Your Daily Standup

The Scrum Guide says the following about the Daily Standup:

The Daily Standup or Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. The Daily Scrum is held at the same time and place each day to reduce complexity.

During the meeting, the Development Team members explain:

  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the Development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal.

Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team’s level of knowledge. This is a key inspect and adapt meeting.

Agile Daily Standup-breaking out of the mold

We all the know the importance of the Daily Standup, but how many teams are actually gaining real benefits from the Daily Scrum or Daily Standup?  This ceremony is not meant to be a ‘Status Report’, but in reality that is exactly what this meeting has become.  If you have fallen into the ‘Status Reporting’ trap, then you may want to consider cancelling your Daily Standup all together or making some simple changes to shake it up!

5 suggestions to shake up your Daily Standup:

1. Extend the length of your daily scrum

Yes, you read that correctly.  If a team of 8 people all have to give an update at a 15 minute Standup, that is less than 2 minutes per participant to provide valuable information.  If someone has a question, then forget about finishing in 15 minutes.  Given the time crunch, team members will hesitate to provide all the information needed in order to allow the team to gain the full benefit from the meeting in favor of meeting the 15 minute deadline.  Stretch a little; give the team some extra time to collaborate – isn’t that what it’s all about?

2. Stop answering the three questions

We all know that a team should be limiting the Work in Progress (WIP).  Let’s say your team should be working on only three stories at a time: review each WIP story in-depth.  Allow each person who is contributing to that story to provide their insights.  Address all issues or questions, or put them in the parking lot for ‘Post Standup’.  (See number 3, below.)  Once you have completely discussed the WIP stories, ask if people are working or need to work on other stories.  This should avoid the schizophrenia that occurs with the round robin approach.

3. Create a post standup meeting

As the team is reviewing each story they will have in-depth questions, concerns, and ideas.  Use the time right after the Daily Standup to pair program or swarm around items from the Standup.  I like to keep a white board at hand and I write down  ‘Post-Standup’ items as they come up.  This gives everyone an opportunity to participate, including Developers, Product Owners and Scrum Master. There is no set time-box for Post-Standup-it is all about collaborating and getting stories to completion.

4. Allow the product owner to participate

If the Product Owner (PO) has questions about the story or wants to provide insight – let them.  Why Not? This is the time when the team is trying to make sure they are meeting the objectives of the Product Owner.  If the PO asked a detailed question that will take more that a few minutes, move it to Post-Standup.

5. Have fun

Banter a little! Life is too short to just jump into the heavy details of the Daily Standup or Daily Scrum.  Take a few extra minutes (see #1) to strike up conversations with your teammates.  Use it as an opportunity to do a little team building and get to know each other. Come prepared with an interesting topic and throw it out to the group such as “Name three things that you think will be obsolete in 10 years”. You will be surprised how far a little fun will go!

Talk to Us Today

Scrum Events – The too many meetings problem

Nearly every team that I have introduced Scrum into a new company someone has complained at some point about the duration of meetings in Scrum. I get comments like:

“Scrum has far too many meetings”
“What? A four hour planning meeting for a two week sprint!”
“We have so many meetings here, and now you are killing us with more meetings”
“I cannot have my team in spending so many hours in meetings”
“I am too busy”
“&(#* off, this is &$%# @

Here are the events in Scrum and the hours for each event:

Time-Spent-on-Events-Graph1

A novice team may see these numbers as big and a lot of time put into each event, however if you follow the principle of inspection and actually take a deeper look into the timing; you may be a little surprised with some of the numbers.

For math purposes, I will be assuming an average 9AM to 5PM job with an 8 hour workday. I will also assume a Monday to Friday job as this is common in just about all the teams I work with.

Here is the breakdown of time spent on each event in a Sprint:

Scrum-Events1

2% Retrospection

Teams should spend time inspecting their processes and practices and seek opportunity to do things better and faster. Without this inspection and spirit to adaptation is completely lost and the essence of agility non-existent.

2.5% Review and Feedback

At the end of the sprint it is important for the team to speak to stakeholders and seek their feedback on the work they have just completed. This risk management strategy helps correct misaligned objectives early by allowing the team show what they have built and the stakeholders to agree or to correct it. Not spending time doing this feedback will simply result in the wrong product been delivered to stakeholders and not to their expectations. This supports the entire belief in incremental and iterative development with regular feedback.

Next is reviewing upcoming work and allowing the Product Owner to demonstrate the health of the pipeline of work to both the team and the stakeholders. It is facilitates transparent communication to the health of the product, project and upcoming work.

2.5% Co-ordinating daily effort

Each day the team simply have a 15 minute event to plan who is doing what for the next 24 hours until the next Daily Scrum.

5% Planning and Design

The largest Scrum event is to Plan the next sprint and to do high level designs on how the work will be approached. Traditional development teams spent way more effort on planning and design and Scrum team have totally reduced this. Yet this event is the most controversial event where teams feel it is still to long.

One must agree with Winston Churchill “Failing to plan is simply planning to fail”. I personally do not think ask any team for 5% of their time to plan and design upcoming work is a big ask. Surely a professional should be able to recognize the importance to plan.

88% Available to do work

That’s a lot of time to get stuff done. I do consider refining as work.

Here are some more facts

1 hour per day (average) in meetings

If you look at it as only having a single one hour meeting per day on average, this is actually not much at all in the grand scheme of things.

It’s a time-box

A time-box is the Maximum time for an event, this means that if you can do it quicker whilst delivering the same quality; then please do it quicker.

If you are doing more meetings than the ones in Scrum, then you are doing it wrong and the organization has dysfunction that needs to be addressed.

Here is the math for the skeptics:

Event-Times-for-Sprint1

Author Brett Maytom is a Professional Scrum Trainer.

where is your time going

 

A Plan to Discuss is Not a Plan

Many companies have been trying to reduce the overhead of meetings, to no avail. Here is one idea that may help. Never set up or attend a meeting where the subject line reads:

“Discuss [topic]”

…with no agenda. Here’s some examples of meeting invites I’ve had over the years:

  • Discuss technology direction
  • Discuss production outage
  • Discuss deployment plan
  • Discuss new design

Of course these meetings never have agendas. What value do these meetings provide? None! A friend of mine compared these kinds of meetings to bar conversations. You know those; lots of fun dreaming about “what ifs” and coming up with a plan on how to “make it big”. And what happens after those conversations? Nothing. It’s as if they never happened.

Let’s rewrite those meeting invites to be a bit more productive (don’t forget to include an agenda!)

  • Decide whether to build the application using .NET or Java
  • Create an action plan that minimizes production outages
  • Decide whether to use Ruby on Rails or CakePHP
  • Define the test cases for User Story XYZ

Notice that the verbs imply finality, while “discuss” does not. To “Decide”, “create”, or “define” means that you will leave the meeting with something finalized. You now have a definition of “Done” for the meeting.

You will never know when you are “Done” if the goal is to discuss.

Talk to Us Today