Play Now!
Subscribe: Apple Podcast
Check out the podcast on Google Play Music
Listen on Spotify!

SPaMCAST 569 features our essay on the five types of meetings.  Meetings are the most important event in any organization — well that is what it seems like.  It can also be said that meetings are the bane of every human that isn’t buying or selling something (and that caveat might be an overstatement). Let’s put a name on the five most common types in software-centric organizations.

We will also have a visit from Jeremy Berriault.  In the QA Corner this month, Jeremy provides observations about the inclusion (and sometimes the lack of inclusion) of QAs in ceremonies such as the Daily Scrum.  Jeremy can be reached at Berriault and Associates Consulting Group or by email at Jeremy.Berriault@Berriaultandassociates.com.  (more…)

A mad house or a meeting?

Depending on whom you ask and/or when you ask, meetings are a bane or boon.  Scrum practitioners often call the standard meetings ‘ceremonies’. The term confers a huge amount of gravitas to events that are just meetings.  What sets them aside from many run-of-the-mill conference calls is their explicit purpose.   (more…)

Meetings are more than just a gathering of people.

Meetings are the most important event in any organization — well that is what it seems like.  It can also be said that meetings are the bane of every human that isn’t buying or selling something (and that caveat might be an overstatement). There is an enormous amount of literature purporting to deliver effective meetings.  If we use the simple Daily Scrum as an example even what should be straightforward wander off course if participants use the meeting for more than it was intended. A quick query of internet sources suggests that there are anywhere from 6 to 16 types of meetings. The most common meeting types in software-centric organizations are: (more…)

Ruins of Willkarakay

Telling stories is a natural human activity from time immemorial.  Creating a succinct and informative story to describe a business need or the future of an organization is challenging.  Stories are not bulleted presentation slides, although those tools can be used.  Rather stories at this level are longer narratives, or at the very least they are like the paintings in Lascaux Caves which evoke a longer narrative. Narrative storytelling is not a tool typically found or appreciated in status meetings, the process of building a narrative that describes a business need or the journey an organization must take to achieve a goal often needs facilitation.  Three facilitation tools are commonly used to help a team or an individual to build a story in a business environment. They are: (more…)

Their are meetings of all types!

Their are meetings of all types!

