As a Product Owner I am biased, but sympathetic. The ceremonies and oversight certainly can slow down velocity. But there are many benefits, and they are not immediately apparent to developers.
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.
You make it all sound like a factory and blame developers for going rogue.
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.
It's not about blame. Developers are paid to develop. They're not paid to care about the interlocking parts, so many of them don't. It's not an indictment. It's just what it is. They have a different set of skills.
> 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.
> It's not about blame. Developers are paid to develop. They're not paid to care about the interlocking parts, so many of them don't. It's not an indictment. It's just what it is. They have a different set of skills.
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.
Franky, scrum teams I worked in were pretty much worst in all the points you list, except higher management feeling of control. Especially in alignment between developers point. The cooperation is never really good in scrum, it is sorta kinda passable at best. Interpersonal relationship are either horrible or passive to non existence.
> 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.
> I mean, what are you exactly talking about here? Because developers do criticise 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.
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.
> 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 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.
> 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... Instead, scrum prevents effective, safe and compassionate communication. It provides rituals, that is it.
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.
You started by saying that scrum helps team alignment, communication and dealing with weaker developers. That introverted developers need something like that to communicate, because they are avoiding tough discussions. You was literally talking about developers.
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 "the more" 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.
-------
In a non scrum process, seniors do frequently take actively care about Juniors or own development. They can do it in systematic manner. They can actually work together on a lighly larger units of work with them. They can split work in a way that makes sense between the actual two people in question rather then based on what someone else prescribed.
Great comment. If you are enforcing due dates, you are doing it wrong, and stacking up debt and creating bad quality. It's about transparency. As a developer I never loved transparency, because being imperfect, I would sometimes make mistakes. As a manager, I cannot see how anything can be done correctly without transparency. It's not about the developer, it's about the quality analyst, the dev/ops, the UX designer, the customer, the documentation, the salesperson, the stakeholder, the investor, the business analyst, the quality analyst, the configuration analyst, etc.
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.