5 ms·

Fine, scrum sucks! I agree. What's the alternative?

rawgabbit 4y ago
We can start by recognizing that scrum and agile cannot replace actual development talent. When companies throw additional scrum masters and project managers into a failing project, the project only fails faster. People first, tools second, and then process.
- pempem 4y ago
  ^ this is agile. at least "people first" - then its process and tools. Tools are last, because there are always new tools and the way you do something should be somewhat consistent within a team/org even if the tools aren't While scrum/agile does not = more developers, it can be leveraged to actually grow a developer's career and skills when done well.
  - rawgabbit 4y ago
    As a technophile, I always disagree with that sentiment. Michelangelo cannot sculpt the Pieta with a sledgehammer and sticks. These days we need highly specialized tools to do our work. These highly specialized tools require specialized developers. The only alternative to this is low code/no code tools. Low code/no code is great for green field projects, as you can ensure a steady pipeline of such developers.
    - pempem 4y ago
      oh my. In a world of continously created saas pursuing bits of walletshare and department budgets endlessly I would say there is a small % of tools that are specialized and uniquely required. There's also a TON of tools that are preference based selection. Michelangelo sculpted with one set of tools and painted with another. Klimt may have had some overlap with one and none with the other set. Neither was being doggedly pursued by salespeople or having decisions about tools made by their bosses. IMO: Its not an apt metaphor in the slightest.
- bladelessninja2 4y ago
  One of the first things Scrum says is that you need to have a team with skills that ensures the job done. Same with Agile: literally says about "motivated individuals" and "self-organizing teams". So, arguably, you are not talking about Scrum nor Agile in those failing projects - you just share this naive view I saw in some managers: "we just put scrum master here and thus we have scrum implemented".
  - rawgabbit 4y ago
    I was not referring to "motivated individuals". I was referring to developers with actual technical skills and actual experience with the tools used by the development team. What I often see is management being told we can hire the cheapest developers with zero experience and throw in scrum/agile... and we will achieve the same outcomes. The result is a mountain of tech debt and pagers going off at all hours at the day.
    - bladelessninja2 4y ago
      Well, scrum literally says that the team should have skills needed to get the job done, so you can still defend scrum, whereas agile says about putting people's interactions over processes and about pursuing technical excellence, so creating tech debt is still not agile. So, I'm not sure if we can agree on that, but, arguably, I believe it is not scrum or agile that are failing, but management who doesn't want to be agile or/and follow scrum. This is my experience numerous talk I had on escalated level when my team was rising issues with management.
- marsven_422 4y ago
mr90210 4y ago
What works best for you.
valenterry 4y ago
How about: Don't follow a fixed, predefined process but find the one that works for your specific situation and adapt it when needed.
- nine_k 4y ago
  Sounds like a lot of work. Starting it from scratch would be a project in itself. So some assortment of reasonable starting points, with their pros and cons described, would be valuable.
  - valenterry 4y ago
    Why so? No one forbids you to pick a process and/or tools that come close to the perfect process and then change them as necessary. You don't have to reinvent the wheels. You can use Scrum, Kanban, ... as starting points. Just don't implement them mindlessly like most companies do.
    - cassianoleal 4y ago
      "Individuals and interactions over processes and tools" "Responding to change over following a plan" These are 2 of the 4 tenets in the manifesto for agile development [0]. They go on by saying: "That is, while there is value in the items on the right, we value the items on the left more." Essentially, choose tools. Follow processes. Periodically and permanently reevaluate. If following the plan creates an impediment to interactions, or makes the people dissatisfied, respond to these changes. Rinse and repeat. [0] https://agilemanifesto.org/ https://agilemanifesto.org/
- andrewflnr 4y ago
  That sounds good, sort of a mindset of flexing and changing direction as you move forward. You might call it... agility.
- pempem 4y ago
  This is the agile suggestion. A previous commenter had it right imho. Its not that the approach isn't working, its that it has been co-opted by management and requires separation to actually succeed. Another note would be that agile itself says: - non team members shouldn't be at stand ups etc. - points shouldn't be used for evaluation of performance (good luck with that) - if management joins anything other than the demo, they should not speak during the meeting (I've had some success here but also always been labeled a curiosity when I push management to be silent)
wahnfrieden 4y ago
Anarchist worker syndicates
taeric 4y ago
The framing is wrong. There is no singular alternative that works. Use it as a tool to keep things moving. If it ever feels that you are doing it for the sake of the process, look hard at changing it. And don't get pulled into success. Most anything can and will work with eager teams at the start. Life has a way of changing without you noticing.
- rileymat2 4y ago
  You could have a Retrospective to analyze what is working and what could improve.
  - taeric 4y ago
    Right, and you should. But a retrospective is just another process. As soon as you find you are doing it for the sake of doing it, consider not for a while.
    - rileymat2 4y ago
      It is interesting to think about what processes a framework can allow to be changed, and what needs to stay. That said. I have never been anywhere where the process does not have room for improvement. But often improvement seems impossible for structural reasons, for a team that is not empowered, where people are checked out, or not forthright due to whatever reasons. And like you say, people go through the motions for the sake of doing it, leading to wasted time and more frustration. Eliminating the retrospective is the easy choice to avoid that.
