Tag: Agile

How to make efficient status meetings

Do you know these horrible status meetings? Every week, every two weeks or – when it is critical – 2x a week? Especially with multiple members? And you never know whether it’s important to go there or not? But you need to go there because there might be a relevant information?

The myth: “If there’s nothing to say, we can quickly close the meeting after 5min”. Seriously – I’ve not seen this happen very often. It quickly drifts into a common chitchat or Q&A. Don’t get me wrong: socializing is important – but a status meeting isn’t a socializing event.

I had a couple of such meetings in the past. When it was just one it was okay – but as I got involved into multiple projects, my schedule started filling up with such kind of meetings. And this became very unsatisfying as it sucked a lot of my time – and even worse: It sucked a lot of overall team-time!

My advice: GET RID OF THOSE MEETINGS / OF THIS MEETING STYLE!

By applying some simple rules such meetings can become ways more effective. but beware … discipline is required.

Preparation:

  • NO STATUS!
    A Status should be transparent in another system (like any Issue tracker / Todo / something – no need to go through that separately)
  • The agenda is in a shared document (Confluence, Wiki, OneNote, Word, Textfile, …) where every member can edit – not just the host – everyone! We don’t want no bottleneck!
  • If a member has a topic do discuss or an information to distribute: This person writes it into the agenda by him/herself in self-responsibility (example: “@name: my topic”).
  • You can also make this document available in a larger audience for transparency.
    Reason: This is raising trust; it allows others to follow and react upon a decision or information without additional post-meeting emails. Also, no fear of missing out (FOMO) in case of not attending.

Before the meeting:

  • No topic, no meeting! If there is no topic – CANCEL the meeting! REALLY!
    Everyone is thankful for the time that was freed.
  • Everyone quickly checks the agenda. May be a bullet point can already be clarified or discussed beforehand / bilaterally and doesn’t even need to go into the meeting. The result can be added directly into the agenda and is thus being distributed already.

During the meeting:

  • If there are multiple points: start with the clarification if there are topics that only a part of the members is interested in and move those topics to the end.
    Reason: some people can leave earlier!
  • The meeting is ONLY about topics in the agenda. ONLY. Everything else goes to the next meeting. This must be rigorously enforced! This is crucial!
    Reason: No fear of missing out (FOMO)! The agenda must be trustworthy and enables the next two (important) points:
  • Members only join the meeting if at least one topic of the agenda is relevant for the individual.
  • Everyone is allowed and encouraged to leave the meeting if the remaining bullet points are irrelevant (drop a quick “thanks, rest is irrelevant for me – I’m leaving” in the chat, so everyone knows that you were leaving intentionally and not just disconnected)

We do this since a couple of months. We follow these rules and have saved numerous hours of working time in the past! But it needs discipline – for sure.

Don’t just ask for Feedback and Improvements

“Every employee should feel encouraged to give feedback and contribute ideas for improvement!” Who has heard this before? Probably everyone!

My (slightly provocative) opinion: “The effect was probably close to zero. So Forget it and don’t do such a shout out!”. Unless you want nothing or barely anything to change. Then do a big shout-out and send people back to work! Great show – with no effect! Of course, I made the mistake myself and didn’t notice for quite a while (years, actually). Every now and then an idea or suggestion came along (or I had one myself) and we were proud of the improvement. At some point between Retros and PostMortems I got the point: “It needs the right framework!”

Why are there retros for projects / sprints / teams / …? Why are there PostMortems? What’s the justification to do them? Not because of the “new fancy agile stuff” where you “just do it that way”, but because it pays off – it works. Because it provides a framework for discussion. Because time is explicitly reserved for the questions: “What can we do better?”, “Why did […] happen?”, “How can we prevent […] from happening again?”

And within this “frame” – that reserved time – people really find the time and opportunity to express ideas. Or just explain some tedious tasks that should be improved because they are … tedious. In this reserved time, there might come more ideas than in the days and weeks before. Than in the time where people are permanently confronted with the problems – where one actually could already come to the conclusion that there is potential for improvement. And maybe also more complex ideas, which people just can’t “simply do” besides regular work. Complex ideas which need a little time to be explained, discussed and understood.

If you want something to run better, the call for improvement is a step. But only one step. So the next step is: Okay, get all people together that are concerned and willing to contribute. Let’s have a look at the bugs/whatever… of the last weeks. Where are do issues pile up? Where do we ALWAYS do the same thing over and over again (“Toil” in SRE Speak)? What’s annoying? Do we have data with which to raise an assumption to a fact (that makes prioritization ways easier)?

And then the essential points: Derive actions, evaluate and implement! And do it on time! Otherwise, any motivation is not only gone, but it is immediately learned that nothing happens anyway.

All this is time-consuming, tedious, inconvenient and also annoying when you have to prioritize the actions against other tasks … But … it brings value. – So if you want to improv: Don’t just ask for feedback.