6 ms·

I find this article lacking, because it makes all of the same mistakes typical of these bandwagon anti-Scrum articles. Despite working in a a Scrum team, I rec

I find this article lacking, because it makes all of the same mistakes typical of these bandwagon anti-Scrum articles. Despite working in a a Scrum team, I recognise literally nothing of the problems that are described. Our product owner works closely with both commercial and development groups to build the backlog. Pressure to build good technical solutions is reasonably balanced with commercial requirements. The development team is empowered to step in and request product changes when they think it's necessary. This happens because we are a team of skilled professionals who want to deliver working things at reasonable pace, and this applies to both commercial and development groups. There is a weird underlying assumption in these kinds of articles that implicitly seems to assume that Scrum will somehow turn a bad team into a good one. I have no idea where that comes from. A team using Scrum still needs skilled people who know how to do their jobs effectively – and that includes the scrum master and product owner roles. Introducing it into a good team can then help to reduce the impact of common software development issues. It doesn't work for every company, team, or product – but that doesn't mean its without value. I'd be more interested in articles that talked a little about better processes that we can use. I'm absolutely open-minded about the idea that there are other legitimate and effective ways to deliver software other than Scrum, because it's obviously the case. "These are the problems with Scrum and this is why they aren't a problem in <other process>" is more valuable than "If you have a bad team then Scrum is bad".

conatus 8y ago
> Despite working in a a Scrum team, I recognise literally nothing of the problems that are described. Same. This process takes work, requires buy in by all levels of the company and needs to be fully understood including its error cases. It takes time and requires course correct and attention. Its not easy but done right it is effective.
- yebyen 8y ago
  > done right it is effective. That is one of the problems highlighted in the article though, too. What is the appropriate level of training for a scrum master and scrum team? Should we read the Scrum Guide? Are we reading the Scrum Guide? Do we actually know what Scrum is? Do we even know that we are doing Scrum? I am working on a young, small team, and we started with an expertly trained scrum-master about 30 sprints ago. She was so well-trained that she was promoted out of our team. Since we started, we've had about 72% turnover. I'm the only original member of the team who is still on full-time except for the product owner... and reading this article, I am coming to find out that our product owner is not doing the job of product owner (mostly our new project manager is.) And > apparently it has to involve something called “Jira”. hits me right in the feels! We have been working with one project management tool (not Jira) since the beginning, and we found another tool that we like (the dev team likes) better. Doesn't matter what the tools are. Bear with me. The first tool is used to communicate with our product owner(s) or stakeholders, where we get their acceptance of stories, and the second tool was meant to be a place where we developers can own tasks and "blog" about our progress without adding noise to the stakeholder channels. A task list that we control. Again, neither tool is Jira. We did a trial, and we quickly found by consensus of opinion and observation that it really helped us a lot to add this tool to our process, all of the developers were buying in! Brought it to management to get it added in the budget... really a nominal sum, but then we were told we had too many tools already and made to abort the trial. I was devastated, but I played along. It was the wrong decision! I started using slips of paper to fill the void, a place where development issues that are not part of our product backlog can live outside of the backlog and the sprint, and now in my perception at least, we're more disorganized than ever as a team. I believe you both, that Scrum can work well if done right, and I'm glad it's working well for you, but ... I think at least some of us definitely need to hear these stories, many of them are our own stories, properly articulated so we can understand what's going wrong in our teams.
  - alistairSH 8y ago
    With turn-over like that, nobody is going to be successful. What is driving the turn-over? Are team-members being moved elsewhere, or are the quitting out of frustration? As for training for the SM (or PO, or anybody else), it's a continuous process. The CSM is a starting point, a basic level of understanding. At my office, many of us have gone on to take the Advanced CSM course. Most of us attend meet-ups, conferences, etc. It's not a once-and-done thing - nothing in a professional career ever is - if you aren't learning and improving every day, you're not doing your job.
    - yebyen 8y ago
      > What is driving the turn-over? Are team-members being moved elsewhere "72%" is really misleading... from the original team of 2 developers and one PM/Scrum-Master, the Scrum-Master was promoted to a newly formed team, and the other developer is still with us, but in a mostly consulting-only capacity, as she is focused on other projects in our team. Nobody is quitting out of frustration. (Not yet anyway!) We've since added two new developers from other groups within our organization, and a new PM. We're talking about a greenfield project with some inherited/appropriated/shared code from other projects on our (slightly larger) team, a mostly new dev effort, and we're approaching year 3 of development. For a dev team this small and a project of this scope and duration, I feel like this is almost an appropriate level of turnover. We have to strike a balance between spreading the domain knowledge around, and keeping the expertise near the "most important project," which is obviously the particular one that we're working on. (/s) The big problem is training, or lack of... the SM that left our team was practically the only one of us with any formal training in terms of either development skills or Project Management. The rest of us have learned basically everything "on the job." We've been exposed to some training opportunities for "business analyst" skills development, which is our organization's take on a little bit like "Scrum-lite" but I am not sure that's for all of us. (I'm working in higher-ed so there are a lot of training opportunities in-house. Just not sure they are the right ones. Most teams in our building just aren't doing product development, so we are special snowflakes.) I've taken some of those BA classes. We really need more technical training. We probably need a larger team too, but hiring is very difficult for us, and in reality I think we're going to have to cope with more of our team members being poached by other departments as we become more successful. Some members of the team have participated in bootcamp-style training courses for our chosen framework. In every case, it was years ago, some time before I arrived on the scene. I have not had any of this, just some prior on-the-job experience and also have read a book or two to pull myself up by bootstraps! We're all learning on the job, and we have a conference budget so we're getting exposed to plenty of new ideas each year, but that's nothing like a formal training day where we all hammer a particular skill until we all get it, or even a sprint that's dedicated for training. Second major problem is that we also usually don't have sprints or stories devoted to addressing technical debt. No refactor stories, basically ever. Basically all story cards must be customer-facing and represent some new, testable functionality for some functional user of the product. This part of the article also struck me as poignant: > The items promoted in the backlog, combined with the schedule pressure set by the product owner and the business mean that the Development Team often are told how to create releases: quickly and exactly how we said. The lack of technical craft or development control means each sprint is launched as soon as possible rather than as soon as prudent, refactoring isn't done, and technical debt builds up, eventually choking the product. When every story is a feature story or bugfix, this is what you get. When the team says "we need to learn this skill first, so we don't add unnecessary technical debt in the next sprint" and are overridden by the PM's boss and told to stick to the planned release timeline at all costs, we lose. > As mentioned above, the lack of titles or specific responsibilities in the development team means no-one is empowered to advocate for development priorities, and also contradicts the typical implementation where there certainly are titles and hierarchies within teams ... exactly this. We're told that the development team as a whole is accountable for progress, but when everyone is responsible, nobody is. You can't call someone a technical lead and then confine their decision-making to minutia within the already-planned sprint work. That's not really how I feel about my team, but I feel like sometimes circumstances put the pressure in that direction. This is getting too personal, but suffice it to say I really agree with this article about a lot of points.
