If you can’t beat ’em, join ‘em

On life with traditional meetings in agile times

In an ideal world the Scrum Events provide transparency on your project (or product, for that matter). Basically that’s the whole idea behind Scrum: solving the need for information of various stakeholders easily: interested people have the chance to track progress by visiting the sprint reviews. If you want to know what’s hindering, well, just visit a daily (as long as you’re not hijacking the discussion, that is). And planning gives a good impression on what we are trying to achieve within our respective timeframe. Heck, teams make both progress and impediments visible through the Sprint itself.

In theory this should at least reduce the need for any other meeting (I refer to them as TMF’s for „traditional meetings formats“, going by Jour Fixe, Project Status Meeting, Steering Committees and the like), right?

In reality, not so much.

Photo by rawpixel on Unsplash

We encountered ever so often that the Scrum Events are done by and for the teams only, with at best random attendance of stakeholders and other interested persons. Gemba Walk*? Way from it. We have seen people questioning rather the Scrum Events than any other TMF. „Do really all developers need to attend a Daily?“ „Is a regular retrospective really needed?“, „Really one hour for evaluating what went wrong in the last sprint?“…

Our impression is that we cannot change this by only referring to the Scrum Guide or stress things like mutual trust.

To make sure, I understand people are doing this in good faith. TMF have been the way to do steering and overseeing for more than 20 years, people are used to this and are having a hard time opening up to new ways of work.

So, if we have to deal with both things for the time being, how can we at least generate as much value out of any TMF as possible? Why not take the Gemba Walk* to them — or to quote what’s attributed to great Chinese general and philosopher Sunzi: if you can’t beat ’em, join ’em (albeit for a certain amount of time).

We find these topics valuable and have them set on the agenda of a TMF first and foremost:

  1. Impediment walkthrough: reminding management on their most important task: removing impediments. We confront them regularly with all things hindering teams delivering great work: Unresolved dependencies, missing access rights, lacking hardware, you name it. This helps develop a sense of urgency. To prepare this, you only need a comprehensive list of impediments that cannot be solved by teams alone.
  2. Bad surprises: ever had too many unexpected bugs? Newly found dependencies? In short, the unthinkable has become reality? This section gives an unflinching look on everything that’s been derailing us in our sprints. It’s not meant as an excuse, rather as healthy expectation management. To prepare this, you will need a good overview on the workload within your sprint.
  3. Team Morale Check: your team is constantly reshuffled? Unresolved dependencies really are stressing people? Multitasking everywhere? We know the emotional state of a team has decisive influence on your delivery, but so far this hasn’t permeated to everywhere. Let us regularly talk about what moves people and let’s undergird effects of management discussions with facts on performance and velocity. To prepare this you need to discuss this in your team retrospective and determine which points should be addressed to management.

Granted, no guarantees given (except stakeholders will be ill at ease with this in the beginning). But chances on success are increasing the better the measurement is and the more comprehensive your metrics are. Recognition factor rises with regular repeatings which in turns generates trust. Transparency will over time lead to mindset change and to what we really need: that management should join the team, or empower the team, with a fully empowered Scrum Master.

To that end: stay candid. Radically.

  • Gemba Walk: Coming from the japanese word for “the actual place”, this denotes the action of going to see the actual process, understand the work, ask questions, and learn. The term was coined by Taiichi Ohne of Toyota.