davebs
commented
5 years ago I'm not sure what you're advocating here.
Closed meilhard closed 5 years ago
davebs
commented
5 years ago I'm not sure what you're advocating here.
davebs
commented
5 years ago Staying in a dialog with the business side of the company! Constantly negotiate the technical needs of your code against the business needs. Being involved in every single Sprint planning session! Try to convince the management that the code will need constant refactoring if it should still work in a few years! And be very clear about what the team can achieve! And if the management still thinks it needs overtime and work on weekends get the hell out of there as quick as you can! No framework will ever improve that environment!
I guess this is what you're advocating. It sounds to me like framework nihilism. I agree there are no silver bullets. I disagree that it's pointless to discuss process. I don't think the situation is as bleak as you say.
I get it. You want to prevent burn out. That's fine! But unfortunately your assumptions are wrong! It's not the framework that causes burn out! It's in most cases the somehow understandable desire of the business to get as much done as possible in as little time as possible. Often it's not understood from management that you will pay a high price for keep doing that over a long period of time. How does your "agile light" approach prevent that in any way? You told me earlier in another ticket that unfortunately the classic agile frameworks are often implemented in a wrong way. You are right! But how does your approach prevent being implemented wrongly?
As far a I understood so far, your "agile light" tries to protect the developers against any kind of organisational meeting culture. The don't need to attend the sprint planning. There is no need for Stand Ups and you also said no Retrospectives needed. So what does it mean? Management is planning the sprint for you! You will have more on your plate as you can solve! No Retrospective means you won't even have a platform to adress this! No Standups? No way of telling everyone involved including the PO that there is too much in the sprint! Great idea!
So, basically your "agile light" in a bad environment makes the situation even worse!
What would be a way of preventing burn out you ask?
Staying in a dialog with the business side of the company! Constantly negotiate the technical needs of your code against the business needs. Being involved in every single Sprint planning session! Try to convince the management that the code will need constant refactoring if it should still work in a few years! And be very clear about what the team can achieve! And if the management still thinks it needs overtime and work on weekends get the hell out of there as quick as you can! No framework will ever improve that environment!