Robin_Message 8y ago
> A team using Scrum still needs skilled people who know how to do their jobs effectively – and that includes the scrum master and product owner roles. That is my key beef with Scrum here. I entirely agree that done well Scrum can be effective. But how it is often done is not well at all (e.g. the two day Scrum master training course.) I'm criticising Scrum as it's widely implemented and how that is poisoning the groundwater for all agile methodologies. And definitely I'll get on to how other processes can be better.
nickelcitymario 8y ago
> There is a weird underlying assumption in these kinds of articles that implicitly seems to assume that Scrum will somehow turn a bad team into a good one. This assumption starts with one of the earliest Scrum pioneers, Jeff Sutherland. He writes quite clearly that he doesn't care about an individual's performance, but rather a team's performance. He also talks at length about how poor performing teams can be turned into high performing ones by the implementation of Scrum. You can agree or disagree with him on this (I'm on the fence), but it's not at all weird that this idea is found within Scrum. It was there from the get go. It's there by design.
- srtjstjsj 8y ago
  You are misinterpreting. Scrum is designed to cure disfunctions that turn good developers into bad teams.
barrkel 8y ago
I recognize the disfunction. What happens is that the owner of the backlog becomes the controller of how much time gets spent on what. With feature pressure, it's all new features all the time, with no scope to address debt.
- alistairSH 8y ago
  IMO, this is where a good leader (SM, tech lead, whoever - I don't mean a literal manager) advocates for sanity on behalf of the rest of the team. Mostly, this just requires somebody to say "No." every so often in the face of ridiculous demands. As SM, it's my job to ensure that not only will the PO listen to concerns from the team, but the team feels empowered to provide that criticism. If neither of those happens, I've failed. A bad PO will RUIN a team. I've seen them do just what the blog entry claims. I've also worked with POs who don't do any of the bad things claimed.
  - Cthulhu_ 8y ago
    This is correct. The article (and grandparent) seems to quickly jump to the assumption that the members of a scrum team are mindless drones - and don't get me wrong, some scrum teams are - but they are empowered by scrum itself to have a say or two itself in what to deliver when. The PO only decides priorities, and is not (officially) allowed to pressure for time and deadlines. In return, the scrum team gives feedback in the sprint ritual about how fast they're going, relatively, in story points delivered. This is only relative to that team's own (previous) sprints. I think the main issue is that people are doing scrum wrong, applying traditional management to an agile process.
    - dgreensp 8y ago
      Does Scrum itself empower individual members of the development team? Saying it’s on the developers not to be “mindless drones” and the managers to not be “bad managers” may be true but doesn’t really refute the article’s point. Maybe you have Scrum disempowering developers and (at the best companies) other forces, including other practices and processes, empowering them. For example, Scrum says responsibility for operations and testing are to be shared responsibilities; you don’t have an ops team or a testing team, or titles, or recognized responsibility. You might have a de facto ops team, but those are just some individuals who have chosen to carry pagers right now. I’ve seen things like this play out and been puzzled by it. I didn’t actually realize until reading this article that people have been giving talks and writing books saying that “subteams” are bad, but it makes sense now. The point being, not having officially recognized responsibilities is a form of disempowerment.
specialist 8y ago
To hear about better processes, you'd have to time travel back to the 90s, go thru PMI training, work with experienced project managers, earn your sergeant stripes.
tannhaeuser 8y ago
No, it's the other way around: those arguing against SCRUM don't have to tell their reasons (bad experience suffices), but SCRUM proponents must come forward with logically sound and coherent arguments pro-SCRUM in the first place.
- mlthoughts2018 8y ago
  For something that prescribes how to do everything, like Scrum does (e.g. you need all these meetings, this person does X, this person does Y, teams have to be cross-functional, no specialists, etc.) I think it's more than fair that the burden of proof lies with the proponents of that methodology. Another way of putting it is that there are many good ways of doing project management, as many good ways as their are unique (team, circumstance) pairs. Most people have an intuitive understanding of why some very low-overhead, low-formalism, "just get stuff done and be reasonable" workflow has worked really well in some specific (team, circumstance) combo situation. If you want them to override their experiences with how those ad hoc, customized management processes worked well, and instead believe that a company-wide, one-size-fits-all approach that removes tons of workflow autonomy that could just be left up to separate teams to customize for themselves, then you absolutely have to have extremely convincing answers to address widespread bad experiences.
- srtjstjsj 8y ago
  What if scrum proponents are busy having successful experiences, but are open to an argument convincing them that they are not?
dgreensp 8y ago
Having worked at primarily at “informally agile” software companies in Silicon Valley (and I count Google as one), I see an important bit of truth in the article that Scrum ideas have become the embodiment of agile, and ideas from Scrum that may not make sense in isolation have become standard practice in software development and are somehow seen as the alternative to “waterfall” development, even if they have nothing inherently to do with waterfall vs agile development. For example, it’s never made sense to me to have a powerful product owner while treating the development team as N interchangeable workers who may have “areas of focus” but have no roles, responsibilities, or organization among themselves, smearing out any sort of power or responsibility for technical quality like butter spread on toast. And yet, the fact that Scrum says to do it makes me wonder if that’s why everyone does it. Reading Scrum’s idea of a development team made me facepalm. I don’t think the article is attacking a straw man that Scrum can turn a bad team into a good one. It may be pointing out that Scrum is regularly used to turn a good team into a bad one. Because everyone wants to be “agile,” even if they never use the word Scrum, they are implementing bad Scrum or cargo-cult Scrum by default.
- srtjstjsj 8y ago
  Where has management forced Scrum onto a team that was already successful?
  - Clubber 8y ago
    Every company I've ever worked at. It's how Bozo managers get points from their Bozo managers. "I can save you a lot of money by converting to Agile / Scrum." What it really means is, "I'm not really responsible for making deadlines anymore."
s73v3r_ 8y ago
I think very, very few articles actually want to touch on the reason that Agile/Scrum goes bad: Lack of management/client buy in. If management or the client aren't going to work in an agile manner as well, then that just puts the devs at a disadvantage, and makes for a crappy work environment. Devs lose any agency they had in terms of what to work on, and as a result become disgruntled and stop caring about the work.
TooBrokeToBeg 8y ago
My initial thoughts...of course Scrum disempowers developers but that's not what the article is about. I see a hyperbolic title and a bunch of complaints about how "in the real world" things work differently (entrenched opposition will always sabotage progress). What is a manager but someone who has control over the controlled? I'm surprised with so many ppl nodding their head at this list of complaints about bad software processes at bad companies, masquerading as analysis. If you think it takes more than 2 days to learn _how_ to be a Scrum master, you don't understand the role. It's not complicated, difficult, and time-consuming enough to require a singular employee...unless your process is already screwed up. Good luck finding whatever magic bullet you think will save you that isn't Scrum-based teams.

conatus 8y ago

> Despite working in a a Scrum team, I recognise literally nothing of the problems that are described. Same. This process takes work, requires buy in by all levels of the company and needs to be fully understood including its error cases. It takes time and requires course correct and attention. Its not easy but done right it is effective.

yebyen 8y ago
> done right it is effective. That is one of the problems highlighted in the article though, too. What is the appropriate level of training for a scrum master and scrum team? Should we read the Scrum Guide? Are we reading the Scrum Guide? Do we actually know what Scrum is? Do we even know that we are doing Scrum? I am working on a young, small team, and we started with an expertly trained scrum-master about 30 sprints ago. She was so well-trained that she was promoted out of our team. Since we started, we've had about 72% turnover. I'm the only original member of the team who is still on full-time except for the product owner... and reading this article, I am coming to find out that our product owner is not doing the job of product owner (mostly our new project manager is.) And > apparently it has to involve something called “Jira”. hits me right in the feels! We have been working with one project management tool (not Jira) since the beginning, and we found another tool that we like (the dev team likes) better. Doesn't matter what the tools are. Bear with me. The first tool is used to communicate with our product owner(s) or stakeholders, where we get their acceptance of stories, and the second tool was meant to be a place where we developers can own tasks and "blog" about our progress without adding noise to the stakeholder channels. A task list that we control. Again, neither tool is Jira. We did a trial, and we quickly found by consensus of opinion and observation that it really helped us a lot to add this tool to our process, all of the developers were buying in! Brought it to management to get it added in the budget... really a nominal sum, but then we were told we had too many tools already and made to abort the trial. I was devastated, but I played along. It was the wrong decision! I started using slips of paper to fill the void, a place where development issues that are not part of our product backlog can live outside of the backlog and the sprint, and now in my perception at least, we're more disorganized than ever as a team. I believe you both, that Scrum can work well if done right, and I'm glad it's working well for you, but ... I think at least some of us definitely need to hear these stories, many of them are our own stories, properly articulated so we can understand what's going wrong in our teams.
- alistairSH 8y ago
  With turn-over like that, nobody is going to be successful. What is driving the turn-over? Are team-members being moved elsewhere, or are the quitting out of frustration? As for training for the SM (or PO, or anybody else), it's a continuous process. The CSM is a starting point, a basic level of understanding. At my office, many of us have gone on to take the Advanced CSM course. Most of us attend meet-ups, conferences, etc. It's not a once-and-done thing - nothing in a professional career ever is - if you aren't learning and improving every day, you're not doing your job.
  - yebyen 8y ago
    > What is driving the turn-over? Are team-members being moved elsewhere "72%" is really misleading... from the original team of 2 developers and one PM/Scrum-Master, the Scrum-Master was promoted to a newly formed team, and the other developer is still with us, but in a mostly consulting-only capacity, as she is focused on other projects in our team. Nobody is quitting out of frustration. (Not yet anyway!) We've since added two new developers from other groups within our organization, and a new PM. We're talking about a greenfield project with some inherited/appropriated/shared code from other projects on our (slightly larger) team, a mostly new dev effort, and we're approaching year 3 of development. For a dev team this small and a project of this scope and duration, I feel like this is almost an appropriate level of turnover. We have to strike a balance between spreading the domain knowledge around, and keeping the expertise near the "most important project," which is obviously the particular one that we're working on. (/s) The big problem is training, or lack of... the SM that left our team was practically the only one of us with any formal training in terms of either development skills or Project Management. The rest of us have learned basically everything "on the job." We've been exposed to some training opportunities for "business analyst" skills development, which is our organization's take on a little bit like "Scrum-lite" but I am not sure that's for all of us. (I'm working in higher-ed so there are a lot of training opportunities in-house. Just not sure they are the right ones. Most teams in our building just aren't doing product development, so we are special snowflakes.) I've taken some of those BA classes. We really need more technical training. We probably need a larger team too, but hiring is very difficult for us, and in reality I think we're going to have to cope with more of our team members being poached by other departments as we become more successful. Some members of the team have participated in bootcamp-style training courses for our chosen framework. In every case, it was years ago, some time before I arrived on the scene. I have not had any of this, just some prior on-the-job experience and also have read a book or two to pull myself up by bootstraps! We're all learning on the job, and we have a conference budget so we're getting exposed to plenty of new ideas each year, but that's nothing like a formal training day where we all hammer a particular skill until we all get it, or even a sprint that's dedicated for training. Second major problem is that we also usually don't have sprints or stories devoted to addressing technical debt. No refactor stories, basically ever. Basically all story cards must be customer-facing and represent some new, testable functionality for some functional user of the product. This part of the article also struck me as poignant: > The items promoted in the backlog, combined with the schedule pressure set by the product owner and the business mean that the Development Team often are told how to create releases: quickly and exactly how we said. The lack of technical craft or development control means each sprint is launched as soon as possible rather than as soon as prudent, refactoring isn't done, and technical debt builds up, eventually choking the product. When every story is a feature story or bugfix, this is what you get. When the team says "we need to learn this skill first, so we don't add unnecessary technical debt in the next sprint" and are overridden by the PM's boss and told to stick to the planned release timeline at all costs, we lose. > As mentioned above, the lack of titles or specific responsibilities in the development team means no-one is empowered to advocate for development priorities, and also contradicts the typical implementation where there certainly are titles and hierarchies within teams ... exactly this. We're told that the development team as a whole is accountable for progress, but when everyone is responsible, nobody is. You can't call someone a technical lead and then confine their decision-making to minutia within the already-planned sprint work. That's not really how I feel about my team, but I feel like sometimes circumstances put the pressure in that direction. This is getting too personal, but suffice it to say I really agree with this article about a lot of points.

Robin_Message 8y ago

> A team using Scrum still needs skilled people who know how to do their jobs effectively – and that includes the scrum master and product owner roles. That is my key beef with Scrum here. I entirely agree that done well Scrum can be effective. But how it is often done is not well at all (e.g. the two day Scrum master training course.) I'm criticising Scrum as it's widely implemented and how that is poisoning the groundwater for all agile methodologies. And definitely I'll get on to how other processes can be better.

nickelcitymario 8y ago

> There is a weird underlying assumption in these kinds of articles that implicitly seems to assume that Scrum will somehow turn a bad team into a good one. This assumption starts with one of the earliest Scrum pioneers, Jeff Sutherland. He writes quite clearly that he doesn't care about an individual's performance, but rather a team's performance. He also talks at length about how poor performing teams can be turned into high performing ones by the implementation of Scrum. You can agree or disagree with him on this (I'm on the fence), but it's not at all weird that this idea is found within Scrum. It was there from the get go. It's there by design.