postalrat 4y ago
Good Cowboy

We can start by recognizing that scrum and agile cannot replace actual development talent. When companies throw additional scrum masters and project managers into a failing project, the project only fails faster. People first, tools second, and then process.

pempem 4y ago
^ this is agile. at least "people first" - then its process and tools. Tools are last, because there are always new tools and the way you do something should be somewhat consistent within a team/org even if the tools aren't While scrum/agile does not = more developers, it can be leveraged to actually grow a developer's career and skills when done well.
- rawgabbit 4y ago
  As a technophile, I always disagree with that sentiment. Michelangelo cannot sculpt the Pieta with a sledgehammer and sticks. These days we need highly specialized tools to do our work. These highly specialized tools require specialized developers. The only alternative to this is low code/no code tools. Low code/no code is great for green field projects, as you can ensure a steady pipeline of such developers.
  - pempem 4y ago
    oh my. In a world of continously created saas pursuing bits of walletshare and department budgets endlessly I would say there is a small % of tools that are specialized and uniquely required. There's also a TON of tools that are preference based selection. Michelangelo sculpted with one set of tools and painted with another. Klimt may have had some overlap with one and none with the other set. Neither was being doggedly pursued by salespeople or having decisions about tools made by their bosses. IMO: Its not an apt metaphor in the slightest.
bladelessninja2 4y ago
One of the first things Scrum says is that you need to have a team with skills that ensures the job done. Same with Agile: literally says about "motivated individuals" and "self-organizing teams". So, arguably, you are not talking about Scrum nor Agile in those failing projects - you just share this naive view I saw in some managers: "we just put scrum master here and thus we have scrum implemented".
- rawgabbit 4y ago
  I was not referring to "motivated individuals". I was referring to developers with actual technical skills and actual experience with the tools used by the development team. What I often see is management being told we can hire the cheapest developers with zero experience and throw in scrum/agile... and we will achieve the same outcomes. The result is a mountain of tech debt and pagers going off at all hours at the day.
  - bladelessninja2 4y ago
    Well, scrum literally says that the team should have skills needed to get the job done, so you can still defend scrum, whereas agile says about putting people's interactions over processes and about pursuing technical excellence, so creating tech debt is still not agile. So, I'm not sure if we can agree on that, but, arguably, I believe it is not scrum or agile that are failing, but management who doesn't want to be agile or/and follow scrum. This is my experience numerous talk I had on escalated level when my team was rising issues with management.
marsven_422 4y ago

mr90210 4y ago

What works best for you.

valenterry 4y ago

How about: Don't follow a fixed, predefined process but find the one that works for your specific situation and adapt it when needed.

nine_k 4y ago
Sounds like a lot of work. Starting it from scratch would be a project in itself. So some assortment of reasonable starting points, with their pros and cons described, would be valuable.
- valenterry 4y ago
  Why so? No one forbids you to pick a process and/or tools that come close to the perfect process and then change them as necessary. You don't have to reinvent the wheels. You can use Scrum, Kanban, ... as starting points. Just don't implement them mindlessly like most companies do.
  - cassianoleal 4y ago
    "Individuals and interactions over processes and tools" "Responding to change over following a plan" These are 2 of the 4 tenets in the manifesto for agile development [0]. They go on by saying: "That is, while there is value in the items on the right, we value the items on the left more." Essentially, choose tools. Follow processes. Periodically and permanently reevaluate. If following the plan creates an impediment to interactions, or makes the people dissatisfied, respond to these changes. Rinse and repeat. [0] https://agilemanifesto.org/ https://agilemanifesto.org/
andrewflnr 4y ago
That sounds good, sort of a mindset of flexing and changing direction as you move forward. You might call it... agility.
pempem 4y ago
This is the agile suggestion. A previous commenter had it right imho. Its not that the approach isn't working, its that it has been co-opted by management and requires separation to actually succeed. Another note would be that agile itself says: - non team members shouldn't be at stand ups etc. - points shouldn't be used for evaluation of performance (good luck with that) - if management joins anything other than the demo, they should not speak during the meeting (I've had some success here but also always been labeled a curiosity when I push management to be silent)

wahnfrieden 4y ago

Anarchist worker syndicates

taeric 4y ago

The framing is wrong. There is no singular alternative that works. Use it as a tool to keep things moving. If it ever feels that you are doing it for the sake of the process, look hard at changing it. And don't get pulled into success. Most anything can and will work with eager teams at the start. Life has a way of changing without you noticing.

rileymat2 4y ago
You could have a Retrospective to analyze what is working and what could improve.
- taeric 4y ago
  Right, and you should. But a retrospective is just another process. As soon as you find you are doing it for the sake of doing it, consider not for a while.
  - rileymat2 4y ago
    It is interesting to think about what processes a framework can allow to be changed, and what needs to stay. That said. I have never been anywhere where the process does not have room for improvement. But often improvement seems impossible for structural reasons, for a team that is not empowered, where people are checked out, or not forthright due to whatever reasons. And like you say, people go through the motions for the sake of doing it, leading to wasted time and more frustration. Eliminating the retrospective is the easy choice to avoid that.

postalrat 4y ago

Good Cowboy