That sounds like you weren’t doing scrum right. It’s also possible I wasn’t doing it right and was doing a healthy version of it?

Every scrum proponent always responds to any criticism with a no true Scotsman claim. I’ve never personally seen or heard second hand of a successful scrum implementation, and the SWE academic literature doesn’t support it either.

I’d argue that spending time on activities like scrum poker or sprint planning are actively harmful for most kinds of teams. The points games are inherently adversarial, only add value for scrum masters, and waste time that could be spent understanding requirements/business problems better. The incentives are inherently perverse and the whole exercise encourages and rewards dishonesty.

Well I feel it was successful on my old team. We weren’t micromanaged and owned our own process. We story pointed and those metrics were only ever seen and used by us. We got tons of value out of retros (had loads of difficult conversations with high levels of trust). We didn’t have a scrum master—everyone knew how to run all meetings and process. We worked closely with our customers doing rapid prototyping as to not waste time building features they only thought they wanted. We showed progress to the org via demos. I feel like it worked really well and really enjoyed it.

As far as no true Scotsman, I didn’t mean it like that—I don’t care if people don’t want to use scrum, but I do take light exception when people shit on it an go on to describe a process that is alien to me. Though I guess what my teen was doing was a bit more of a mix of scrum and XP.

> We story pointed and those metrics were only ever seen and used by us

That seems to be the exception rather than the rule in my head experience. Even still, what concrete value comes from assigning fairly arbitrary effort estimates in this fashion?

> but I do take light exception when people shit on it an go on to describe a process that is alien to me

Respectfully, I’ve seen a bunch of scrum implementations and attempts in that direction and they have a lot of overlapping pathologies. I’ve also gone to the source material. IMHO scrum simply wastes time on meetings that give a false sense of visibility and create a lot of negative incentives. For those costs, I’ve never seen a return that was worth the trade off.

It sounds very much like you were doing some flavor of XP with a few scrum meetings sprinkled in. This isn’t the process scrum evangelists and consultants are pushing. But I’d still argue that most story pointing meetings are wasteful.

There another issue I've seen with all the forced estimation that gives questionable values to the business.

When devs overestimate they then tend to take the extra time to overengineer the solution, and when they underestimate they tend to take on technical debt to make the very arbitrary deadline.

I think it also incidentally discourages the trade off conversation by artificially time boxing work.

> what concrete value comes from assigning fairly arbitrary effort estimates in this fashion?

This sounds counter-intuitive, but I’ve found in many teams the value of story pointing is to instigate healthy conversations about requirements and surface assumptions in a team that might be reticent to engage in those kinds of conversations naturally. The actual point values are probably the least important outcome - any inaccuracies tend to average out over time anyway.

I’ve gone in to many teams in my career where “planning” amounts to 1-liner tickets describing a month’s worth of work, and the team has a few dozen of these in the backlog. Conversations about what is actually involved in delivery don’t happen, and execution is chaotic because everyone has a different understanding about what we’re building.

This sounds like a dysfunctional team because it is. A surprising number of teams are dysfunctional, and many of these frameworks and tools come out of attempts to solve for dysfunction.

In these teams trust and morale tends to be low. The abstraction of story points (and associating them with complexity, not time) opens the door to having conversations about what the work actually is rather than how long everyone will take to do it.

It’s a lot easier to hear “why do you think this is a 5-pointer instead of a 3-pointer” instead of “why do you think this will take 5 weeks, I think it should only take 3.”

Scrum isn’t a universally-applicable tool, and introducing story points without also leveraging their ability to stimulate conversations about the work is a waste of time, but applied well they can help break through to teams that aren’t ready (or don’t have the muscle memory,) to have these conversations without some kind of trigger.

Having been in a team that needed to have these conversations because many were ramping up on the work, these conversations were godsends for catching inaccurate and problematic assumptions, making sure people understood how their work supported the business, and enforcing consistency with how the work was organized and documented which helped as the team grew and turned over.

That’s fair. Honestly I haven’t gone too deep into the source material. Most of my knowledge comes from two former coworkers and current friends who were well versed and experienced in XP and agile and had a huge impact on the engineering culture at the company I was talking about.

