Why I Hate These Standups...

Table of Contents

Why I Hate These Standups…

I often hear it… that they are a waste of time, just distractions from work, adding no real value…

Because sometimes it’s true. Why don’t we like standups?

  • Trance - We mostly work in a state of flow - we hate breaking out of it, as for most of us, it’s like stepping out into the freezing night in a t-shirt. It hurts.

  • I’m Not Done Yet - What do I talk about if I’m not finished? I don’t know how long it’ll take, and frankly, just leave me alone. We don’t like discussing unfinished work, especially if it turns out to take longer than expected. We fear judgment. This greatly depends on the ScrumMaster (leader) and the team’s atmosphere, ensuring such meetings don’t generate a sense of guilt.

  • Meetings (any kind) aren’t a skill we’ve mastered. Actually, not the meetings themselves, but communication. When 90% of your professional activity is spent in front of a computer, your brain stops practicing communication skills, and what isn’t practiced dies. We hesitate to use something that’s dead ;-)

Why Have These Meetings (From a Programmer’s Perspective)?

Precisely for these reasons ;-)

  • You need to come out of the trance to avoid losing all contact with the universe.

  • You need to be able to switch between details and abstraction (the big picture), otherwise you’ll create excellent software that’s useless to end users. Daily meetings give you a chance to metaphorically wipe the coal off your face and ask: are we digging in the right direction?

  • Without practicing communication skills, you’ll eventually perish in isolation, being the only one who knows what you’re doing. You might be doing fascinating things, but they’ll only be fascinating to you. In this case, there’s no remedy but to practice by talking ;-)

Starting from the programmer’s perspective, from the point of view of a Scrum Master (leader) and Product Owner (client), it’s more obvious. These meetings allow them to understand what’s happening.

However, it’s worth considering this control question: do these meetings add value? If after several meetings you feel like you’ve been chewing the remains of a cardboard box for breakfast, something is wrong. A standup should serve to highlight what is REALLY happening, what’s changing, and what problems exist. Like a good confession, it requires a decent examination of conscience, meaning 2-3 minutes to think about what you’re doing, not just showing up to produce something that sounds good.

Dear ones! Let’s not be afraid to talk! (I know… it’s not easy…)

P.S. Sometimes I hear the question: if our team has 2-3 people, should we do THESE standups? If you delve into the above text, you’ll find the answer. In short: it may not be necessary if, in another way:

  • Technical team members regularly step out of the trance, think at a higher level about their work (asking themselves in some form: why am I doing this?), and talk to the leader, client, and each other about what they’re doing and any issues.

P.S.2 Sometimes meetings don’t flow. There can be several reasons. For instance, team members speak too vaguely. But there’s another frequent issue:

  • Meetings don’t flow if they are organized for people who aren’t working towards the same goal (task, group of tasks). For example, the team consists of 9 people, but is working on mini projects of 2-3 people working independently (even though we’re working on the same product). In such cases, common meetings will be boring for most, as they won’t be very interested in what’s happening with others.

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

Related Posts

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 Property of Complex Systems

The Property of Complex Systems

This morning, while driving to work, I encountered a much longer traffic jam than usual. “Well, with such cold weather, everyone is probably driving more cautiously,” I thought, as I slowly crawled along the Łazienkowska Route. After several minutes, I noticed from a distance that there was an accident on the opposite lane, with police and paramedics doing their work. On my side, nothing particular was happening. But still… Drivers were simply slowing down to see what was happening on the other side. No one was stopping, they were just looking. And as a result, the stretch that usually took me 5 minutes this time took 20 minutes. After passing this point, the traffic sped up significantly and flowed normally.

Read More

The Natural Order of Refactoring Examined Part 4: Refactoring to Patterns

The Natural Order of Refactoring Examined Part 4: Refactoring to Patterns

By following the steps outlined previously, we begin to see a more structured solution, predominantly consisting of methods grouped into classes. It’s now time to apply object-oriented principles, such as those encapsulated by the SOLID principles. We analyze the code for patterns of repetition, the need for flexibility, and code smells, and introduce design patterns where appropriate.

Read More