Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

newsletter.pragmaticengineer.com

Post reply on HN
Print view View original

421–430 of 452 posts

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

#421

Post by esel2k »

artichikin wrote: post #296
shoto_io wrote: post #122

Shape Up: mentioned for a few venture-funded companies. Has anyone here some experience with Shape Up? Love to hear your thoughts. I just read about it so far and would love to hear some real-life stories.

We adopted it a year ago and the team still quite likes it. Reduced day to day stress and distractions and a good structure and shared vocabulary. Wouldn’t say it’s perfect but much nicer than the sprint treadmill.

We just started using it and I am pretty happy that it keeps PM (me) really shaping things with a fat marker to farm for dissent early on without distracting devs in endless meetings. So sharing vision and customer problems early is great.

What miss is (maybe its me): How do you get into that execution mode from there? Break it down? High level estimates? How do get started (especially large endeavors that would be more than 6weeks)?

Thanks for any insights

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

#422

Post by robertlagrant »

giantrobot wrote: post #317
mindcrime wrote: post #251

Earlier quoted context omitted.

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 too find velocity to be one of the dumbest aspects of Agile. It takes the stupid of story points and doubles down on uselessness and arbitrariness. Velocity in physical terms is an instantaneous measure. It's the same in Agile, you've done X things in Y time. But that ignores the context of those X tasks and the context of Y time. The X+1 task might turn out more difficult or have some other challenge that makes it…

> I too find velocity to be one of the dumbest aspects of Agile

It's not part of Agile. It's specific to Scrum.

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

#423

Post by robertlagrant »

regularfry wrote: post #347
mindcrime wrote: post #251

Earlier quoted context omitted.

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.

> 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.

I don't see how this can be the case. If each ticket is estimated to be about the same size, and it sounds as though they should be, then if you're doing say 5 tickets a week, 10 a sprint, and they're all about the same size then each ticket you could say is 5 points, and you're doing 50 points a sprint.

That's probably pointless (hah) if they are all the same size; ticket sizing is more for if you have tasks of different sizes and you're trying to roughly combine them into something you can predictably deliver.

But if you're at a stage when your delivery is already this predictable, you may not need to use story points particularly. If it's mandated for some silly reason then you could use the above method to bat it away quickly!

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

#424

Post by _y5hn »

Millenialboomer wrote: post #273
nickd2001 wrote: post #143

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". I wonder how widespread this is.. Certainly that's exactly what I experienced at a previous workplace, and worse than that, people's performance was judged on whether they'd done exactly the "right" stories in a 2 week sprint. Rather than thinking about developing software, people were working out how…

As a manager, we have been incentivized to game this system exactly as you describe, both from my end and my devs end. Moving to a company which only cares about delivered software instead of metrics saved my soul.

The problem here this is only soul-crushing for the competent.

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

#425

Post by _y5hn »

bitwize wrote: post #246
commandlinefan wrote: post #214

Earlier quoted context omitted.

> whether they'd done exactly the "right" stories in a 2 week sprint Not only that, but if anything else comes up during the "sprint", you're expected to address it while still finishing everything that you (involuntarily) "committed" to during sprint planning.

WE committed. We made these commitments as a team. If you can't fulfill what has been committed to by the team, then we as a team have to have a discussion about that. I'll put the meeting for next Monday on everyone's outlook.

Estimates are not commitments. I know young devs are preyed upon, but people can't be pushovers in the workplace. It's really detrimental to all, so we need to support reason above rituals and rigid processes.

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

#426

Post by _y5hn »

sunwooz wrote: post #320
akudha wrote: post #84

Earlier quoted context omitted.

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…

Oh god, this perfectly describes the company I just quit. They went from using Trello, allowing us to choose what to work on, loosely setting story points and ... that was it. Then they decided they needed the metrics on everything, so they switched to JIRA, started doing retros, setting strict points on tasks(reprimanded in retros if you messed up), using burndown charts to reprimand even more, and giving the produc…

No need. Abusers won't listen in the first place.

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

#427

Post by _y5hn »

seanhunter wrote: post #192
jonpurdy wrote: post #176

Earlier quoted context omitted.

Everyone is correct in this thread. The stimulation of discussion is useful, and numbers are arbitrary. Instead of worrying about 5 vs 8 though, the team should be discussing relative difficulty: is story B easier/more difficult/complex than story A? And then ranking stories based on the relative difficulty of each other. Story points can then be derived based on that ranking, if the team chooses. They're useful for…