The Scaled Agile Framework Enterprise (SAFe) organizes work using a hierarchy of value stream, agile release train, program increment, sprint and teams. In order to make the structure work, SAFe adds a few events to the standard set of team-level Scrum meetings (sprint planning, daily stand up/Scrum meeting, demonstrations and retrospectives.  The additions include:

  1. Release Planning Meeting. The release planning meeting is used to plan and kick-off a program increment. The meeting is typically held over the course of two days and involves everyone involved with the program increment. The release planning meeting is one of the keystones of the SAFe framework.
  2. Scrum of Scrums: The Scrum of Scrums (SoS) is a meeting of the Scrum Masters using a format that is very similar to the daily stand-up meeting. The SoS is a common tool for scaling Agile and has is part of the Scrum cannon. This meeting is generally facilitated by the release train engineer.
  3. Scrum of Product Owners (optional): In a similar vein as SoS, a Scrum of product owners. The same general format of the classic three questions can be applied from a product owner perspective. The goal of the meeting is generally to keep the product owners informed and involved.
  4. Release Management Meeting: The release management meeting reviews progress toward a developing releasable product. Attributes that are reviewed include scope, quality, and progress toward the release roadmap, quality and potentially other factors.
  5. System Demo: The system demo provides a demonstration of the integrated software. This is typically a demonstration to the business and other key stakeholders. The system demo occurs at the end of each sprint generally after the sprint demo.
  6. Program Increment Solution Demo (Part of the activity SAFe calls Inspect and Adapt): The PI demo reflects everything that was developed (and is done) during the program increment. All release planning participants are part of this demo. The PI solution demo connects the loop with everyone that was involved in planning and also provides a starting point for everyone involved in the next planning event.
  7. Problem Solving Workshop (Part of the activity SAFe calls Inspect and Adapt): The problem solving workshop is a macro version of a retrospective. The workshop generates an improvement backlog that is an input into the next release planning cycle. The problem solving workshop provides all of the teams with time to identify and prioritize problems that may affect the entire Agile release train.

All of these events bear further exploration, however it is important to note that when scaling Agile so that important  large business needs are tackled in a timely fashion, scale comes with a cost. The cost is the need for control structures. Agile has many attributes that contribute to discipline and control such as short feedback loops, iterative planning, demonstration and more, but as the number of teams working toward a common goal gets larger additional mechanisms are generally needed when cadence and synchronization are not sufficient.

Hydrogen is elementary!

Hydrogen is elementary!

Hand drawn chart Saturday.

In Scrum there are four-ish basic meetings. They are sprint planning, daily stand-up, demonstrations, retrospectives and backlog grooming (the “ish” part). Whether distributed or co-located, these meetings are critical to planning, communication and controlling how Agile is typically practiced. Getting them right is not optional, especially when the Agile team is distributed. While there specific techniques for each type of meeting (some people call them rituals) there a few basics that can be used as a checklist. They are:

  • Schedule and invite participants. Team members are easy! Schedule all standard meetings for team members upfront for as many sprints as you are panning to have. As a team, decide on who will participate in the demo and make sure they are invited as early as possible.
  • Review the goals and rules of the meeting upfront. Don’t assume that everyone knows the goal of the meeting and the ground rules for their participation.
  • Publish an agenda. Agendas provide focus for any meeting. While an agenda for a daily stand-up might sound like overkill (and for long-term, stable teams it probably is), I either review the outline of the meeting or send the outline to all participants before the meeting starts.
  • Check the tools and connections. Distributed teams will require tools and software packages; including audio conferencing, video conferencing, screen sharing and chat software. Ensure they are on, connected and that everyone has access BEFORE the meeting starts.
  • Ensure active facilitation is available. All meetings are facilitated. Actively facilitated meetings are typically more focused, while un-facilitated meetings tend to be less focused and more ad-hoc. Active or passive facilitation is your choice. Distributed teams should almost choose facilitation. If using Scrum, part of role of the Scrum master is to act as a facilitator. The Scrum master guides the team and participants to ensure all of the meetings are effective and meet their goals.
  • Hold a meeting retrospective. Spend a few moments after each meeting to validate the goals were met and what could be done better in the future.

Agile is not magic. All Agile teams use techniques that assume the team has a common goal to guide them and then use feedback generated through communication to stay on track. Distributed Agile teams need to pay more careful attention to the basics. The Scrum master should strive to make the tools and process needed for all of the meetings fade into the background; for the majority of the team the end must be more important than the process.

Break the rules at your own peril.

Break the rules at your own peril.

I am not really a big rule guy, I would rather think of most structures as a guideline. However, sometimes there are some lines that shouldn’t be crossed.  There are three rules that everyone involved in backlog refinement must remember.  These rules are broken at your peril!

  1. Rule One (originally described in Splitting User Stories: Patterns): Each story must deliver functionality that is potentially implementable. If a story needs to be split or refined, think slice rather than phase or layer. Each story should represent a thin slice of on an onion starting at the outer layer cutting to the core rather than an individual layer.
  2. Rule Two: All formal refinement sessions need to have a clear measurable goal. A goal provides focus for the refinement exercise and provides bounds in much the same manner as an agenda does in a standard meeting. Participants should know the goal for the session (e.g. today we focus on stories supporting the theme for the next sprint) when the session is scheduled so that they can prepare. For example, when I participate in refinement sessions, I try to review the stories that will be discussed so I am not participating to generate questions, but rather participating to generate understanding.
  3. Rule Three: While most Agile exercises include the whole team, participation in a refinement session should be limited. I use the Three Amigos technique to ensure a crosssection that includes a tester, product owner or business analyst and developer. refinement sessions are working sessions focused on making sure stories are understood, properly formed and have initial acceptance criteria. The larger the number of people involved in a meeting, the larger the amount of time that will be spent developing a consensus that will be revisited during sprint planning.

When scheduling a refinement session remember the three rules.  First and foremost, all stories need to deliver value. If a story does not deliver value, consider jettisoning the story. If you are going to schedule a session make sure you have a goal.  Just like the relationship between a meeting and an agenda (no agenda, no meeting), if you don’t have a goal for your session generate a one or reschedule the session. Finally, inviting everyone involved in the project (and a few extra subject matter experts for good measure) is a recipe for death by talking.  Constrain the session to the absolute minimum number of participants. User story refinement is important, don’t mess it up!  If you have to break the rules  . . . well just don’t.