Live data from Hacker News

How big tech runs tech projects and the curious absence of Scrum

newsletter.pragmaticengineer.com

341–350 of 452 posts

Re: How big tech runs tech projects and the curious absence of Scrum

#341
post #89

Earlier quoted context omitted.

As a Dev, I loved SAFE. It changed everything about how our program operated to the point our delivery became extremely predictable and we still had every 9th and 10th week to tinker on new ideas or do refactoring and cleanup where we wanted. That program purred like nothing else I've ever been a part of. Senior leaders sat with devs, started talking to everyone about their priorities - people we had never seen befor…

> and we still had every 9th and 10th week to tinker on new ideas or do refactoring and cleanup where we wanted. We do PI planning from SAFe. We would get the last sprint of quarter for slack, improvements, they said. Instead, we use it to clean up the mess created from waterfall scrum in the previous sprints.

In the first PIs after we started moving, this was the case for us too. But it got better every PI. The last few PIs I was in had 10 teams and a couple of them would be playing catchup, but most would be working on other unplanned projects. Either refactoring or learning or getting extra things done.

Re: How big tech runs tech projects and the curious absence of Scrum

#342

The thing about Scrum is the observations and principles make sense, but then to sell it as a course they've turned it into very specific prescriptions. I went on a scrum course and the takeaway was basically that feedback is a big deal, and you should try to get some repeatedly and quickly. It's also common sense that you should have tasks written down somewhere, and that some of them are more important than others.…

The problem with scrum is that it is micromanagement distributed. And that it makes whole team victim of the assertive asshole when that one appears.

Re: How big tech runs tech projects and the curious absence of Scrum

#343
post #299

Earlier quoted context omitted.

> the whole process revolves around the assumption that there's lack of trust and team cohesion Where in Scrum is this defined?

A mandatory meeting in which all developers must be present and regurgitate status updates to the entire team, as an example, assumes this information wouldn't get to relevant parties organically and all team members must consume all status updates.

> and all team members must consume all status updates.

This is because nobody can be assed to figure out who needs to communicate with who, on what.

Re: How big tech runs tech projects and the curious absence of Scrum

#344

Earlier quoted context omitted.

The issue with all of this addition process, ceremony and meetings is work still needs to get done. Sadly the only time to do work is often outside of working hours since then, finally, the meetings and ceremony have ended.

I don't think this is the case. A two week sprint should have about 100 minutes of standup, 1 hour of planning, 1 hour of refinement, half an hour of review and 1 hour retro, ish (I can't remember the exact timings). About 5 hours every 2 weeks. Saying that adds up to a full 2 weeks of work is just... pointless. So falsifiable.

I can only speak from personal experience (perhaps our Scrum consultant did it wrong). We have a large group and even running through the all of the demos (mostly slides really) from all of the teams at the end of a three week period took days. Added to this the retrospective, multiple planning sessions as well as all of the meetings that we used to have prior to doing this.

In the end, it was just so obviously unworkable to everyone it had to be stopped.

However, you are absolutely right, we were not in meetings 100% of the time - it just felt like it. Many people need good swaths of uninterrupted time (perhaps 1.5-2 hours minimum) in order to be productive. Rapid context switching between various meetings and development work can be expensive. It is unfortunate when this time can only be found outside of working hours.

My suggestion is to start with no process and no regular meetings and carefully add process/meetings as required. If you need to talk with one or more people... call them right now (or arrange a meeting with a clear agenda - right now). All overhead should be carefully evaluated in terms of its actual ROI.

Re: How big tech runs tech projects and the curious absence of Scrum

#345
post #84

The thing about Scrum is the observations and principles make sense, but then to sell it as a course they've turned it into very specific prescriptions. I went on a scrum course and the takeaway was basically that feedback is a big deal, and you should try to get some repeatedly and quickly. It's also common sense that you should have tasks written down somewhere, and that some of them are more important than others.…

The problem with any system is that people try to enforce it, military style. In my previous job, we did scrum, but not too strict. We had two week cycles, not-too-strict deadlines (most of the time) etc. If I finished my task early, I was free to pick up tasks from the planned list, without having to get permission from my manager. We also didn't agonize over story points, retrospective etc. We did it light hearted…

Funny, retros are the one thing I like. If you can get a team to honestly say what went well and what went bad, and the step that can be taken to improve, every two weeks, with some light follow up. In 6 - 12 months, you can turn a flaming wreck of a project into something that resembles best practice.