That for sure seems useful. "Hey Sally, you think B is harder than A. Why do you think it's hard?" "Hey Bob, you disagreed with Sally and think B is easier, why is that?"...is very likely to lead to a useful conversation in terms of everyone getting in sync and may well lead to hidden information being brought out into the open, which is a good thing. In general I think relative value/preference type conversations te…

Attention! Discussing story points is no longer allowed during planning. After voting, teams are to discuss relative story points, swapping points between each two story. This is expected to increase efficiency and coherence. Rule enforcement commencing beginning of next month after the first weekend.

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

#428

Post by regularfry »

tootie wrote: post #417
regularfry wrote: post #411

Earlier quoted context omitted.

Then that's the difference. Siloing devs away from the customers is something you see as a positive. Which, for some situations, it can be. But if you're in a situation where there's meaningful advantage in cutting the feedback loop down and reducing the number of handoffs between functions, it's not. The key here is that you're using the third person: "their goals", "their money". "Business" is a remote third party,…

We're absolutely not siloed. It's a question of expertise and attention. And also we're media so we have millions of users with extremely varied habits and needs. Discovering what those are is a huge job and one best done by a dedicated expert. I can't spend my dev hours having them sit and listen to stories about business process and sales funnels when there's dev tasks to do. Unless your company only has a single j…

The answer to your original question is "trust the team". Integral to that is that they must have the skills on the team (or close to hand) to be able to do specialised work, in the same way as you might have someone with the "DBA" job title who specialises in databases. What you would expect is not that all the database work goes to the DBA, but that other team members would pick up DB jobs that don't necessarily need the full depth of their skills, with the DBA there to help if needed, and the team would be able to sort all that out themselves without management overhead. Incidentally that's also why you don't need to hire people who already have cross-cutting skill-sets. You're aiming to hire people who can learn, and trusting them to do so.

If you're not in a situation where you can envisage "trust the team" being something you could live with, then yes, what you're doing probably looks rational to you. "I can't spend my dev hours..." makes me think you're in a fundamentally McKinsey/Taylorist environment, low-trust by design. That's not uncommon, but it doesn't make other approaches wrong either.

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

#429

Post by vikingerik »

knightofmars wrote: post #300
Clubber wrote: post #83

Earlier quoted context omitted.

>Most of Scrum's bad rep comes from people who think they know better, tweak it to suit their needs, then realize they made a ton of holes in the system and their Frankenscrum doesn't really work. I remember when Scrum came out. It's a very specific method for a very specific company type that was sold to work with any company. Before scrum, each company kinda figured out their own processes based on their size, team…

Anecdotally, I've experienced the exact opposite. The company I work with had been doing waterfall development for 15+ years. We switched to agile using the Scrum framework. It wasn't smooth sailing the entire way, there were teams early on that struggled with adopting Scrum. Most often it was due to the team attempting to solve every retro issue by updating "the process", which only addressed symptoms instead of fix…

I had the same experience, in a longtime waterfall company, that adopted Scrum, with significant pain points but it was still a world of improvement. The thing that the Scrum haters don't see is that its biggest benefit is invisible -- it's in what doesn't happen, in what Scrum avoids.

Scrum avoids the eighteen-month waterfall death marches that kill a department or a company. Scrum gets you thinking in terms of managing scope, of pacing deliverables, of thinking of a list of prioritized "wants" as you say rather than a dictated set of commitments. Scrum makes you approach development as it has to actually happen in the real world, rather than as a dictated plan that inevitably won't survive contact with adversity.

Of course it's completely possible to still mess that up, with overzealous adherence to process and ceremony and metrics. It's very possible to run Scrum as a set of perpetual two-week waterfalls -- and very possible that that's still a great improvement over two-year waterfalls.

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

#430

Post by aprdm »

kragen wrote: post #399
PerkinWarwick wrote: post #105

Just to be the old grouchy guy, I can't say that any of the modern processes sound like any fun. 90% of the time I've run into them it was basically a way for external consultants to make a pile of cash (and for an internal champion to work without doing work), the other 10% it slowed down development to a series of small changes. Perhaps it's just a difference in the scope and type of projects (boutique hardware vs.…

The software process stuff I've found most valuable is really the XP/Joel-Test stuff, not the Scrum stuff: · nightly builds or continuous integration; · pair programming or code review; · automated builds; · comprehensive test suites or test-first programming; · fixing bugs before adding features; · source code version tracking software; · keeping a list of bugs and planned features instead of not keeping one; · prio…

Great post. Totally agreed.
Post reply on HN