Meetings in a Hurry Are Not Effective Ones

Table of Contents

The Importance of Timeboxing in Scrum

The timeboxing is a fundamental technique for many Scrum activities. There is often a misunderstanding that meetings should be fast, leading facilitators to rush participants to finish within the timebox. This haste results in poorly discussed problems and many uninformed decisions.

Time boxing, in this context, serves a different purpose. It is for making conscious decisions on choosing what and what not to talk about during the conversation. It is more for eliminating than for being in a rush.

Strategies for Effective Timeboxed Meetings

As a facilitator aiming for effective timeboxed meetings:

  1. Ensure everybody agrees on the goal of the meeting, the expected outcome, and the decisions that need to be made (e.g., planning meeting - discussing items with defined acceptance criteria, estimated, and having a rough design).

  2. Ensure that an agenda (structured) is agreed upon.

  3. Keep an eye on the time.

  4. If time is running short, say it aloud and remind everyone of the goal, expected outcome, and necessary decisions.

  5. Ask participants what they think they should focus on or eliminate to achieve the results within the timebox.

  6. If time is about to exceed the timebox, make an agreement for another timebox (e.g., extend the meeting for 30 minutes).

  7. Summarize the results.

  8. Consider conducting a short retrospective afterward to find ways to improve the meeting.

By following these guidelines, facilitators can help ensure that timeboxed meetings are productive and decisions are well-informed, without the stress of rushing through discussions.

(Text translated and moved from original old blog automatically by AI. May contain inaccuracies.)

Tags

Related Posts

The Natural Order of Refactoring Under the Microscope Part 3: Extract Method

Analyzing Class and Method Responsibilities

In the next step, we examine the responsibilities of individual classes and methods, checking if they align with the intended responsibility of the class. It is best to analyze all methods and group them based on performing similar operations. We look for a place for these in other classes or a new class. Remember: if there is a significant private method in a class (longer than 3-4 lines), it should be moved to another class.

Read More

Simple, Complicated, Complex, and Chaotic Systems: The Cynefin Framework

Perhaps you’ve previously encountered concepts such as complex systems, complicated systems, or complex adaptive systems, for instance when reading Jurgen Appelo’s Management 3.0, or when considering Ken Schwaber’s thoughts on the applicability of Scrum. This might sound intriguing, but it can be difficult to find logical sense in it if one lacks a certain theoretical foundation. This is where it’s worthwhile to examine Dave Snowden’s concept called Cynefin, which is based on complex systems theory, anthropology, evolutionary psychology, and cognitive psychology.

Read More

The Natural Order of Refactoring Under the Microscope Part 1

Refactoring is an age-old problem—perhaps not the best word given the relatively short existence of software engineering as a discipline. Everyone knows refactoring should be done, but nobody seems to have the time for it.

Read More