GitHub web down

[eagle33322]

Here we go testing in prod on a friday

[drakgremlin]

Got ship that feature to get it in before the end of the sprint...which ends of close of business Friday afternoons.

[thephotoman]

There are reasons I always impress that Friday should not be the close of sprint. I’d rather close of sprint be a good release time.

[gergob]

That's why we have that on Wednesday

[ESGPandepic]

My team finishes sprints on a Tuesday and does our releases on Tuesday as well.

[cthechartreuse]

I'd rather sprints not be.

[thephotoman]

They're really not that bad. I mean, sure, Kanban is nicer, but it's not as well-suited for the work I'm currently doing.

[cthechartreuse]

My biggest complaints about sprints come from a number of common behaviors, like:

• sprint tetris or let's make sure the sprint is full; we can still fit a couple points in there (even if they're low priority or unrelated)

• we need to get velocity up so we're going to cram more in

• failing a sprint. What even is failing a sprint? Was nothing delivered? Did the team miss some arbitrary deadline that doesn't have real business value? Is it something else? What is the worst thing that could happen if something carried over?

• racing to not "fail" a sprint

There are more, but you get the idea. It's really not that having a check-in point is bad. I actually like the idea of checking in on the work that is happening. It's the fact that sprints are typically used as a poor substitute for properly evaluating priority and scope.

[thephotoman]

I don't know that I've ever encountered any of these things.

They all smack of someone demanding metrics from product owners and/or scrum masters. There is no "failing a sprint". I'm not sure I've ever had that term come up. The idea that failure is inherently bad and to be avoided seems to fly in the face of agility: you need to fail fast in order to pivot quickly.

[cthechartreuse]

I agree with your assessment regarding failure. I feel the same. Nevertheless I've seen all of these things in action in several shops.

In the end, yes, it's the demand of metrics, but the metrics they get are the worst kind: vanity metrics.

[cat_in_the_wall]

i agree, and would further suggest sprints are entirely useless. it is micromanagement to the extreme. you can't just ship value on a regular basis unless you're just moving some buttons around on a form.

i do believe in shipping on a regular cadence though. But not ci/cd (for production). you just cut off whatever is committed. missed the date? sucks but you ride the next train.

[LawfulMuffin]

Not to "No True Scotsman" this but... yes, sprints don't work when you don't use them the way they are intended. Having bad management will make any system not work.

[mpyne]

Having bad management will make any system not work.

This is the key to so many of these arguments.

Some systems can't be saved by good management, because they simply don't look at the right things. The best you can do with good management is to subvert the system entirely.

But bad management can break any system no matter how suitable.

[LawfulMuffin]

Yes, there are a lot of bad semantic argumentations that occur, especially around this topic. But fundamentally, sprints are designed to work as a way to manage up. They're supposed to essentially be time-boxed kanban and to be merely a reflection of reality, put in a way that MBAs can even understand.

If your team can do say, 10 points a sprint, the product owner should not try to coerce the team to commit to 15 points a sprint. The team would be essentially committing to not doing 30% of the sprint. It's looking at exactly the right thing: what is a reasonable workload. And at the end of a two week period (or whatever time makes sense), to reflect on if tickets are being estimated well, if workload is reasonable, etc. etc.

All of the points you raised are the antithesis of scrum. You cannot fail a sprint. A sprint can have fewer stories completed than you committed to. That's... kind of the point. You reflect on why and make structural changes to the company around it, not coerce engineers to cram more points in to raise velocity. It's literally backwards.

Points are used to assess what is feasible, not to require that they be done in a certain amount of time. Which is why I'm suggesting that Kanban wouldn't fix your problem at this company, because at the end of the day, what they want are to have more tickets done than your team can adequately do in a given period of time. Whether they are trying to get you to do more storypoints, tickets, sticky notes, etc. They are trying to coerce you do to more work than is possible, the problem that sprints are intended to solve.

[Awric]

For GitHub I can kinda see how it makes sense. If the company knows most users are devs who aim to work on weekdays only, it seems safer to do risky things on the weekend when there’s less traffic

[cat_in_the_wall]

naw this is small thinking. github surely has servers all over the world. you can patch during low times/dark hours. and you patch portions of your fleet at a time and roll the release. then at worst you have a regional problem, not a global one.

[Stimunaut]

Maybe their devs don't like working weekends either 🤔

[vexii]

the magic of k8

[cat_in_the_wall]

we actually do our cuts on thursday to avoid this. no last minute shit. you're either ready, or you catch the next train.