6 ms·

Maybe the time is right for anti-agile coaches to call all the companies that bought agile coaching over the past 15 years. I guess they'd be talking about why

Maybe the time is right for anti-agile coaches to call all the companies that bought agile coaching over the past 15 years. I guess they'd be talking about why waterfall was best all along. I think some of the root issue is the annoying micromanagement and lack of trust from non technical stakeholders. They need to chill out, but it's in their nature to be dicks somehow. They think if only they plug numbers into a spreadsheet correctly, huge savings will just pop out. But really they waste time and annoy the hell out of people. Maybe anti-agile is "fire all the nontechnical managers". Agile as a system of prioritization isn't bad, but human factors mess it up a lot.

misterflibble 4y ago
Yes I definitely feel that technical expertise and trust is needed in decision making for all projects. In my current team, developers don't have much influence (lol um.. I mean just me as I'm the only 100% full stack) and we have non-technical leadership. One problem is our tech leader isn't familiar with our programming language or development framework (worked with a different stack entirely). Also, both the tech leader and the Scrum master do not trust us to make any API or front end changes that aren't listed on the sprint board. Everything must be decided during sprint planning for the two-week sprint. So, if there's some code that obviously needs refactoring, or small code improvements (i.e. anything that's not on the board), every Pull Request is rejected. What's that you say? "Create an explanatory task/story ahead of time, and mention it during planning?" Sorry, I've tried that many times and they were all de-prioritised and post-poned. So, no trust both ways it seems! and now I'm ranting on HN Edited: grammar
hef19898 4y ago
>> I think some of the root issue is the annoying micromanagement and lack of trust from non technical stakeholders. They need to chill out, but it's in their nature to be dicks somehow. Sure. And now imagine that one of those people encounters your proverbial, arrogant, software solves it all developer. The results, if there are any to begin with, are glorious (gloriously unusable).
- BlargMcLarg 4y ago
  Arguing in extremes helps no one. Do a better job in your selection process and setting up proper paper trails and agreements. It's absurd how this extreme is used to justify micromanagement without recognizing how things have exploded despite micromanagement being the status quo. Haven't seen a single stereotype micromanagement scrum shop care enough about the consequences of letting a few cowboys loose only to have trouble hiring devs to fix the mess later (because no self-respecting developer wants to fix old code with near zero documentation for a pittance).
  - hef19898 4y ago
    I'd love my post to be an argument in extremes for arguments sake. It is, unfortunately, half of my daily work at the moment...
  - CactusOnFire 4y ago
    If I recall correctly, "Working software over comprehensive documentation" is part of the Agile Manifesto. I have seen this transformed into "We don't need documentation, just work on a new feature".

misterflibble 4y ago

Yes I definitely feel that technical expertise and trust is needed in decision making for all projects. In my current team, developers don't have much influence (lol um.. I mean just me as I'm the only 100% full stack) and we have non-technical leadership. One problem is our tech leader isn't familiar with our programming language or development framework (worked with a different stack entirely). Also, both the tech leader and the Scrum master do not trust us to make any API or front end changes that aren't listed on the sprint board. Everything must be decided during sprint planning for the two-week sprint. So, if there's some code that obviously needs refactoring, or small code improvements (i.e. anything that's not on the board), every Pull Request is rejected. What's that you say? "Create an explanatory task/story ahead of time, and mention it during planning?" Sorry, I've tried that many times and they were all de-prioritised and post-poned. So, no trust both ways it seems! and now I'm ranting on HN Edited: grammar

hef19898 4y ago

>> I think some of the root issue is the annoying micromanagement and lack of trust from non technical stakeholders. They need to chill out, but it's in their nature to be dicks somehow. Sure. And now imagine that one of those people encounters your proverbial, arrogant, software solves it all developer. The results, if there are any to begin with, are glorious (gloriously unusable).

BlargMcLarg 4y ago
Arguing in extremes helps no one. Do a better job in your selection process and setting up proper paper trails and agreements. It's absurd how this extreme is used to justify micromanagement without recognizing how things have exploded despite micromanagement being the status quo. Haven't seen a single stereotype micromanagement scrum shop care enough about the consequences of letting a few cowboys loose only to have trouble hiring devs to fix the mess later (because no self-respecting developer wants to fix old code with near zero documentation for a pittance).
- hef19898 4y ago
  I'd love my post to be an argument in extremes for arguments sake. It is, unfortunately, half of my daily work at the moment...
- CactusOnFire 4y ago
  If I recall correctly, "Working software over comprehensive documentation" is part of the Agile Manifesto. I have seen this transformed into "We don't need documentation, just work on a new feature".