I have do it as a consultant. I have taken a project on life support that they were gonna cancel, regardless of our performance, and resurrected it so hard they actually decided to keep it. We changed their minds

The most effective tool was retros. I dislike agile in all other aspects, and do not use story points. Retros are the best bit! It's the core part of the learning loop.

I learnt retros from Google. Big tech does retros. Its honestly magic when done well.

Re: How big tech runs tech projects and the curious absence of Scrum

#346
post #106

Earlier quoted context omitted.

> debating whether it is worth 5 points are 8 I'm baffled by this behavior. If you know it is the next most important thing, why do you care? What would it change in your behavior if it is a 5 vs and 8? If you are looking at a task that you would choose not to do if it were an 8 but choose to do if it were a 5, then you probably look for something that is more important to work on. I think you are right that much of…

A couple things: 1. Sometimes your team needs to give an estimate of when it will deliver a feature. The idea of pointing in Scrum is that you establish a velocity, which lets you get a feel for how long it's going to take to deliver a given piece of work. 2. Sometimes your team needs to make trade-offs, and often the right lens here is ROI. You can't estimate ROI if you don't estimate the I. (Although I believe agil…

Neither "points" nor "velocity" appears in the scrum guide.

Re: How big tech runs tech projects and the curious absence of Scrum

#347

Earlier quoted context omitted.

> I realized that it all comes down to "metrics" - end of every sprint, my manager has to present it to his bosses, with pretty graphs describing "velocity" and other buzzwords. This is a thing that's pretty key to Scrum: velocity can't be used to compare teams. It is easy to misuse though. I would start every meeting I were in with "these points measures cannot be used to measure performance between teams."

I find "velocity" to be almost completely useless, both in principle and in practice. It's not only useless for comparing teams, it's useless for comparing the same team over time if anything that affects "velocity" changes: the team composition, the length of the iterations, the nature of the tasks being worked on, etc. Now, how often have any of us worked on a project where at least one of those things didn't chang…

I've seen "story points" be totally useless over time on teams where "number of tickets delivered per week" was remarkably stable. But people don't like using that for some reason.

Re: How big tech runs tech projects and the curious absence of Scrum

#348

The thing about Scrum is the observations and principles make sense, but then to sell it as a course they've turned it into very specific prescriptions. I went on a scrum course and the takeaway was basically that feedback is a big deal, and you should try to get some repeatedly and quickly. It's also common sense that you should have tasks written down somewhere, and that some of them are more important than others.…

I thought one of the interesting points in the article was that Scrum gives a team some breathing room when there are many "stakeholders" in the organization wanting feedback, updates on progress, and to frequently change requirements. The Sprint gives a defined time period during which the team is allowed to work uninterrupted by these kinds of requests, with the updates, feedback, change requests etc. taking place…

This is exactly it: Scrum and XP are designed to protect the team.

Re: How big tech runs tech projects and the curious absence of Scrum

#349
post #7

My tinfoil hat theory is that Scrum was invented by Big Tech to hobble potential future competitors.

> My tinfoil hat theory is that Scrum was invented by Big Tech to hobble potential future competitors.

Why make up an easily debunked conspiracy theory?

Scrum wasn't invented at big tech..

Agile development in general became a thing in the mid-90ties.

Re: How big tech runs tech projects and the curious absence of Scrum

#350
post #149

Earlier quoted context omitted.

A general goes to the commander of a group of soldiers and says "In 3 months, I want them to be able to demo the "march in formation" feature in front of the big-wigs who decide whether to give us more funding." So the commander says "Yes General, we'll do Drills™ to make it happen." And then the commander writes down "Do drills" on a TODO list, gives presentations to the soldiers about the importance of drills, and…

But lots of developers actually hates Scrum even when done correctly. The problem is that Scrum is very rigid, it tells you how long your development cycle should be, what your meetings should look like etc. They'd prefer to just do what needs done, have the meetings that needs to be had, deliver features when ready rather than have arbitrary deadlines (sprints) etc. I understand that many developers loves having tha…

That's a far stricter presentation of Scrum than it deserves. The scrum guide doesn't prescribe a sprint length any more specifically than "less than a month"; it doesn't say "you can only deploy once a sprint".

Now, it might be that some people selling Scrum have Very Specific Views about some of these things, but that's not Scrum either.

Post reply on HN