Hacker News Reader

Comment by bshimmin | Hacker News Reader

I really don't see why it has to be that way, and if people feel like that, there's something weird going on.

If you've been given a large feature that involves, say, analytics, there is surely nothing wrong with your standup contribution being:

"Yesterday, analytics. Today, analytics. Yes, I said the same yesterday, it's a big job, but it's going fine. Anyone can come over and ask me about analytics if they like! No blockers. Thanks."

It tells people what you're doing and that it's broadly going ok. If you're five days into something that was supposed to take three days and you're actively embarrassed about this, then that's a problem - but it's a problem that should be discussed at the end of the third day with the stakeholders, not in the standup.

View on HN

[edit] Reporting on a high level ("yesterday - analytics, today - analytics") is fine only up to a point. This statement only works when team members are 1) mature (to admit problems) and 2) very self-aware (to accurately assess if they are making progress).

Unfortunately, huge percentage of people in software houses I've seen are young and therefore both immature and not very self-aware. They have a hard time recognizing the upcoming issues, and will not admit they made a mistake or are unsure if they can succeed on time.

The results? People claim they are on track, then they fail, goals aren't achieved. This happens over and over.

Eventually Project Manager or senior developers start probing more and more, dividing the work more, creating smaller (shorter) tasks to cater for less independent employees, adding short iterations, daily checkups and ...

Wait, we created "agile". Haven't we?

Overreport and micromanage to deal with issues.

This is why I regularly advise new hires, both senior and right out of college, that communicating when you're blocked or stuck is not optional. The quickest way to get me to recommend a performance improvement plan isn't if you can't hack it on a particular task, it's if you aren't clear that you don't have what you need (voodoo to get tools working, training, experience) to get the job done. Being stuck and not speaking up is a cardinal sin in knowledge work.

The problem is you feel like you need to justify working on one thing for two days:

"Yes, I said the same yesterday, it's a big job, but it's going fine."

and, this is even more defensive, you feel people will not believe you so you invite them to see some proof:

"Anyone can come over and ask me about analytics if they like!"

Maybe the biggest problem is this though:

"Yesterday, analytics. Today, analytics"

This task needs to be broken up into manageable pieces badly.

This task needs to be broken up into manageable pieces badly.

This would also be my immediate thought as well. "Yesterday I setup integration with the analytics service. Today, I'm going to audit the places where we currently send analytics and see if it would be possible to centralise it – I'll share the results later".

It's hard to track progress and estimate if your tickets are huge multi-week affairs.

Thanks one and all for the responses to my comment, which was written in some haste but seems to have generated useful discussion nonetheless.

Just responding to this one, I would say that it really depends. If your task is implementing analytics and no one else on the team has anything much to do with it, then maybe it's best not to trouble them with the specifics. Your summary is much better, and only a few extra words, but if no one really cares about the analytics except to know that it's cheerfully in progress, maybe it's not all that necessary to go into more detail. This is definitely something you need to be wary of in a multi-disciplinary team.

Also, I didn't mean "Anyone can come over and ask me about analytics if they like!" to sound defensive - it was actually more tongue-in-cheek! Here's another attempt: "I can't imagine why you would want to bore yourself with my analytics implementation, but please come over and ask me about it if you're having trouble sleeping at night." (I will freely admit that I am a confident person and would have no trouble saying something like that in front of a dozen people.)

Is it really important to track progress on a day to day basis?

IMO, only for a small minority of tasks.

The vast majority of projects I've seen and worked on are measured in dev years of effort.

My current project is well over a thousand dev years.

In comparison a few days is meaningless.

Most often it's a trust issue.

Is it really important to track progress on a day to day basis?

It depends on the team.

We find it useful specifically because we want to make sure we are estimating relatively accurately. Since we work in essentially 10-working-day periods, it's great to know when a piece of work we thought we could easily achieve is actually a blocker, or much more complex than we thought.

A thousand man-years of effort? Sounds like a very large project.

Just for contrast: I've been working for a medium size software house for the past 4 years. Typical project size is somewhere around 500 to 1000 man days. On that scale, individual days matter.

Still, I also have the impression that they matter because Clients demand certainty and precision in reporting rather than focusing on actual value delivered, but the management doesn't always see it that way.

> A thousand man-years of effort? Sounds like a very large project.

Kind of. It's upper-medium.

It's nothing compared to Microsoft Office, a web browser, etc.

Microsoft for example has maybe 50k developers and so creates 50,000 man years of work every single year.

> Typical project size is somewhere around 500 to 1000 man days.

That's roughly 2 devs for a year. That's hardly even a prototype where I work.

It is fascinating to see the difference in scale in our industry.

Daily standups aren't for tracking progress, they're for keeping the team in sync, and in particular are a forum for raising blockers/dependencies so that they an be addressed.

Tracking progress goes on a Kanban board (or digital equivalent).

> The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog.

www.scrumguides.org/scrum-guide.html#events-daily

