Hacker News Reader

I’ve had good experiences with scrum helping a team that has both experienced (10+ yrs) and junior (straight out of college) devs be productive. Letting the junior devs take the easy tickets allows the seniors to focus on the hard problems while the junior devs learn the system.

But that only works when management is willing to say “this ticket will be on the board for a while and that’s okay, we won’t harass you about it.” That is, scrum is decent for organization but bad for management.

A good tipoff is how long standup lasts. It should be no longer than 15 minutes for a team of six, and that’s stretching it. Aim for 1-2 minutes of talking. That’s more than enough to say “I worked on tickets X and Y, I’m stuck on A and making good progress on B.”

Effectively nails it. OP sounds like he has bad product owners and ticket grooming, in some ways. Management buy-in to the different "forms" a ticket can take is important to avoid Scrum Masters making velocity charts and other various job-justifying tools that they display to themselves for themselves but hold their teams accountable for.

This seems to be my (management) take on it. The agile environments I've been involved in, all I see are the 'scrum masters' flogging everyone to clear all the tickets by some arbitrary date, no matter what they are. I've had to step in and say 'I'd rather this get done right than get done on your timeline' more than once. Pretty much why I've never bought into it...

If saying "I spent all day in front of whiteboard trying to work out the best solution to this problem" isn't an acceptable thing to say in your daily standup then your project manager needs speaking to. With my team not only is that acceptable, but we include cards in the planning process for specifically that sort of thing, with a note on them saying they're going to spawn more once we have an idea of what the solution actually is.

> spawn more once we have an idea of what the solution actually is

That's really the key a lot of development orgs miss. You have to actually break down the work into smaller pieces and track progress on those pieces. "This feature will take 3 months to do. I will start now and three months later, a working feature will pop out of the black box." - will give most Project Managers a heart attack. "This feature will take 3 months to do. I'll take a few days to break it down into approximately 1-week sized milestones and throughout development we can talk about progress vs. those milestones." - ahhh, that's much better!

Sadly, there is one reason you might want to take a team of highly experienced developers and hamstring them with Scrum: not all highly experienced developers can or will stay focused on getting the product out the door.

I've run into situations recently where the work that nobody wants to do never gets done. Even experienced engineers fall into the trap of only wanting to work on interesting features and nobody wants to do the "needs to be done" shit work.

The deadline rapidly approaches, the senior engineers are working on whatever they want to work on and it's the dev lead who stays up late and gets done what needs to be done before the deadline. Lather, rinse and repeat for a few releases and you realize why even good managers fall to the temptation of micromanagement.

> Scrum is a way to take a below average or poor developer and turn them into an average developer. It's also great at taking great developers and turning them into average developers.

Given the available pool of poor/average/great developers, this may be the correct decision.

Model: There are a1, a2, a3 developers of poor/average/quality. Poor developers cost p1, have a default productivity of q1. Average developers cost and produce p2, q2 and great developers cost, produce p3, q3. Scrum brings everyone's productivity to q2. Note that no one gets a raise or pay cut.

Without Scrum your total payoff is

     a1*(q1-p1) + a2*(q2-p2) + a3*(q3-p3)

With Scrum it becomes

     a1*(q2-p1) + a2*(q2-p2) + a3*(q2-p3)

So what you need from Scrum to be worthwhile is that

     a1*q2 + a3*q2 > a1*q1 + a3*q3

i.e.

     (a1/a3) > (q3-q2)/(q2-q1)

Now, let's say 60% of programmers are poor; a1/a3 is 1.5.

     q2 - q1 > 3q3 - 3q2

So even if poor developers improve by 1/3 while great developers are downgraded by 1, we're better off.

> So even if poor developers improve by 1/3 while great developers are downgraded by 1, we're better off.

Ye... No. Note that your made-up productivity algebra model crumbles as soon as you stop seeing developers as code churning machine and instead as what they should be, problem solvers. That's because quantity is not the only metric by which you can measure problems. Complexity and ease are others. A dozen average problems do not necessarily equate a single hard one. Hard problems can prove elusive to average devs and they're usually where you see materialize the limitations of the thinking that a single great developer can simply be replaced with a dozen average ones. One such manifestation is commonly called "technical debt".

Or just fire the bad developers.

Reminds me of https://youtu.be/VAAOnmOlrLU?t=155

But bad developers are cheaper and also more interchangeable.

Of course star developers hate Scrum. But star developer code is often crummy too, and technology advances so fast that I'm glad for every dollar I didn't pay for divine Win32 code.

> Scrum exists because managers don't trust developers to get things done without constant supervision

it's not that they don't trust them, it's that they don't get things done without constant supervision.

> potentially really smart people

potential is not actual. in actuality, most of your coworkers are decidedly average. and the average coder, like the average driver, isn't that great.

the solution for smart people (who also produce), is to not work at these places. easy.

i say this having only worked at 2 places that do scrum. both of those places had only enough superstars to count on one hand, and the rest of the staff were dullards. yet, they got things done, thanks to the micromanagement of scrum. i didn't participate in the scrum, because f' that.

The purpose of the Daily Scrum is not for the developers to report what they did yesterday and what they will do today. Manager, Scrum Master and Product Owner are all not participants of the Daily Scrum. Velocity is not a metric for reporting but for the team to plan their work.

What is your Scrum Master doing?

That's behavior tells me more about you than about Scrum itself.

In my team, we are just able to take the S cards, when the L cards are done. If a Junior get a L card, a senior will come and pair with him/her. Nobody tries to be clever, we all try to move forward together. As a Team.

Anyone know how I can upvote a comment a hundred times?