6 ms·

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 im

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.

re-thc 3y ago
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.
- Gareth321 3y ago
  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.
  - re-thc 3y ago
    > 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.
jaybrendansmith 3y ago
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.
watwut 3y ago
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.
- Gareth321 3y ago
  > 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.
  - watwut 3y ago

re-thc 3y ago

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.

Gareth321 3y ago
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.
- re-thc 3y ago
  > 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.

jaybrendansmith 3y ago

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.

watwut 3y ago

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.

Gareth321 3y ago
> 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.
- watwut 3y ago