Comments by "TheEvertw" (@TheEvertw) on ""Agile Practices are 268% More Likely To Fail"... WHAT A LOAD OF..." video.

  1. ​ @DumbledoreMcCracken  Touchée! Truth is, requirements need to be written by those who know what needs to be built, not how to build it. Though some understanding of the realities of SW engineering can be very helpful when writing requirements. As a Unix guru once noted, "it is better to built the right solution the wrong way, than the wrong solution the right way". Or as someone else said, "It is better to be approximately right than absolutely wrong".
    4
  2.  @georgehelyar  I have seen plenty of "waterfall" project succeed. But if you look closer, those projects were done by mature developers and managers who knew how to handle surprises and manage risk. Which is what being "agile" boils down to.
    4
  3. If you are a successful SW engineer (successful as in making successful solutions), I can guarantee that you have incorporated most if not all of the Agile Manifesto in you way of work. Do you listen to your users and incorporate their feedback, or do you doggedly continue building what was agreed years ago even when users are dissatisfied? Do you write reams of documentation no-one will read and even when they do, they discover it is out of date? When a colleague comes with a question, or you see him struggling, do you refer to the documentation system or the Design, or do you sit down to work with him? Does your Design change when you discover that it must? Did you ever talk with a User or other non-SW person to discover you misunderstood something about the solution, and then changed the SW accordingly? If you answer these with Yes, you are Agile.
    3
  4. The problem with sprints is that it was never intended for constant use throughout the project. They didn't call it a SPRINT for nothing. You can only sprint once in a while, NEVER continuously. Continuous Delivery is a MUCH better way of working, even if not completely applicable in all SW projects, because the user feedback element is not always an automatic result of continuous delivery. So sometimes you need to organize events to garner user feedback and demonstrate progress to the stakeholders. And with CD you can organize these events anytime without putting pressure on the team, because the SW is always ready to be demonstrated.
    2
  5. Another great video! People offering quick fixes or methodologies for making the outcome of SW projects more predictable, and are not truly Agile, are no better than snake-oil salesmen. They offer false security. The problem is that in SW, all the repetitive work is automated, and thus doesn't cost anything. Whereas in the other engineering disciplines the repetitive work costs an order of magnitude (often several orders of magnitude) more than the non-repetitive, creative, design work. So any methodology that borrows from other engineering disciplines simply doesn't work in SW development. SW development is inherently more complex and difficult than most other engineering work. As someone said, there is no silver bullet. (Systems Engineering is also inherently complex. Thus system engineering methodologies borrow heavily from SW engineering and vice-versa.)
    2
  6. You can be Agile without calling yourself agile.
    1