This looks like more of an "ad" (or a very directed study by a competing methodology), but excess pragmatism can ruin even the most sensible ideas.
Agile, testing, design patterns, best practices can all tank and bury a project if applied excessively "by the books" without consideration of the actual problem to solve.
I've worked in teams that had about 10 people actual doing dev work that implemented the full suite of Agile "principles" as rules. Daily standups, grooming, retros, pointing as "poker", 1:1s every week. The result was that we had barely time to actual work since the week had 10-20 hours of meetings. Most retros and standups were literally just us saying "same as yesterday, only had a few minutes to work on this" the whole week.
Testing is the same. If applied without consideration for the actual problems, reaching that 90%+ code coverage is easy if nobody cares about how hard and time consuming it will be to change code later. Specially when a feature is in very early development.
I think all those things are good, but what I see sometimes is that they are applied as absolute rules that cannot be deviated from, which inevitably leads to poor results.
I'm now working in a "light Agile" environment with just 2-3 meetings a week, barely 1 hour total, and much less strict PR/testing requirements (we focus on testing the important functionality, not line coverage count) and it is so much better. Some of the same co-workers that were under the more strict rules are now twice or more more productive then before.
Agile, testing, design patterns, best practices can all tank and bury a project if applied excessively "by the books" without consideration of the actual problem to solve.
I've worked in teams that had about 10 people actual doing dev work that implemented the full suite of Agile "principles" as rules. Daily standups, grooming, retros, pointing as "poker", 1:1s every week. The result was that we had barely time to actual work since the week had 10-20 hours of meetings. Most retros and standups were literally just us saying "same as yesterday, only had a few minutes to work on this" the whole week.
Testing is the same. If applied without consideration for the actual problems, reaching that 90%+ code coverage is easy if nobody cares about how hard and time consuming it will be to change code later. Specially when a feature is in very early development.
I think all those things are good, but what I see sometimes is that they are applied as absolute rules that cannot be deviated from, which inevitably leads to poor results.
I'm now working in a "light Agile" environment with just 2-3 meetings a week, barely 1 hour total, and much less strict PR/testing requirements (we focus on testing the important functionality, not line coverage count) and it is so much better. Some of the same co-workers that were under the more strict rules are now twice or more more productive then before.