> It's hard to track progress and estimate if your tickets are huge multi-week affairs.

So what you are saying is that the standup really _is_ for project tracking. I don't disagree. In my experience that has been the main point to the meeting, but it's not really how it's supposed to be done according to agile doctrine.

The point of the meeting is often (A) let management/outsiders assess progress across devs with minimal time investment on the manager's part, and (B) put subtle pressure on the devs via the daily confession.

So what you are saying is that the standup really _is_ for project tracking

Only in the sense that the team needs to know itself how work is progressing, in order to understand what they can realistically achieve, or to estimate more accurately, or to identify pain points that need to be resolved. Not tracking in the 'report to an external agency how much is being done every day', which I agree is awful.

The point of the meeting is often…

I maintain that is this happens, you are in a bad environment.

> Only in the sense that the team needs to know itself how work is progressing

That's what retrospectives, demos, and stories are for.

If there is concern about individual performance, managers could create dashboard of their teams' git commits, allowing them to jump around and see peoples' work passively without disrupting the entire team.

When developers pull tasks, their name goes on it. If one dev keeps pulling tasks that don't get done, or take far too long, that becomes obvious to the whole team quite rapidly. That doesn't "disrupt" the team at all.

Right. The point is you don't really need them to stand up every day to say "still working on tasks A, B, and C". You'd just look at the board and say, "Hey, you have four things assigned to you. Are they blocked? Otherwise, please do one thing at a time."

You don't need whole team to see that. You need to go to that one developer and ask him why tasks are not finished. I case he has solvable problem, you get the chance to fix that solvable problem. In case he does not, you need to watch him more and maybe eventually fire him.

The team knowing about whole thing won't make your job for you. It will just make them lash at each other unpredictably.

No, standups should not be for project tracking, it's a quick synch up and opportunity to raise issues. (e.g. My task is blocked until X is done). Then you resolve the blockage outside of the standup, in a longer, deeper discussion with fewer people.

Project tracking should be in a Kanban board (or digital equivalent, such as Jira or TFS). This should be used by the dev's so that they know what work is queued up, what work is in process and who's working on it, and what is completed, so that they can do their jobs. In an agile team most of the management is externalized onto a Kanban board - the team manages itself most of the time, using the Kanban board to have a shared understanding of what's going on. A secondary benefit is that outsiders can look at the Kanban board to assess progress, without consuming any dev time.

The "subtle pressure" on the dev to deliver is a great point. In fact, when status is completely transparent, developers put a great deal of pressure on themselves to deliver, because they want to honor their commitments, and there's a social pressure not to be "that guy" that blows the sprint.

While I don't mind daily meeting as such, if communication between ream members works at least half well, you should not need special occasion to raise the issues. You raise them wherever you see other team members are not focused on something.

As for second paragraph, I prefer management style that accepts that things sometimes take longer then estimated. I don't want to stay longer because made up deadline.

I think some organisations have deeper problems [than developer communication] which SCRUM and Agile are simply not equipped to cope with.

Here’s one example:

* Moving functionality from a legacy^2 to legacy (mainframe to client-server)

* Target system groaning under 15 years of neglect, developer outsourcing, technical debt and band-aids. Source system simply untouched for nearly 20 years.

* Source and target systems inherently un- unit testable

* Mediocre developers with no intrinsic sense of craftsmanship nor any desire to acquire some

* Developers with no experience of legacy codebase so completely unqualified to estimate cost of stories

* Culture of fear reinforced by performance reviews, stack ranking and PIPs

* Locked down QA systems and silo’d resources

Any one of these would be a project killer but my last employer suffered from all of them in the same project and showed no inclination to address any of them because they were deemed to be out of scope. But it was totally fine to tie up 10 people for 15 minutes every day to enable the PM to derive a magical velocity curve to feed back to the stakeholders so that the company could demonstrate how effective this SCRUM process was going to be.

"This task needs to be broken up into manageable pieces badly."

This seems to be a sentiment I see a lot, but I don't think it applies equally to all people.

Maybe it depends whether the person doing the task is a mature worker (in the sense of doing independent work).

When you break things down, you make it easier for less experienced workers to complete work. It helps the managers with tracking progress.

However, increased breakdown is very costly on many levels. You need extra time to break things down (senior dev), extra effort to track it in project management tools, extra time to deal with it all every day. It's costly.

Moreover, dividing work that way is harder and less efficient for more experienced workers. They often dislike being micromanaged and probed multiple times a week (or day) about their progress. Give them space and they excel, but ask them to explain what they do, what's next, how much time is left, etc. and they get annoyed.

Mature workers generally know who needs to be informed of issues, recognize them early on, and proactively resolve those. "Process" is what you typically need when you don't have many mature workers. It's fine, but perhaps it's best to be careful who we apply it to.

> When you break things down, you make it easier for less experienced workers to complete work.

