[adamsmith143]

Totally agree but from a SWE perspective on any kind of Agile/Scrum team I think the expectation is usually that you pick up another task if you finish early and there's still time during a sprint for example.

This also obviously breeds other bad incentives i.e. the faster you work the more work you get.

[nisegami]

>the faster you work the more work you get.

It took me about 2 months to learn this after getting my first job. Nowadays I intentionally add minor bugs that turn up during demos so I have stuff to "go back and fix" later.

[digisign]

That sounds... unnecessary. There is always stuff to refactor, and tests to add, folks showing up at the last minute with new requirements. Or you can just wait a day to push commits, etc. More honest, I think.

[SoftTalker]

The point is, that if you demo something and it's perfect, someone in the room is more than likely going to opine about a way it could be even better. Likely not another dev, but a product or biz person. Even if you deflect by saying "that wasn't in the story, but we'll add it to the backlog" that still takes time and unnecessary discussion.

If you leave or introduce some trivially fixable but noticable flaw in the demo, that will (hopefully) get noticed and everyone can feel that they are doing their jobs without needing to make up something.

[digisign]

Software is never perfect though, especially for an agile product. The reason agile the method is chosen is because they are exploring the space.

But you do touch on a real phenomenon, the Iceberg secret. The solution of which is typically to do mockups with wireframing software:

https://www.joelonsoftware.com/2002/02/13/the-iceberg-secret...

[sgerenser]

“That looks great. Just one thing – get rid of the duck.“

[corrral]

Refactoring and adding tests can be (and very often are) pushed into the backlog, and then never done. "We'll circle back to that after this sprint (narrator: they would not circle back to it) but for now focus on these new features"

Bugs are more urgent.

[digisign]

Disagree. This is a misconception junior devs often have... that you need to ask permission to do your job. (Not unless the boss is dysfunctional, in which case it's time to leave.)

Tests and refactoring should be done as part of every ticket and typically don't need to be explicitly called out. This naturally pushes "done" so you don't run out of tickets early.

[corrral]

Yes, but the point of this was to generate (easy) work that others want you to do so they won't ask you to do other (more time-consuming) stuff instead.

You'll have a very different experience telling the product owner you spent the whole week working on bugs that they noticed and they told you to fix (even if you left them in originally on purpose) than telling them you spent all week refactoring code. The former is an instant "great!". The latter is gonna get a concerned look and more questions.

The topic wasn't correctly doing development work, but finding ways to slack off while looking good.

[digisign]

You don't tell non-technical folks technical details, you deliver finished tickets on schedule, which makes them happy. Would you discuss what algo's you used with them? Database schema? No, then talking about unit tests is a non-sequitur as well. Complete snoozefest for non-geeks anyway.

In fact I'd be disappointed by a dev that constantly introduces careless bugs, it's a dev smell. Most bugs should be unique and result from ambiguous/incomplete specs.

Don't agree it is good advice to build a career being dishonest to others. I'm not even a goody-two-shoes... it's just not necessary in all but the most dysfunctional of places.

[afarrell]

> This is a misconception junior devs often have... that you need to ask permission to do your job

I think this is driven more by junior devs still trying to figure out what their job is.

[nisegami]

The only tests we have are some for a project I worked on that I wrote to prove it could be done. Automated testing might as well be dark magic to my coworkers.

[robocat]

Also called “The Queen’s duck”.

https://bwiggs.com/notebook/queens-duck/

[wreath]

I’d be careful with this. You dont want to build a reputation of building buggy software and have sloppy work.

[nisegami]

I'd be fine with that reputation, given circumstances not worth getting into.

[paskozdilar]

> from a SWE perspective on any kind of Agile/Scrum team I think the expectation is usually that you pick up another task if you finish early and there's still time during a sprint for example.

This is true, assuming that:

1. the whole team has approximately equal skill

2. the system is uniform and well-documented

3. the people actually give a shit about the product

If any of these assumptions are not met, then the expectation is naive.

[fatnoah]

I can't think of any environment that I've been in where this is true. I think the closest I've been was as part of a team of three people where each of us could really handle any task in the codebase. It was also true that there were things that we each cared far more about as individuals, so, in spite of comparable skills, we tended to gravitate to specific stories, anyway.

As a manager, I have every expectation that we won't be doing scrum exactly by the book, but that's totally fine. I'm more concerned about (reasonably) consistently reproducible levels of productivity, not squeezing every point out of a sprint. If there's slack time, great. That seems to be when people are most likely to contribute new stories, learn something new, etc. Besides, rigidly following scrum feels anti-Agile, anyway. People and interactions over tools and processes.

[laserlight]

Picking up another task doesn’t mean that it has to be finished. If one lacks skill, they can train. If documentation is missing, one can document whatever they learn. The last one is difficult to address, but not impossible. If team members don’t give a shit about the product, I bet they can still find something they give a shit about that also contributes to the product.

[paskozdilar]

You make a good point. I guess as long as the people are passionate, the first two issues can be, over time, worked through. I guess the tarpit is that the "time" can be really long, especially for (skill-wise) heterogeneous team working on large undocumented projects.

[dangerlibrary]

It might be time to start looking for a team with a better work culture. There are many of them.

[adamsmith143]

I am definitely willing to concede I may be in a bad situation but are there really teams in Agile frameworks with fibonacci pointing where you can pick up a 3-5 point ticket, finish it before the end of a sprint and not work on anything else?

[dangerlibrary]

Yes, there are, though that question is weirdly specific.

Is it important to you to work on a team using an Agile framework with Fibonacci pointing?

[adamsmith143]

Not at all, just trying to make a concrete example.

[digisign]

I don't think you're supposed to do nothing at that point. Leisurely improve your tools, read to improve knowledge/performance, etc. This compounds your efficiency over time, without the stress of more deadlines.

[corrral]

I've seen plenty where a point-a-day pace or somewhat under (maybe 0.8pt/day) would be a totally normal pace, and is absolutely achievable with under half a day of actual work per day, including meetings, if you know what you're doing.

But then again, points are incommensurable between teams.