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

Technical Leadership Book is Available

Exciting Announcement: Technical Leadership Book Release

It is a great pleasure for me to share the information that today is the premiere of my book “Technical Leadership”.

Read More

A Manifesto Against Developers

A Manifesto Against Developers

I hate you because:

  • You focus on the features of your IDE instead of the features your client/user needs.
  • You consider typing at the keyboard as thinking.
  • You waste countless hours manually testing your code.
  • You spend more time struggling with frameworks than delivering value to end users.
  • You code for hours without asking yourself, “What am I really doing?”
  • You naively believe that technologies and tools will solve your problems.
  • You naively believe that a good algorithm is more important than a good understanding of requirements.
  • You naively believe that your intuition is enough for writing good code.
  • You naively believe that you can manage the complexity of the system piece you’re working on.
  • You agree to unrealistic deadlines.
  • You write poor code and rationalize it with various excuses (because there is no time).
  • In your head, you create code snippets without really knowing what needs to be done.
  • You guess what needs to be done rather than clarifying.
  • You mindlessly follow the technology you use.
  • You don’t understand the tools and technologies you use.
  • You isolate yourself in your piece of code, breaking contact with the world.
  • You think it’s all the fault of managers or clients and believe you can’t do anything about it.

… even though I love you because I am a programmer myself.

Read More

The Natural Order of Refactoring Under the Microscope Part 3: Extract Method

Analyzing Class and Method Responsibilities

In the next step, we examine the responsibilities of individual classes and methods, checking if they align with the intended responsibility of the class. It is best to analyze all methods and group them based on performing similar operations. We look for a place for these in other classes or a new class. Remember: if there is a significant private method in a class (longer than 3-4 lines), it should be moved to another class.

Read More