I actually don’t disagree that story-pointing feels like a waste of time, but I do find it useful to talk about what’s involved in a task and figure out how long is might take. I don’t think it’s unreasonable for management to want a rough idea of when something will be delivered, mostly so that they are able to plan themselves. Of course, it all depends on endless variables as to how much process a company needs. In larger companies with multiple teams, I strongly believe in self-organizing teams with a well-defined point of contact and freedom to implement as much or as little process as they want.

Edited to fix horrendous typo as a result of typing on my phone. I likely didn’t catch them all.

Yeah, I think periodically talking with product folks about the nuts and bolts of a task is really useful. It’s even quite useful to think about when tasks are becoming large. That sparks a lot of good conversations. The specifics of how to best do that will vary a lot team to team.

We do it pretty lightweight as a way to estimate the whether there’s the right amount of work to fill up ~2 weeks. Senior engineers get a lot more leeway to reprioritize on the fly.

That’s not entirely unreasonable but also not the prescribed method I’m criticizing.

I get that. In general I find scrum/agile to be unhelpful when run by people who don’t adapt it to the team/business needs.

> what concrete value comes from assigning fairly arbitrary effort estimates in this fashion?

My team asked for this. I dont know why they need it but apparently it helps them understand how much work theyre agreeing (and committing to shipping) in a sprint.

I think if you have a good grasp on what each issue will entail, you dont really need it but if youre less experienced maybe it helps?

But that just begs the question, why sprint? Two weeks seems arbitrary, and meetings on that cadence are pretty noisy. Trying to deliver in that frame can either lead to dead time if things go faster than expected or can lead to artificial failures if you miss it. Why set yourself up to fail that particular way? I don’t think it’s especially useful for organization or accountability and adds a lot of noise and waste.

Of course its arbitrary, but you gotta pick something. We optimise for progression. Failing a sprint doesn't actually have any real ramifications. What we use failure for is a signal to indicate problems. Missed? I guess we have some talking to do in retro to figure out what was misunderstood. Missed three sprints in a row? Is there a problem we need to resolve?

Similar to misses, we don't really get much from shipping on that cadence either, other than progress and building confidence in upper management to base their timelines on us delivering what we expect.

planning can be useful if stories entering the queue are refined in real time and the team knows where they are going. best case, it's a ten minute "here's the backlog; who needs work?; what are we shipping this week?" conversation...but this assumes a high-performance team of go-getters where every story is vetted well enough for anyone to pick up

(that convo can be had on slack, btw, just like standups.)

the problem is "scrum masters" waiting to refine/reject stories during refinement (or not refining at all), or engineers not updating their cards frequently enough, or nobody guarding the backlog and allowing anyone to dump stuff into it. when these things happen, you get three-hour-plus-long sprint planning that wastes everyone's time

the other thing I absolutely hate are capital-r-Retros. retros are supposed to be the meeting that everyone looks forward to, but they often get skipped because it's an hour of people sharing platitudes because the room isn't safe enough to REALLY say what you feel. if i ran retros, they would be at a nearby pub or chill restaurant, over beverages and food, with no real structure other than "at some point we should talk about how this week went."

OMG yes, the retros at my current company are just full of platitudes (and that’s what people look forward to) and I hate it. People do bring up difficult topics but because want to get through every. single. topic. the difficult convos get rescheduled to yetanothermeeting so there’s time to talk about all the positive stuff (which, again are just platitudes, nothing constructive). I tried to change this and got shot down.

Otherwise (and I’m forgetting which thread I’m in here so maybe repeating myself), I have experienced incredibly valuable retros. They were structured but still fun.

And very much agree with the first paragraph. I also agree it could just be done on Slack, but I personally like having a daily meeting where I get to see my team all together… so long as that meeting is short (max 5 mins on a good day).

Genuinely curious about this: is there a specific white paper (or collection) to which you're referring?

I’d have to dig back into the literature, I don’t have anything at hand. Basically for every pro-scrum paper you’ll find a criticism. A few people have done meta analyses and found no benefits. There should be something in IEEE but I’m on a plane right now.

the good thing is that when you see that Scrum process is broken and is not going to improve, that is as clear signal as it can get for a developer to quit to a better place.

That would be my recommendation.