Hacker News Reader

Comment by awillen | Hacker News Reader

"In too many engineering teams, sprint planning and daily standup are centered on the sprint board and backlog. Stories (tasks) are the focus of attention; discussions are focused on achieving pointing targets, the mechanics of how to achieve a particular task, or dependencies and sequencing. The problem is that teams lose sight of the forest for the trees. We forget that stories are only a crude approximation of the work needed to finish an initiative; and more importantly, that the work only matters when it has delivered end value."

I disagree with the author on the point of standups - they're not big-picture strategic sessions; they're about short-term, tactical planning. What work are you going to do today? Are you blocked by anything?

That's not to say that the big picture should be forgotten, but it's wildly impractical to do an initiative-level review every single day.

View on HN

> I disagree with the author on the point of standups - they're not big-picture strategic sessions; they're about short-term, tactical planning. What work are you going to do today? Are you blocked by anything?

This has always been my problem with standups: they feel a bit too much like micromanagement.

This may have been due to how your standup worked. Believe me I have seen it too and part of why I want to be a team lead/scrum master is to make sure this does not happen to my team.

Did your standup feel like a report to the Product Owner? Or a report to the Scrum Master? Or a report to Team Lead? Not good. Creates the feeling you had.

The standup should create conversation between team members. 'Oh you said you are doing X while doing your tasj? That won't work for my Y, good thing you mentioned it, let's have a quick talk after standup'

As a scrum master if they 'report status to you' you can for example not look them in the eyes all the time so that they can't fixate on you. There are ways to still show them that you are paying attention.

If the PO is asking follow-ups that make it clear he's expecting status reports to him you can take him aside and talk to him about that. It might come to the point where you have to threaten to throw him out of standup if he doesn't shut up and then he won't even be able to even listen.

Same goes for team lead depending on whether you have a separate scrum master or maybe the team lead has that hat.

> The standup should create conversation between team members.

A team of even adequate--not great, just adequate--people working together will have these conversations independently.

> 'Oh you said you are doing X while doing your tasj? That won't work for my Y, good thing you mentioned it, let's have a quick talk after standup'

There are two different cases where this would apply: when someone attempts to do something and finds some blocking issue, and when someone attempts to do a task out-of-order from a dependency.

The first case rarely occurs in a way that a daily standup will efficiently address. Most tasks take longer than a day to do--the standup is unlikely a time when this sort of issue is most efficiently resolved. Other than junior engineers or maybe quick bug fixes I rarely encounter an engineer who measures his work by the time between standups.

The second case is best resolved by having a proper, complete design process--requirements analysis, technical design (changes in architecture, code, dependencies, etc.), and a team-wide review--and a work tracking tool that permits tasks to be ordered (e.g. JIRA's "blocked by" label). Work doesn't always fit into that neat of a design and execution process, obviously, and it's okay to have an occasional, regular meeting (e.g. once a week or every other week, maybe slightly more often depending on the scope of work the team typically has) to address those specific issues as-needed. But those meetings shouldn't be permanently scheduled on the calendar--just while a given project is in progress.

> A team of even adequate--not great, just adequate--people working together will have these conversations independently.

Then the daily standup will be really damn fast. =)

On the other hand the daily is a place where you _know_ that the other person isn't busy and it's a good time to raise any concerns or ask for assistance.

Fast meetings do not exist.

Once the time is allocated, if there's nothing of importance to discuss then some low value subject will always fill it.

If it's going to be "really damn fast" because nobody has anything (more) to say, it's pointless (and micromanagement, for the managers' benefit only).

And if the person is busy, they should indicate as much. People shouldn't have to have a carve-out on their calendar for concerns or requests for assistance: that's an indication of a dysfunctional team.

My fastest scrums have went like this (on $chat_application):

  <scrum master> anyone have anything new for daily?
  <dev1> nope, still working on $task
  <dev2> nope
  <tester1> nope, still finishing up testing $task2
  <scrum master> let's skip it then

>A team of even adequate--not great, just adequate--people working together will have these conversations independently.

And nobody else will know about them.

Reply on news.ycombinator.com