Of course, the counter to that is that we're not doing scrum right. The question in my mind then is if I haven't seen a single team do Scrum correctly there's something wrong that makes the methodology so difficult it can't be applied ...
I'm surprised at the conclusion because this statement can be said of any framework. It's up to the people to actually make it accountable. Doesn't matter if it's Scrum/Kanban or another one. If your org treats accountability as "an illusion" then it's doomed to fail regardless.
> The question in my mind then is if I haven't seen a single team do Scrum correctly there's something wrong that makes the methodology so difficult it can't be applied ...
This I 100% agree with. I've come to look at these frameworks (kanban, scrum etc) as I look at the Bible... no church gets it right and never will. It's not possible.
It's interesting that you use this analogy. I've always compared Scrum to Communism or faith healing: If it doesn't work for you, you either didn't implement it correctly or you didn't believe in it enough.
That was a reply to "...but for many the accountability of Scrum..." in the parent comment. There's an idea that Scrum creates accountability by making it possible to measure how well a team is meeting their commitments. It really doesn't. The metrics that Scrum exposes are little more than semi-random numbers. You're asked as a team to "commit to completing" some mostly arbitrary total of these numbers that has been determined to be your teams "capacity".
The entire premise of this kind of estimation is fallacious on face. It completely ignores the skill level, overall capabilities, and specializations of your developers and effectively equates them to an common minimum of mediocrity. Worse, it pre-supposes that your team fully understands all of the places that a particular task can go sideways which is almost never the case.
About the only way I can see it working is a situation where you know exactly what needs to be done, step by step, from or near the very beginning of a project. Otherwise, all you're doing with Scrum is forcing the team to make decisions on a Sprinted cadence rather than at natural break points along the completion of a project. This creates artificial delays, particularly when other teams are also working on sprinted cadences because you're likely to be requesting things that won't make it into some other teams sprint. Creating at least a sprint long delay before your team can complete their work, and well, breaking your sprint goals, etc..
Sigh ... Hence the accountability and predictability that's supposed to come out of Scrum is illusory at best and usually self deception.
To me, what you're looking for doesn't exist. Ignoring Scrum, the question is "how do we know our engineers are effective?"
You know Scrum's attempt to answer that. Regardless, no matter what methodology you pick - it's bad. But, you have to answer it. Otherwise engineering is a black box without a way to peer in.
I know many engineers would prefer it that way, but that's just not realistic.
In the end the whole thing has to be an agreement between people.
That’s almost always the excuse in my experience. It’s not that it doesn’t work, it’s just no one has ever done it correctly.
In Scrum, estimation meetings usually result in follow-ups with stakeholders that can (and often do) radically change the stories themselves. Totally different code winds up getting delivered that increases actual value delivered, even if "lines of code written" slows.
That's the whole point of agile, to deliver value rather than code.
1. Does the team have the right people, with the right skill sets, wearing the right hats? (e.g. BAs or PMs doing those actual jobs)
2. Does the team have self-motivated, high-performance people?
I have yet to see any process that can overcome "No and no."
Large tech org's knee-jerk response to failures is to increase the formalism of their agile frameworks, but that's just a bandaid over gangrene.
If they think the solution to bad people is more process, they've already lost.
- If you have unpredictably changing requirements, and a small-ish non-life-critical product to build, and a large fraction of good people on the team, you should use an agile process.
- If you have unchanging or predictably changing requirements, and a large fraction of not-so good people on the team, you should use a plan-driven process.
But what if you have unpredictably changing requirements and a large fraction of not-so good people on the team? No process can save you now.
So those skilled and motivated people are estimating piecemeal tickets, too micromanaged to be able to fix actual issues they clearly see around them. It is forced helplessness You can't overcome bad process and scrum is a bad process.
Scrum advocates always end up blaming the people on team. Even if that exact same team was performant and scrum literally killed 70% of what was good in it.
Of course process can't make bad programmers good.
But good process can dramatically improve the value delivered by a team of good programmers. People don't spontaneously self-organize in optimal patterns of internal communication and accountability and external communication, no matter how self-motivated and high-performance they are.
> I have never seen feedback from estimation to requirements.
Perhaps you work with perfect pms! jokes aside, usually all it takes is an estimation of 8 or 13 and something changes real fast.
The entire point of agile is that a PM can't do that. Large estimates force a PM to go back to stakeholders and revise the desired features to something that engineers have consensus that should be deliverable within the next sprint given their historical velocity.
If you're not doing that, then you're not even in any conversation about agile/scrum.
By saying 8pts the team is effectively saying it's probably a 2 sprint job and individual tickets are not supposed to be 2 sprints long meaning there's complexity that either needs to be broken apart or on the rarer case, team agrees the ticket is fine as-is then it'll take 2 sprints.
Anything 13 or greater is saying this ticket is so big we can't even begin to accurately estimate it - PM take it away from us! It's fun to see 21 or 34 pts... it's all a joke at that point.
They're supposed to represent a measure of complexity.
How much time that then takes depends on who does the work, the order in which tickets are implemented, how much distraction there is, luck (do you encounter any unforeseen problems), and so on.
They're then used to see how many issues will fit in a sprint, which is a measure of time. So everybody ends up treating them as representing time anyway...
But in reality it's ideal hours or ideal days.
The 8 and 13 come from the fibonacci sequence.
The meeting-centric focus of dogmatic Scrum team rhythms that attempt to create standardized estimation sizes in order to produce velocity metrics is obscenely slow and a largely a waste of time.
Measuring output metrics at all is worthless. Measuring the impact of delivering working code is all that matters.
As an engineer on a team using scrum, this is my favorite part.
(Many orgs are understandably nervous to automatically report a simple number as an estimate; in those cases, you could translate cycle time into a date range estimate so long as you’re not also expected to report “we’ve started” etc. since those won’t necessarily line up.)
OTOH, nothing stops you from having biweekly reviews with customers in Kanban, or delivery goals on the same cycle that guide decisions of which work items to pull in and whether to allocate more effort or defer ones that run into unexpected complexity. There’s no reason to (and plenty of reason not to) build a work-should-end and then new-work-items-should-start cycle around that; continuous flow makes more sense.
What I am saying is that, insofar as cyclical touch points are a valuable customer-interaction feature of Scrum (and even when doing “proper Agile” with daily interaction with the customer as part of development, which is more an exception than the rule in most “Agile” places I’ve seen, the fact that “the customer” is usually an organization and the ideal daily interaction is individuals at the working level, not whole-team-to-whole-team level, those periodic touchpoints are useful) you can have them in Kanban while maintaining continuous flow as opposed to sprint-oriented flow in the development team.
In the end it's the work of the PM in both cases.
People with enough power in the org will insert their ticket in your precious sprint anyway.
I know, I know, it's just a label applied to the cycle time of the process but labels matter and I think it subtly and subconsciously poisons the whole thing. Especially when managers and PMs start making sprint cycles into hard deadlines.
One of the tipoffs that you are working under fake agile not real agile. I have the same problem with using the word "sprint" as well, but I think the true issue is that most orgs claim to be "agile" when they are actually doing some variety of waterfall with agile verbiage thrown in. The best test for fake agile is if you can't cancel the daily standup, even for a couple of days, via the retro.
The sad truth is that most management teams would prefer their employees to be predictable and observable (ie, under control) than be efficient. Especially if nobody can actually quantitatively measure the loss of efficiency.
Velocity metrics, burndown charts, point estimations, and all of that have been at best aspirational white lies and at worst outright falsehoods on almost every scrum/agile team I've ever worked on in the past fifteen years.
In actuality many scrum teams are doing something closer to kanban day-to-day under the fake veneer of scrum/agile sprints on top to satisfy management and/or external parties.
-"It is impossible to do accurate estimates"
-"You will get better at it"
I wonder if the Scrum Master knew that in the end "get better" is "starting to cheat".
Do anyone else share this experience?
It’s extremely doubtful if you get even a roughly accurate estimate of effort within one project let alone relative effort across two.
Industries and occupations that manage estimates well do so because bulk of the work is repeatable and predictable, and the people doing that work have done nearly identical kind of work before. There is some variability involved, but there's only so much of it, and it yields to tried and true classical project management techniques (not the things that pass as "project management" in software companies).
For example, even an inexperienced carpenter, asked to install a door system they haven't seen before, will be able to do it two or three times to get a feel and work the kinks out, and then when they're hired to install it in 300 flats of a new apartment complex, they'll be able to give you an accurate estimate of time and effort required.
With software, almost universally, your project is meaningfully unique, and your workers have never worked on something very similar before. The sources of variability are endless - project-unique challenges ahead, programmers never doing that particular component in that particular combination of languages, libraries and frameworks, in their specific versions, programmers and PMs never working in that specific domain before, etc. - and that's before you add stakeholders changing their requirements every other week.
The understanding one needs to have first is that the software project they're holding a stake in is typically best thought of as R&D effort.
After all if dev team days that more perspective project is very likely cheaper to make, why would you choose the other one?
See? No need for detailed answers if there is sufficient difference in qualities.
I don't ask contractors for a detailed breakdown, just the whole thing. And they either do a high padded fixed price or work per hour.
A friend who is an elictrician might do 100 similar rooms in a building and they have a detailed breakdown of "time per screw" more or less.
So I guess the accuracy depends on the sameness of tasks to do.
I try to do the same in software projects. Estimating projects by hours is impossible, fibonnaci numbers are a meaningless abstraction, and spending time each sprint to discuss how it went, what the next sprint plan is and estimate every task is a waste of time.
What I can say is whether a task looks like something that could be done in an afternoon, a few days, a few weeks, or multiple months. Accuracy there comes with experience, but no one gets better by chopping the calendar year into 2 week intervals and pouring a ton of process all over it.
Prices in the real world are barely linked to costs. Budget risks are bundled in markets with high variance.
Software developers are not negotiating fixed price contracts with their project managers every two weeks. Just how toxic such a situation would be should be obvious. Managers need to understand the context of the job and determine if they're satisfied with the productivity of their employees.
Agile is a development process not a contract pricing strategy. If anything proponents of "Agile" would be more hesitant to quote you a firm fixed price contract than "Waterfall" teams.
This is not exclusive to scrum.
> the reason given for Scrum being bad is it features estimation
This seems like a strawman and not at all what I was picking up from further up the thread.
---
https://news.ycombinator.com/newsguidelines.html
> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
Software dev can resemble research on a smaller scale. The more interesting or complex your requirements and environment, the closer it resembles research.
The original point of agile was to lean into this fact and get out of planning and predicting. Scrum culture has corrupted this goal.
If you don't report actual time for the task, the excercise is useless.
E.g. shift work time from a slower than estimated task to a faster, or "wait" if the task was done too quickly.
I was a trained Scrum Master and I knew this very well.
Software development is incredibly opaque by default (heck, even we don't know how far along we are, most of the time) so anything that improves that will be perceived as improved productivity.
But even if it's not, sometimes progress reporting (however rough) is needed to synchronise with other parts of the organisation. It just needs to be put into a form that is useful (e.g. for agile projects "percent of plan delivered" is not a useful metric) and how it's going to be used should be explained to those producing it. Heck, optimal is if the people making software and the people they need to coordinate with can get together and jointly agree on what type of reporting is actually meaningful for both parties.
Almost always, we're discussing vanity metrics though.
The trouble is -- as with any product development -- we don't know exactly what we are going to build because it depends on fickle market sentiments, new technology, etc. That is what sets the upper limit on predictability, and that can be controlled by high level decisions. (Unfortunately, increased predictability usually means decreased profitability.)
That's not enough - you can have pretty good predictability if you know exactly what you're going to build, and if you already built the same kind of thing with the same technologies/tools that you're going to use this time. Which is very often not the case: business very often wants new things that others don't already have, or the technologies/tools from previous times are now outdated (or believed so...).
Scrum is based around this idea, so adopting it (or adopting it better) should be a sign they understand it. If they start saying "oh points are basically time" then you're probably in trouble.
A metric compresses a very rich and nuanced opportunity into a false dichotomy.
So even though the current company is using scrum, in my team I treat it as kanban with story point limited, meaning I start with a certain amount of story points, then add / remove as the sprint is going.
If you ask me, that level of predictability is a poor tradeoff, but hey, it's the same kind of organization that decides that SAFe scrum is a serious methodology.
If you do Kanban right you have to have predictability through tasks of roughly equal size. If you will you can think of Kanban as Scrum where all tasks have to either be sized 2 or 3, else they don't make it into a sprint.
New items get added to the end of the backlog by default and stakeholders know when they can expect their request to be done because you know your velocity and queue length.
Putting every single request that comes in at the top of your Kanban backlog is orthogonal and bad.
Planning one that's near to 9-11 work days is the hard part.
And that job takes more than 2 hours. You could also have said "well if that's the case can you poke some exploratory holes in the drywall please so I can get a better estimate" (aka a "spike").
The higher ups do it to follow the process and not to fix the actual problems.
It gets tiring after a while of time wasting.
First few times it works as a psychohygiene, but then it just becomes annoying. So teams stops talking about actual deep issues on those meetings and they are are creating an illusion of happiness.
But I do agree with the post - Kanban is way way better and you can include the scrum continuous improvement elements as well on a regular cycle.
You've already pointed out that this is basically unheard of but I'm struggling to think of situations where scrum metrics have provided benefits that outweighed the cost of taking, and exposing them.
My experience has been that most development teams intuitively recognise problems that might be revealed by these metrics. Is this not often the case?
The thing is with metrics is that they are hard to argue with, whereas intuition is a debatable opinion. Perhaps not everyone in the team agrees. Perhaps it's about showing interfering management or dependent teams where the issues lie. Perhaps the team doesn't realise how long a particular stage in their workflow is holding things up - I mean they know that stage is a problem but have they realised it's actually their biggest blocker to finishing work?
Also depending on what you use to generate metrics - something like ActionableAgile that use Monte Carlo simulations against a few weeks worth of activities can show a team what their cycle time is, what items are in danger of blowing that and how long it's likely to finish just their current backlog (for example).
As you say, in their worst case they tell teams what they already know and then again that's the value of a good SM or AC - finding out why nothing is being done about it (whilst beating away interfering managers).
Agree with everything _expect_ retros.
I think the value of the retros is proportional to how senior the team is and to how seasoned managers are. But for me retros are extremely high value _if_ you have:
- Teams that can look at problems head on and be civil addressing things without making it personal.
- Managers that have a 'clear roadblocks' mindset and have a service-providing mindset towards the team.
In this scenario you can really have high value retros, with continuous adjustments to workflow, processes, design, without continuously repeating the same mistakes or falling in the same pitfalls.
Also, after an initial stabilisation period, teams need fewer and fewer changes. Talking about it every sprint gets really pointless and takes time away from the things they're good at and they're motivated to do.
But I do wonder if it just encourages people not to bring up real problems so that they can skip a meeting.
I think having the board up at all times is a great idea though. Just have to have some way to figure out "is it empty because things are fine or is it empty because no one cares anymore".
I also worked on a team with terrible retros. The "good" column would always be extremely long and was only full of platitudes, nothing of actual substance that was brought forward into the next week. If anything difficult came up, someone would say, "Ok, let's book a meeting to talk about this later". It was an extreme misunderstanding of the value of retros. Though everyone else seemed to enjoy them so that's arguably valuable? I dunno.
Anyway, yes, lots has been said on this topic in the past. SCRUM is just Agile for stakeholders. There is the whole "SCRUM But" joke but I actually think a bunch of things in SCRUM are valuable BUT if something isn't working out, don't do it! I get the impression that lots of companies just do all the rituals "because SCRUM" and don't actually understand why they are doing them. Case in point, I was at a company that would always spend time story-pointing but no one ever looked at them. Not the teams and not the stakeholders.
Yet ironically they care and tout about their ability to measuring efficiency.
An easy way to boost efficiency: hide inefficiency out from view!
we're in this exact phase - sacrificing efficiency, team morale and independence to make the boards look cleaner to "raise the bar" per se.
We're a small efficient team in a massive org. Manager does a great job of not making stupid decisions, values people's time and is clear about the metrics the team gets evaluated on.
somewhere along the way he's, missed the reality that clean user stories and tasks, complete with points down to hours and acceptance criteria can still be completely f$#king wrong compared to the actual work that needs to be done. Not because the people are idiots but because thats how most software work is. You find out when you actually start working on it.
But if you mandate that you need a well cut plan before code gets written, you mostly get well written $hit.
We just embarked on this journey which I can mostly predict the outcome of.
sad, true.
I cannot for the life of me work in the churn and development pace of a Scrum team, so Kanban (and the culture around it) is best fit for me.
I think it also depends upon the type and culture of people working in the team as well. Some teams work really, really well with the predictable cadence, others do not.
It's a case by case kind of situation, I think.
That said I highly prefer Kanban personally for an number of reasons.
We now have long sprints (~1 months) for reviews and retrospectives. Which are usually well received. You get to see what all the other teams have been doing, and you also get a formal chance to talk about any problems.
Timeboxing is about committing only a small amount of time and money at a time, so you can choose to double down on winners and stop investing in losers, rather than suddenly finding yourself having sunk 3 months of time into something that turns out wasn't that good after all.
The question is not "How much can we definitely complete in two weeks?"; it's "What things are promising enough that we are willing to dump two weeks into them, with no promise of ever making a profit?"
If one month counts as a small amount of time and money for your organisation, then you're doing it right!
Software estimation, similarly, is fractal in nature - you can always drill down deeper to measure but it gets increasingly complex and at some point you have to ask, is it worth it being "accurate"? Or do we just do it? Org charts require the former while developers desire the latter.
Unless you wanted to say that the same is true for software estimation, e.g. due to the measurements taking up more and more time.
But maybe instead of infinity, it's better to say estimation can take longer than the work itself which has been the case a few times for me.
I can actually see predictability improving, but mostly because we will ship whatever at the end of the sprint and let any issues come back as bugs later. We always ship on time at one Scrum job, but the quality is very low.
However, Scrum doesn't make much sense if you don't continuously iterate. Another symptom of this is people measuring velocity instead of value created. To properly implement Scrum, you actually need to measure the impact of the work completed in the past two weeks. Unfortunately, most teams don't do this, instead they focus on measuring velocity since it's easier and within their control. It's worth noting that it's completely fine for teams not to constantly iterate and change direction (including high-performing teams), and in those cases, Scrum simply isn't the best tool for the job imo.
I must admit that I personally prefer Kanban for almost all workloads.
Lots of stuff pushes organizations in the direction of doing 80% of 10 separate projects, and it's a killer. This is good reading in this domain: https://apenwarr.ca/log/20171213
Alignment is so important, and it's rare that I've found a team not using scrum which is working harmoniously. In reality, some members of the team aren't pulling their weight and it's causing animosity. Or they're working at odds and not communicating the pieces they're developing. A huge one for me is stakeholder alignment. Without scrum it's awfully common for developers to build things the stakeholder doesn't want. Scrum forces regular check-in and demonstration which otherwise rarely happens organically.
A big part of scrum is accountability. As I touched on, when people aren't pulling their weight, it hurts everyone. Unfortunately developers are rarely extroverts, and they often don't have the skills or desire to have tough conversations with each other. Sometimes it's just agreeing on what they find acceptable behaviour and work. Sometimes it's adapting to different ways of work, or neurological issues with a team member. You might be surprised to learn that a lot of developers are on the spectrum. Scrum forces these conversations to the fore and provides a tested framework for conflict resolution.
We also gain transparency. This is really important so that all the other supporting business functions can operate. Sales can communicate with customers about important updates and new features. Marketing can plan campaigns. Support can prepare. Finance can ensure adequate budget for new infrastructure and FTEs. Sure it's annoying, but this planning is essential for a business. It just doesn't happen organically. Scrum forces developers to work to some kind of schedule, offering short-term (but flexible) estimates on what can be delivered, when.
In a perfect world, none of this is a problem, and all of it happens organically. I've just never seen that happen. The sacrifice in velocity is worth the increase in value output to the stakeholders.
That’s not how it works. It’s as though developers are dumb and can only execute if you tell them to do exactly as needed. Rather where’s the leadership and direction? Perhaps that’s not clear or the developers don’t even agree with what’s going on. You statement is so 1-sided.
If someone is not performing you shouldn’t need scrum to work that out otherwise you have bigger problems.
I’d argue alignment is useless as most of the time developers are told to implement useless features. Perhaps with some guidance and direction what the developers come up with is better than product.
It’s sad but product is like a theory machine that’s often impractical.
So what would you prefer? Developers without scrum delivering in 4 months or with scrum and taking a year? Even if they do go off for a few months on their own it’s more than worth it.
The problems aren’t accountability or alignment. If people aren’t following a plan, that is if there is 1 then it’s a leadership problem.
> Rather where’s the leadership and direction?
We're right here, implementing scrum for the reasons I listed.
> If someone is not performing you shouldn’t need scrum to work that out otherwise you have bigger problems.
I have found that poor performance is often not because an employee is "bad." It's because the team dynamic is not working. Maybe their skills are poorly utilised. Maybe the team isn't make accommodations for their neurodivergence. Maybe they don't understand how to integrate well into the team. Maybe they don't feel confident to bother the senior devs, and maybe the senior devs have told them to fuck off. I've seen all of this and more.
> I’d argue alignment is useless as most of the time developers are told to implement useless features.
Sure, there's no point in any of the work you do if you're being told to develop things that no one wants. My baseline assumption here is that the business has need of your work. If it doesn't, you should brush up no your CV.
> So what would you prefer? Developers without scrum delivering in 4 months or with scrum and taking a year?
If the four months gives me something no one wants, I'll take the year.
> The problems aren’t accountability or alignment. If people aren’t following a plan, that is if there is 1 then it’s a leadership problem.
That's the whole discussion: how best to follow the plan. I don't think it's as easy as criticising developers for "not following the plan" if we don't provide a strong foundation in which to do so. Cue scrum.
That's the problem. That's not how it used to work and we've lost that. Developers are a lot more than develop. If you really think you need to pay someone 200-500k in better places to just "develop"; there's the problem.
Software exceeded because developers innovated and did a lot more than that. Shrinking them to just robots is where the problem starts and you can hire copy/paste "developers" for a lot less.
> I have found that poor performance is often not because an employee is "bad."
My point being and as you've actually explained - it still has nothing to do with scrum.
> Sure, there's no point in any of the work you do if you're being told to develop things that no one wants. My baseline assumption here is that the business has need of your work. If it doesn't, you should brush up no your CV.
The business has need for work - it doesn't make it a useful feature. What the client wants and what gets trickled down after 10 layers is a different story.
> If the four months gives me something no one wants, I'll take the year.
How do you keep concluding no 1 wants it?
> That's the whole discussion: how best to follow the plan. I don't think it's as easy as criticising developers for "not following the plan" if we don't provide a strong foundation in which to do so. Cue scrum.
Point being scrum doesn't provide this foundation. Read the comments. You lose long term planning and try to squeeze everything in 2 week compartments = find quick wins and hack everything so it fits. It's a disaster. What happens as other have explained is the estimates get padded. People do less work. People are unhappy and you're just left with the illusion of "success".
US and in particular SF didn't succeed on this but on elevating developers to innovate. Please don't kill it.
> Unfortunately developers are rarely extroverts, and they often don't have the skills or desire to have tough conversations with each other.
I mean, what are you exactly talking about here? Because developers do criticize each other all the time, both in code review and outside of it. If they have trust, they talk plenty. If you do not see developers communicating, it is because of how you lead a process.
> Sometimes it's adapting to different ways of work, or neurological issues with a team member
Scrum is so inflexible, that it literally prevents accommodations for issues like this. And that is not even speaking about the fact literally this should be job of people management. This is literally what leaderships should do, because they have actual power to change the things.
It's not just communication which is needed. It's effective communication. For example, criticism without structure and consideration comes across as unkind and destructive. This is the piece which I rarely see working well without a framework. It doesn't have to be scrum. I just see scrum solving this and many other problems really well.
> Scrum is so inflexible, that it literally prevents accommodations for issues like this. And that is not even speaking about the fact literally this should be job of people management. This is literally what leaderships should do, because they have actual power to change the things.
Scrum doesn't have to be inflexible. It should be tailored to the needs of the team. The catch is that changes should be agreed by all, rather than one member going rogue. "Rockstars" hate scrum.
As for the "job of people management," if you're punting the responsibility of collaborative team dynamic to your leaders, be prepared for them to lead you. With scrum.
Scrum does not help with effective communication at all. Its only tools for feedback are code review and retrospective. Its tools for teaching are code review, demos and planning sessions. There is literally no place in it for private feedback or some kind of learning plan or a weaker developer having tasks adjusted so that he can catch up (getting simpler ones, or only frontend ones till he learns that), literally nothing. And with public feedback, it provides zero guidance on how to do it anyway.
Instead, scrum prevents effective, safe and compassionate communication. It provides rituals, that is it.
> The catch is that changes should be agreed by all, rather than one member going rogue. "Rockstars" hate scrum.
Neither of these is true. Scrum is inflexible and the moment you change the process, you are not doing scrum and you will be forced to go back to scrum. Second, you will need to specify what you mean by rock starts. If you mean toxic personalities, they do well in scrum. If you like to control other people, scrum provides quite a lot of opportunity for that.
What it does not provide is opportunity of people to use full extend of their capabilities. People who are able to perform well and able to get along with others, you will definitely do better in processes that allows you to perform and get along with others. If rocks start here means a positive, a capable non toxic person with good social skills, yeah, those tend not to like scrum.
Sure, scrum is a team tool, not a personal development plan tool. The latter is best handled with one's manager. Note that I am not claiming scrum is an everything tool. It won't solve world hunger either. How on earth does scrum "prevent effective, safe, and compassionate communication"?? It just sounds like you're throwing accusations at the wall now to see what sticks.
It sounds like we've had vastly different experiences. I'm sorry to hear yours have been so unpleasant.
When I said that developers do tough part regularly in code reviews, you said that effective communication is more and scrum provides that more
When I said that scrum does not provide it and makes it harder, you said that scrum actually should not do any of that, manager should. And oh, scrum has scrum master and no manager, so no I guess no one is doing it.
This has been my experience. I've seen more than once management teams happier with numbers and estimates that weren't met than actually getting software out quicker at an unanticipated rate.
They'd rather have estimates that they could yell about than revenue generating software through (presumably) happy customers. <shrug>
Every team that I've worked on that has switched from Scrum to Kanban saw an immediate improvement in speed that never disappeared.
Once, just once, I was lucky enough to work on a team that switched from Kanban to Scrum, and then, mercifully, blissfully, back again. To be fair, I think we actually worked quicker after the return, though I don't know if that could be attributed to having actually learned some lessons from Scrum, or out of a fear that we'd one day return to it.