The Agile Practitioner: Striking a Balance–Meetings vs. Work

When the progenitors of agile convened, their ultimate objectives were to help teams build better software faster. The emphasis on delivering customer value in small increments, testing their efficacy, and iterating quickly held the promise of being more efficient by putting developers to work early in the development cycle.

The early returns suggested that this way of working was far superior to the old “waterfall” method of having a massive design effort followed by a massive coding effort, only after which to find out how well the team did. However, as the new normal set in, expectations rose.

At the same time, cracks started to appear in the new approach. Large complex projects often suffered from limited planning and architecture. This was not built into the agile philosophy, but it was easy to see how teams could take the “just do it and see what happens” thing a bit too far.

Fortunately, the agile approach calls for regular retrospection, so as teams discovered the error of their ways, they took steps to fix them. What emerged was a specific brand of agile practice called “scrum.” Scrum took the learnings from these early experiments and brought some structure to the process.

This structure took the form of some meetings that occur at various intervals:

  • The Stand-up – this is a brief daily meeting. It is called a stand-up because it is intended to be so short that nobody need sit. The idea is that each member of the team says what they have been working on, what they will do next, and any blockers that are impeding their progress.
  • Sprint Planning – a “sprint” is a period of time during which the team commits to delivering some specified customer value. There is no prescribed duration for a sprint, but one and two week periods are common. The sprint planning session allows the team to work with the product owner to determine which work they should do and how much of it to which they can commit.
  • Backlog Grooming – this meeting allows the team to look through all the work that has been defined for upcoming effort and reevaluate it for priority and readiness for execution. These meetings are often scheduled prior to sprint planning, but on some teams may be less frequent.
  • The Retrospective – this meeting usually occurs shortly after the sprint ends. It is the opportunity for the team to reflect on what went well, opportunities to improve on things that didn’t go well, and new ideas for things to try as a result of discussion or other discovery during the sprint.

These meetings occur on every agile team I’ve ever worked with. But, it doesn’t end there. Some other meetings that most organization have include:

  • Scrum of Scrums – this is when all teams or a representative from each team get together and essentially have an inter-team stand-up. This is usually a brief meeting that can be similar in duration to a stand-up, which can happen daily or less frequently.
  • Sprint Review or Demo – during this session, teams show the customer value they have delivered during the sprint. This could be a session with a client, internal stakeholders, or (as is the case with ITHAKA where I work) other teams working on a large integrated system. These sessions usually take place in cadence with the sprint timing.
  • Technical Detailing – during the planning and grooming sessions, user stories are often written that need additional effort to make the work “playable.” In an ideal world, a user story would simply state what the user wants and why. The developer who picks up the work would figure out how to implement it, but in reality, there are often decisions that need to be made that the whole team should discuss first. Some teams do these sessions frequently, but keep them short and others may do them less frequently, but have longer sessions.

Add to these meetings, organizational type meetings such as:

  • Staff Meeting – because agile teams are cross-functional, it is common for the specialists on the team (developer, quality, product management, scrum masters, and user experience/user interface designers) to have a periodic meeting to discuss topics related to their specific areas of expertise. These meetings could be weekly or less frequent.
  • One on One – many organizations have some form of regular check-in with one’s supervisor to discuss progress towards goals, challenges, and upcoming initiatives. These can also be weekly or less frequent.
  • Project Meetings – organizations often have cross-team initiatives or projects that require regular coordination meetings. Depending on the phase of a project/initiative, these meetings could have different frequencies, but I have never seen them scheduled more than twice per week, but usually these are weekly or biweekly meetings. Teams can be simultaneously involved in more than one of these.
  • Organization Wide Meetings – most organizations have company-wide meetings on some sort of regular basis. These are often monthly, but are sometimes quarterly.

Whew! That’s a lot of meetings! Of course, this doesn’t count the ad hoc meetings that are needed to learn new things, meet with vendors and/or customers, and keep up with organizational practices and activities such as open benefits enrollment, retirement plan updates, human resource topics (e.g. sexual harassment awareness, which is almost mandatory nowadays).

When Do We Get To Work?

It’s no wonder that some agile team members are starting to ask whether this is working? They mean this literally…as in can you really call this “working?” Seems like there is more meeting than working. Isn’t meeting part of working? Could we work without meeting?

I am reminded of a particular session that was scheduled at an agile conference. I don’t remember the exact title, but it was something like “Agle Without Meetings.” The syllabus promised to tell us how we could get well-planned work done without meetings, chat clients or email.

The room was packed solid. There was no place to even stand. There were people in the hall looking in. They had obviously booked too small of a room for this exciting topic that clearly resonated with everyone present.

The presenter never showed up!

Not everyone got it. However, there was a lesson there. The guy that submitted the presentation probably never intended to show up. His message was simple. If you don’t want to be in meetings, don’t go to them. However extreme that may have been, there is a very real opportunity here.

Finding Balance

Some organizations have started to implement meeting policies that discourage too many meetings or inviting too many people. Some organizations give employees permission to leave any meeting in which they believe they are not getting or providing value. Still other organizations have removed the chairs from many of the meeting rooms. If you have to sit, the meeting is too long.

While these types of measures may seem a bit draconian, they serve to put organizations on notice that meetings must be valuable to participants. I have a number of standing meetings for which we have a policy: if there is no specific agenda for a particular instance, we cancel it. Furthermore, if the agenda only interests part of the team, only the interested parties need show up. I am certain that we sometimes miss opportunities because someone was not there who could have provided valuable input. This is the price we pay for balance.

As leaders in our organization, we understand the value of communication in service of alignment all too well. There are a lot of ways to achieve alignment — and communication for that matter, meetings are but one of them.

Of all the ways we communicate, face-to-face, real-time meetings offer the highest density potential for idea exchange. The key is knowing when that level of interaction is either necessary or worthwhile. It must be measured against taking people away from getting work done. To be sure, there are working meetings, which we sometimes call huddles (we are using a rugby metaphor afterall). However, I did not list these meetings above because they are just a different way of getting work done. The meetings I’m talking about are used for planning, alignment, learning, and/or information sharing.

Meetings are usually put in place to solve a problem. Sometimes, the problem they were solving goes away, but the meeting does not. It is important to regularly evaluate what meetings are on your calendar and challenge their necessity. One great way to find out if a meeting is valuable is to stop having it for a while. If no problems occur as a result, continue to stop having it.

Another great exercise is to review the objectives of each meeting and evaluate alternatives for communication. Could you use a chat room where people could participate in their own time, rather than in parallel? Would a status email work? Remember, face-to-face meetings offer the highest potential for interaction density, but they are also the most expensive in terms of sacrificing work time. Make sure that a meeting is the best option before choosing it. The progress you lose may be your own.

Tom Bellinson

Tom Bellinson

Mr. Bellinson has been working in information technology positions for over 30 years. His diverse background has allowed him to gain intimate working knowledge in technical, marketing, sales and executive roles. Most recently, Mr. Bellinson finds himself serving as an Agile Coach for ITHAKA, a global online research service. From 2008 to 2011 Bellinson worked with at risk businesses in Michigan through a State funded program which was administered by the University of Michigan. Prior to working for the University of Michigan, Mr. Bellinson served as Vice President of an ERP software company, an independent business and IT consultant, as chief information officer of an automotive engineering services company and as founder and President of a systems integration firm that was a pioneer in Internet services marketplace. Bellinson holds a degree in Communications with a Minor in Management from Oakland University in Rochester, MI and has a variety of technical certifications including APICS CPIM and CSCP.


Leave a Reply

Your email address will not be published. Required fields are marked *