Actually you make it easier for everyone. The point of breaking down a task is to start removing assumptions, and make it so others can also lend a hand.

> However, increased breakdown is very costly on many levels. You need extra time to break things down (senior dev), extra effort to track it in project management tools, extra time to deal with it all every day. It's costly.

Time and again I have heard this reasoning, but in my experience the real costs comes when not breaking down tasks. There is an unknown unknown problem with large tasks, that is often solved by breaking them down with the stake holder instead of finding the issues during acceptance.

I do agree though that the right level to break down tasks is an art that ends up being team specific.

It's also so you can get the jump on risks as early as possible. Consider two projects, both roughly a week long. Project A is broken down into day-long tasks, and project B isn't. On day two, the guy doing project A reports he wasn't able to get milestone 1 completely done yesterday. Others can now step in and help if needed, after only a day. The guy doing project B, who reports "analytics yesterday, analytics today" needs to subjectively assess whether or not he's behind, and depending on how experienced he is at this, nobody will know until the sprint is blown that he was unrecoverably behind.

> The problem is you feel like you need to justify working on one thing for two days:

The problem is that the Agile industry caters to the fast world of write-only web site and app producers where the most complex thing is usually the decision whether a IAP purchase should be 0.49 USD or 0.99 USD.

The fact that there might exist some actual real-world problems that map to features that take weeks to month to implement and are not trivially decomposable is completely foreign to them.

It may be foreign to the "Agile Industry" but I've worked on a complex re-implementation of a dynamic language and supporting libraries on the JVM which involved a lot of quite complex problems and various agile techniques served us extremely well.

Having said that the team should be the ones driving this sort of thing - we switched between scrum and kanban several times depend on the nature of the work, and we kept looking at what we were doing to see if it was helping us, and when it wasn't we stopped doing it or changed it.

> but I've worked on a complex re-implementation of a dynamic language and supporting libraries on the JVM which involved a lot of quite complex problems and various agile techniques served us extremely well.

Any specifics? I would have imagined this to be a case with very strict up front requirements with a relatively heavy toll on changing the design during the project.

Actually, agile was first invented for writing mission critical enterprise software more effectively - thus the emphasis on test-drive-development and a very tight confirmation loop with the users. The fact that it also works well for web sites is great, of course, but it's not where it started.

Three days long task is not unmageably large.

Personally, I find the "tasks must be tiny teeny as you can not manage task larger then few hours autonomly" management insulting - it feels like babysitting. Ok if one was irresponsible in the past or is too junior to work normally, but not ok if I was working alright.

The goal in small tasks, to me, is to encourage collaboration more than to micromanage. Sometimes you can get three free devs working on one story and turn it around in a day or two, but if it was all one "get the feature done" task, there are no opportunities there.

Fine grained efforts to "encourage collaboration" in places where it's not clearly needed is micromanagement. In fact, from an introvert's point of view, it could be the very worst form of micromanagement.

Agile only works for certain kinds of developers. In particular, it works well for people who are team oriented and communicate well, able to talk to the rest of the team to coordinate for at least 10 minutes a day, and responsible enough that they push themselves to deliver and get what they need from the rest of the team. If someone's an introvert who wants to be left alone to code, or to rely on a manager for all discipline, they need to be in a different environment, perhaps an old-school waterfall company where the manager hands out assignments and badgers people until they are done. I've done many agile transformations, and some developers just don't fit in agile, and are perfectly happy in waterfall, and that's fine. Though it might mean needing to find a new job.

I am ok having to talk with people for three hours or more a day. I am ok having to coordinate and having to respect other people's needs.

I am not ok with being micromanaged on hourly basis. I am not ok when I loose all autonomy and have no responsibility. The whole 10 minutes of talk you put in is nonsense - you won't be able to split large tasks into microtasks in those 10 minuteš a day.

Last point - waterfall vs agile is false dichotomy. So is the strawman of evil badgering management who stands against pack of developers who have all awesome social skills and are natural born benevolent leaders.

Or it might mean that the company should be asking whether agile is actually a net benefit.

> "Yesterday, analytics. Today, analytics. Yes, I said the same yesterday, it's a big job, but it's going fine. Anyone can come over and ask me about analytics if they like! No blockers. Thanks."

"You're not transparent enough. It feels you are blocked and you're not communicating. The task is too big, we will divide them more next sprint"

(later that year)

"Why have you lost your motivation?"

The Agile will continue until morale improves... :-)

Basically this. If you're working on a large decoupled task, no-one else (other than team lead) has to know or care what you're doing other than that you're not waiting on anyone else. The moment your work has to interact with someone else's work, then you need to know what each other are doing.

Sounds like a bus-factory way of working, which has its own set of problems.

As in a high-bus-number way? Not necessarily. We're talking about a few days here, not someone going off in a silo for months on end. If your standards for documentation, testing, etc. are reasonable then the results of their work should be maintainable by any team member after they're done.

Reply on news.ycombinator.com