4 ms·

Agile/Scrum is great if done properly. Most of the industry is doing it wrong/cargo-culting the wrong think. Non-technical managers, or worse, CS grads whose g

Agile/Scrum is great if done properly. Most of the industry is doing it wrong/cargo-culting the wrong think. Non-technical managers, or worse, CS grads whose goal was to stop coding 4 years into their careers, took the parts of Agile they liked and made it into a micro-management strategy to justify their work. Agile was written at a resort by 10x engineers for 10x engineers. Flat organization and high ownership (meaning these guys have a stake in the company). Trying to blindly copy it to highly hierarchical cost-center software shops is a recipe for disaster where the only ones making money are the agile consultants.

myth2018 6y ago
> Agile/Scrum is great if done properly. and, I'd like to point out, Agile/Scrum is great IF applied on suitable organizations/projects. Some projects are too big by nature and, regardless of how much resources are available, there are not enough 10x engineers to be hired and trained to deliver the project within a feasible time. Some organizations are too hierarchical and there's no way to change entire cultures based solely on software projects' needs. By extension, its employees are unlikely to show the level of ownership required by Agile. Don't get me wrong, I like Agile and favor it over other method families whenever I can, but I have a different point of view when it comes to organizations "not well-suited to Agile". I don't necessarily see them as limited solely based on how well software projects can be carried within their structures. It's indeed advantageous to possess a software project-friendly environment. That would provide them a good edge over competition. But there are so many other things beyond that, and so many organizations being successful on their main goals despite being Agile-hostile, that I'm more inclined to look for ways to cope with their shortcomings. I'm not implying you wanted to say that, but I see many Agile enthusiasts classifying those organizations as "not prepared to Agile" and I think this is so wrong. I see that simply as a natural incompatibility and, if I had to elect a culprit (which I don't think to be the case), then Agile would be the party which is in debt.
- 908B64B197 6y ago
  > Some organizations are too hierarchical and there's no way to change entire cultures based solely on software projects' needs. By extension, its employees are unlikely to show the level of ownership required by Agile. These two issues can be solved by isolating the software folks from the rest of the organization. Think of a company within a company. That and fixing the hiring pipeline can fix ownership: bringing a culture of stock based compensation typically attracts high achievers and make it important for the engineers to truly own the product.
  - myth2018 6y ago
    How so? You could structure your IT department as a flat organization (and I think it's indeed a good idea), but how would you fully adopt agile principles when they consider users as part of the team? How would you favor interactions over processes while stakeholders from the other side manifest low ownership levels or even sabotage the project (if they see the project putting their jobs at risk or when their managers don't give the project a proper level of priority)? In theory it makes sense, but experience shows it's impractical to apply Agile principles on such environments without some adaptation. I've already worked under such arrange (scrum + flat IT department inside hierarchical organization). It worked great for my project, but I was lucky to work with a competent and collaborative key user. On the other hand, some colleagues of mine faced issues. I suspect that their projects would have been more successful under a different, slightly more bureaucratic approach, given the sort of users they were working with
    - 908B64B197 6y ago
      > your IT department If software engineers are working as the "IT" department, it's already a red flag. Especially if it's treated as a cost-center. > It worked great for my project, but I was lucky to work with a competent and collaborative key user. On the other hand, some colleagues of mine faced issues. I suspect that their projects would have been more successful under a different, slightly more bureaucratic approach, given the sort of users they were working with Some users, especially internals, don't want any changes. when that happens, the only thing left to do is pretty much switch project sadly. With a stock compensation, you don't want to waste your time building something that won't be used: that doesn't create any value.
hrktb 6y ago
> Agile was written at a resort by 10x engineers for 10x engineers. Do these 10x engineers need Scrum ? I don’t think flat/high ownership organization have a strong need to be told how to do things, or import some cookie cutter framework in their day to day operation. Getting inspired ? sure, but a lot of the ceremony parts of Scrum don’t make sense if people already communicate fluently and organize seemlessly.
- 908B64B197 6y ago
  Nobody does the full Scrum. It's more of a set of ideas that can can be applied to a project (or not) and ways of thinking about the software engineering process itself. It's not a magic recipe, just like no programming language or framework will make RandomCo. a unicorn.
- Jtsummers 6y ago
  One of the details of the manifesto is that it does not tell you how to do things, and in fact discourages the prioritization of "processes and tools" over "individuals and interactions" (doesn't remove processes and tools, but it deprioritizes them). The manifesto was as much for the developers as for their managers and customers. It established the priorities of their work and relationship with each other.
- imbnwa 6y ago
  And people can only communicate fluently and organize seamlessly because of their understanding. There's no quickfix solution to making sure you hired the right people.
- mindcrime 6y ago
  > Agile was written at a resort by 10x engineers for 10x engineers. Do these 10x engineers need Scrum ? Not to beat a dead horse one more time, but "Agile <> Scrum" Scrum is just one, out of many methodologies that claim some association with the core ideas behind the Agile Manifesto. It's totally possible to be "Agile" and not do a single thing that's in Scrum. And just to add one more note: there's a lot of "stuff" that gets lumped in with Scrum in a lot of these criticism heavy threads, that isn't actually part of Scrum per-se. Often times idiot would-be Scrum masters cobble together bits and piece of ideas here and there and make some goofy hodge-podge and then call it Scrum. I'd encourage anybody contemplating Scrum for whatever reason to go read the Scrum Guide and see how different it is from the "Scrum" their organization practices. Same for the Agile Manifesto. And if you encounter an organization that claims to be doing SAFE (Scaled Agile Framework) turn and run away as fast as you can, IMO.
d13 6y ago
The only time I’ve seen it done properly was a team I worked in before the Agile manifesto was written.

myth2018 6y ago

> Agile/Scrum is great if done properly. and, I'd like to point out, Agile/Scrum is great IF applied on suitable organizations/projects. Some projects are too big by nature and, regardless of how much resources are available, there are not enough 10x engineers to be hired and trained to deliver the project within a feasible time. Some organizations are too hierarchical and there's no way to change entire cultures based solely on software projects' needs. By extension, its employees are unlikely to show the level of ownership required by Agile. Don't get me wrong, I like Agile and favor it over other method families whenever I can, but I have a different point of view when it comes to organizations "not well-suited to Agile". I don't necessarily see them as limited solely based on how well software projects can be carried within their structures. It's indeed advantageous to possess a software project-friendly environment. That would provide them a good edge over competition. But there are so many other things beyond that, and so many organizations being successful on their main goals despite being Agile-hostile, that I'm more inclined to look for ways to cope with their shortcomings. I'm not implying you wanted to say that, but I see many Agile enthusiasts classifying those organizations as "not prepared to Agile" and I think this is so wrong. I see that simply as a natural incompatibility and, if I had to elect a culprit (which I don't think to be the case), then Agile would be the party which is in debt.

908B64B197 6y ago
> Some organizations are too hierarchical and there's no way to change entire cultures based solely on software projects' needs. By extension, its employees are unlikely to show the level of ownership required by Agile. These two issues can be solved by isolating the software folks from the rest of the organization. Think of a company within a company. That and fixing the hiring pipeline can fix ownership: bringing a culture of stock based compensation typically attracts high achievers and make it important for the engineers to truly own the product.
- myth2018 6y ago
  How so? You could structure your IT department as a flat organization (and I think it's indeed a good idea), but how would you fully adopt agile principles when they consider users as part of the team? How would you favor interactions over processes while stakeholders from the other side manifest low ownership levels or even sabotage the project (if they see the project putting their jobs at risk or when their managers don't give the project a proper level of priority)? In theory it makes sense, but experience shows it's impractical to apply Agile principles on such environments without some adaptation. I've already worked under such arrange (scrum + flat IT department inside hierarchical organization). It worked great for my project, but I was lucky to work with a competent and collaborative key user. On the other hand, some colleagues of mine faced issues. I suspect that their projects would have been more successful under a different, slightly more bureaucratic approach, given the sort of users they were working with
  - 908B64B197 6y ago
    > your IT department If software engineers are working as the "IT" department, it's already a red flag. Especially if it's treated as a cost-center. > It worked great for my project, but I was lucky to work with a competent and collaborative key user. On the other hand, some colleagues of mine faced issues. I suspect that their projects would have been more successful under a different, slightly more bureaucratic approach, given the sort of users they were working with Some users, especially internals, don't want any changes. when that happens, the only thing left to do is pretty much switch project sadly. With a stock compensation, you don't want to waste your time building something that won't be used: that doesn't create any value.

hrktb 6y ago

> Agile was written at a resort by 10x engineers for 10x engineers. Do these 10x engineers need Scrum ? I don’t think flat/high ownership organization have a strong need to be told how to do things, or import some cookie cutter framework in their day to day operation. Getting inspired ? sure, but a lot of the ceremony parts of Scrum don’t make sense if people already communicate fluently and organize seemlessly.

908B64B197 6y ago
Nobody does the full Scrum. It's more of a set of ideas that can can be applied to a project (or not) and ways of thinking about the software engineering process itself. It's not a magic recipe, just like no programming language or framework will make RandomCo. a unicorn.
Jtsummers 6y ago
One of the details of the manifesto is that it does not tell you how to do things, and in fact discourages the prioritization of "processes and tools" over "individuals and interactions" (doesn't remove processes and tools, but it deprioritizes them). The manifesto was as much for the developers as for their managers and customers. It established the priorities of their work and relationship with each other.
imbnwa 6y ago
And people can only communicate fluently and organize seamlessly because of their understanding. There's no quickfix solution to making sure you hired the right people.
mindcrime 6y ago
> Agile was written at a resort by 10x engineers for 10x engineers. Do these 10x engineers need Scrum ? Not to beat a dead horse one more time, but "Agile <> Scrum" Scrum is just one, out of many methodologies that claim some association with the core ideas behind the Agile Manifesto. It's totally possible to be "Agile" and not do a single thing that's in Scrum. And just to add one more note: there's a lot of "stuff" that gets lumped in with Scrum in a lot of these criticism heavy threads, that isn't actually part of Scrum per-se. Often times idiot would-be Scrum masters cobble together bits and piece of ideas here and there and make some goofy hodge-podge and then call it Scrum. I'd encourage anybody contemplating Scrum for whatever reason to go read the Scrum Guide and see how different it is from the "Scrum" their organization practices. Same for the Agile Manifesto. And if you encounter an organization that claims to be doing SAFE (Scaled Agile Framework) turn and run away as fast as you can, IMO.

d13 6y ago

The only time I’ve seen it done properly was a team I worked in before the Agile manifesto was written.