srtjstjsj 8y ago
You are misinterpreting. Scrum is designed to cure disfunctions that turn good developers into bad teams.

barrkel 8y ago

I recognize the disfunction. What happens is that the owner of the backlog becomes the controller of how much time gets spent on what. With feature pressure, it's all new features all the time, with no scope to address debt.

alistairSH 8y ago
IMO, this is where a good leader (SM, tech lead, whoever - I don't mean a literal manager) advocates for sanity on behalf of the rest of the team. Mostly, this just requires somebody to say "No." every so often in the face of ridiculous demands. As SM, it's my job to ensure that not only will the PO listen to concerns from the team, but the team feels empowered to provide that criticism. If neither of those happens, I've failed. A bad PO will RUIN a team. I've seen them do just what the blog entry claims. I've also worked with POs who don't do any of the bad things claimed.
- Cthulhu_ 8y ago
  This is correct. The article (and grandparent) seems to quickly jump to the assumption that the members of a scrum team are mindless drones - and don't get me wrong, some scrum teams are - but they are empowered by scrum itself to have a say or two itself in what to deliver when. The PO only decides priorities, and is not (officially) allowed to pressure for time and deadlines. In return, the scrum team gives feedback in the sprint ritual about how fast they're going, relatively, in story points delivered. This is only relative to that team's own (previous) sprints. I think the main issue is that people are doing scrum wrong, applying traditional management to an agile process.
  - dgreensp 8y ago
    Does Scrum itself empower individual members of the development team? Saying it’s on the developers not to be “mindless drones” and the managers to not be “bad managers” may be true but doesn’t really refute the article’s point. Maybe you have Scrum disempowering developers and (at the best companies) other forces, including other practices and processes, empowering them. For example, Scrum says responsibility for operations and testing are to be shared responsibilities; you don’t have an ops team or a testing team, or titles, or recognized responsibility. You might have a de facto ops team, but those are just some individuals who have chosen to carry pagers right now. I’ve seen things like this play out and been puzzled by it. I didn’t actually realize until reading this article that people have been giving talks and writing books saying that “subteams” are bad, but it makes sense now. The point being, not having officially recognized responsibilities is a form of disempowerment.

specialist 8y ago

To hear about better processes, you'd have to time travel back to the 90s, go thru PMI training, work with experienced project managers, earn your sergeant stripes.

tannhaeuser 8y ago

No, it's the other way around: those arguing against SCRUM don't have to tell their reasons (bad experience suffices), but SCRUM proponents must come forward with logically sound and coherent arguments pro-SCRUM in the first place.

mlthoughts2018 8y ago
For something that prescribes how to do everything, like Scrum does (e.g. you need all these meetings, this person does X, this person does Y, teams have to be cross-functional, no specialists, etc.) I think it's more than fair that the burden of proof lies with the proponents of that methodology. Another way of putting it is that there are many good ways of doing project management, as many good ways as their are unique (team, circumstance) pairs. Most people have an intuitive understanding of why some very low-overhead, low-formalism, "just get stuff done and be reasonable" workflow has worked really well in some specific (team, circumstance) combo situation. If you want them to override their experiences with how those ad hoc, customized management processes worked well, and instead believe that a company-wide, one-size-fits-all approach that removes tons of workflow autonomy that could just be left up to separate teams to customize for themselves, then you absolutely have to have extremely convincing answers to address widespread bad experiences.
srtjstjsj 8y ago
What if scrum proponents are busy having successful experiences, but are open to an argument convincing them that they are not?

dgreensp 8y ago

Having worked at primarily at “informally agile” software companies in Silicon Valley (and I count Google as one), I see an important bit of truth in the article that Scrum ideas have become the embodiment of agile, and ideas from Scrum that may not make sense in isolation have become standard practice in software development and are somehow seen as the alternative to “waterfall” development, even if they have nothing inherently to do with waterfall vs agile development. For example, it’s never made sense to me to have a powerful product owner while treating the development team as N interchangeable workers who may have “areas of focus” but have no roles, responsibilities, or organization among themselves, smearing out any sort of power or responsibility for technical quality like butter spread on toast. And yet, the fact that Scrum says to do it makes me wonder if that’s why everyone does it. Reading Scrum’s idea of a development team made me facepalm. I don’t think the article is attacking a straw man that Scrum can turn a bad team into a good one. It may be pointing out that Scrum is regularly used to turn a good team into a bad one. Because everyone wants to be “agile,” even if they never use the word Scrum, they are implementing bad Scrum or cargo-cult Scrum by default.

srtjstjsj 8y ago
Where has management forced Scrum onto a team that was already successful?
- Clubber 8y ago
  Every company I've ever worked at. It's how Bozo managers get points from their Bozo managers. "I can save you a lot of money by converting to Agile / Scrum." What it really means is, "I'm not really responsible for making deadlines anymore."

s73v3r_ 8y ago

I think very, very few articles actually want to touch on the reason that Agile/Scrum goes bad: Lack of management/client buy in. If management or the client aren't going to work in an agile manner as well, then that just puts the devs at a disadvantage, and makes for a crappy work environment. Devs lose any agency they had in terms of what to work on, and as a result become disgruntled and stop caring about the work.

TooBrokeToBeg 8y ago

My initial thoughts...of course Scrum disempowers developers but that's not what the article is about. I see a hyperbolic title and a bunch of complaints about how "in the real world" things work differently (entrenched opposition will always sabotage progress). What is a manager but someone who has control over the controlled? I'm surprised with so many ppl nodding their head at this list of complaints about bad software processes at bad companies, masquerading as analysis. If you think it takes more than 2 days to learn _how_ to be a Scrum master, you don't understand the role. It's not complicated, difficult, and time-consuming enough to require a singular employee...unless your process is already screwed up. Good luck finding whatever magic bullet you think will save you that isn't Scrum-based teams.