Hacker News new | past | comments | ask | show | jobs | submit login

However, many companies face similar issues. For a moment I thought the OP worked for my company because we face the same issues (that's not possible however because in person stand ups are banned at our company due to the distributed nature).

1) While I agree that 20 people seems like too large a team in general, I have a fundamental problem with the idea that scrum can determine what size team is right.

What seems to be happening, it appears to me, is that we have a fair idea of how large a meeting can be before it becomes unwieldy, and scrum has a daily meeting as it's fundamental component, so basically decides that for it's fundamental component to be effective there shouldn't be more than 8 people so therefore teams shouldn't be larger than 8 people.

That seems backwards to me.

2) Almost every scrum training usually has a separate scrum master. I do think the idea of a team member being the scrum master makes a lot of sense and would probably alleviate a lot of the concerns.

3) Scrum story points are supposed to reflect end user benefits. A refacorin's benefit will only show up after several sprints. In the meanwhile you hurt your velocity significantly because your refactoring is likely to be 0 points. Now, this actually makes sense to me, but the issue is that in most places management is carefully monitoring velocity and is gonna hold the drop against the team.

To be fair though, I think this is another issue where the real problem is management converting a measurement metric into a target, which basically negates any use it may have as a metric.

My biggest issues with scrum are: 1) A daily standup is ridiculous. It's highly disruptive and gives me the feeling of someone constantly peeking over my shoulder. A better strategy is a simple email when someone has an update, or a blocker to the rest of the team. Very few of my projects are done in a single day, and it's psychologically stressful to join every meeting saying I worked on story A, will continue working on story A for 3-4 days in a row, while the managerial types rattle off a list of meetings they attended, emails they sent, trainings they completed, etc. 2) Sprints are far too inflexible. Each story should basically define a new Sprint for the people involved in that story, which may or may not be longer than originally expected. I don't see the point of having a fixed 2 week period that applies to everyone. Why not just have a weekly or biweekly meeting where you go over everyone's stuff and see where you stand. It's basically a more flexible version of what sprints try to achieve, without the psychological issues created by having to fit things into a Sprint or alternatively having to carry it over into a whole new Sprint. That same meeting can track how many points were earned since the last meeting and you have your velocity being tracked as well.

Retrospectives are great. But they should be included in the same 2 week catch up meeting.

I find scrum tries to create a lot of artificial deadlines, possibly to encourage people to break things into smaller pieces and make regular progress, but I find that's not how people usually work. In my experience people tend to work more in spurts, delivering a ton of features and bug fixes over a couple of days, and then going relatively quiet for the next few days. Not because they aren't working, but because thats just how things usually pan out since software development is a decidedly non linear process.

> Scrum story points are supposed to reflect end user benefits.

That’s not my understanding at all. In our org, that’s the role of backlog priorities. Story points are the cost to get there, and are explicitly a tool to estimate relative amounts of effort involved.

If tech debt is to be incurred, it is expected that engineers negotiate that, and that other estimates will change as a result (and/or other tasks be created to track that debt). But then, nearly 100% of the managers in our org are, themselves, engineers or SMEs in the field they are managing, so they have realistic goals and understanding of the sausage-making process. What you’re describing really does sound more to me like a management problem than a process problem.

Sometimes I find myself so stressed out by the standup, I basically doing nothing the rest of the day. Also I have a habit now to get up early and try to do yesterday's portion of work in an hour or two before standup just to report it. I completely stop thinking in time periods wider than sprint, and I thought before that was my strength. Worst thing, the process forces an idea that my struggle with it is, basically, my fault. I hate "scrum".

You are not alone. Meetings just suck all the energy out of me.

I think the scrum team size is determined in part because communication overhead is exponential, getting beyond 6-8 people means the whole team has to spend a lot of extra time coordinating. This is true regardless of whether you're dong scrum or not. It's true some teams may be correctly sized at 20, but I would suspect that breaking that into 2-3 other teams would be a benefit most times.

Story Points represent effort and uncertainty, not business/customer value - those are Business Value Points. Devs are only committing to X story points per sprint. If refactoring is needed, it's built into the story points, or added as it's own task. And as others have said if the Product Owners don't take engineering input on paying down tech debt/infrastructure/internal tooling, then you have a broken company no matter what process you're following.

> 3) Scrum story points are supposed to reflect end user benefits.

Scrum.org states[0] A Story Point is a relative unit of measure, decided upon and used by individual Scrum teams, to provide relative estimates of effort for completing requirements.

[0]: https://www.scrum.org/resources/blog/why-do-we-use-story-poi...

According to Jeff Sutherland himself[1], story points are based on team effort and not end-user benefit: Estimates are estimates for the team to get a story done.

[1]: https://www.scruminc.com/story-points-why-are-they-better-th...

Eh, the idea that a team should be no larger than the number of people that can meet together is not unreasonable, if also not incontrovertible. What makes a team a team if they can't meet together as a team effectively?

I'd say the most important characteristic is whether the team can work together effectively.

As an example, one could consider the various people working on an individual open source project as part of a team. And most successful O/S projects rarely require everyone to meet together at the same time.

I personally strongly prefer small teams (I find even 8 members too large), but arguably certain projects may need bigger teams, and I think they should still be able to practice Agile with the bigger team, which scrum doesn't allow for.

Thanks everyone for correcting my understanding of story points (which was based on scrum training provided by my current company).

Effort makes a lot more sense, and I particularly like that it tries to incorporate uncertainty as well (I guess that's why they chose story points, to make it vague, since using hours leads to people treating estimates as deadlines instead).

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact