Trouble maker and Problem solver ⚙️🔧
Loves simplicity, hates bullshit 💩.
Productivity obsessed, avid learner 🖥🚀
Sport and outdoor freak 🧗⛰
Metalhead 🎸🤘 Father of 2 👨👩👦👦
Opinions are my own
thank you very much for your detailed comment, but I believe you did not quite get my point.
I am not ranting about developers not delivering on time and putting more pressure on them.
I just listed all the possible reasons why we ( and I put myself in since I still code 80% of my day) are often caught saying generic "I am almost done" during standups.
and I made it very clear in the conclusion that being precise about the level of doneness could help improve estimates, planning, manage to stretch a bit the schedule, or get some helping hands from colleagues.
not at all to punish or ridicule the struggling developer.
i am sorry if I was not able to deliver the idea with more clearly and with more humor.
I totally get your points. We're all in the same boat, but the root of the issue is simply today's expectations truly exceed any ability to set a due date.
Continuous delivery is the only way with each iteration biting off small chunks. If a dependency arises and management doesn't address it (like security getting in the way, or poor infrastructure) then the problem is not the developer's issue. Yet it's the developer who has to stand in front of a group of peers (who are not having the same issues) and report daily.
Retrospectives are another joke, I've seen idea after idea to improve never receive any traction because the desire to meet a due date exceeds the ability to fix technical debt. Developers are simply not allowed to create the tools and processes necessary to heal the toxic environment. In fact technical debt is almost never addressed, in favor of getting the new stuff out.
Any developer who's been around a while, knows there's nothing they can't accomplish, it's just a matter of time. Putting additional pressure on the developer is not the answer. What's need is shared responsibility and collaboration. Many drill sergeants don't do that; rather, they side with upper managers in order to shine and keep their job in this ultra competitive world.
I my last 7 years, I've only had 1 of 5 Agile teams actually make it pleasant to work there. The rest either just wanted to keep their jobs or were arrogant by nature. Arrogant leaders are a big thing in IT which is a total detriment to IT Teams.
Trouble maker and Problem solver ⚙️🔧
Loves simplicity, hates bullshit 💩.
Productivity obsessed, avid learner 🖥🚀
Sport and outdoor freak 🧗⛰
Metalhead 🎸🤘 Father of 2 👨👩👦👦
Opinions are my own
i could not agree more with what you wrote, besides that in my last 7 years and 5 teams only 1 was not pleasant to work with, exactly for the reason you mentioned.
Retrospective were done just because it was cool to say we were agile, the pression was too high, tecnical debt never addressed, it was
feature feature feature!
and then of course
bugs bugs bugs!!
but I managed to leave that team and then always found strong colleagues that shared passion and will to change, and good managers that fought on our side bringing our requests to the management, rather than just filtering them account ( yes yes, tell me and then i will never bring them up..)
Also please be aware I'm not talking to you directly, the content of your article is mostly good. It caused me a bit of pain as I read it based on my past experiences with everything you mentioned. Stand-ups can be great but they can also be tortuous. Retrospectives can be great and they can be worthless. Dependencies can be taken seriously or glossed over. Infrastructure is almost universally not enough on long standing projects. Security can be too tight. Complexity is over the top difficult and finally the tooling isn't quite there yet.
Tying in JavaScript with a different back-end is ludicrous but done all the time. How many hats are developers required to wear? It takes a minimum of 1.5 years to be a SME for Java or C# minimum. Typescript/JavaScript take the same amount of time.
Trouble maker and Problem solver ⚙️🔧
Loves simplicity, hates bullshit 💩.
Productivity obsessed, avid learner 🖥🚀
Sport and outdoor freak 🧗⛰
Metalhead 🎸🤘 Father of 2 👨👩👦👦
Opinions are my own
Trouble maker and Problem solver ⚙️🔧
Loves simplicity, hates bullshit 💩.
Productivity obsessed, avid learner 🖥🚀
Sport and outdoor freak 🧗⛰
Metalhead 🎸🤘 Father of 2 👨👩👦👦
Opinions are my own
thank you very much for your detailed comment, but I believe you did not quite get my point.
I am not ranting about developers not delivering on time and putting more pressure on them.
I just listed all the possible reasons why we ( and I put myself in since I still code 80% of my day) are often caught saying generic "I am almost done" during standups.
and I made it very clear in the conclusion that being precise about the level of doneness could help improve estimates, planning, manage to stretch a bit the schedule, or get some helping hands from colleagues.
not at all to punish or ridicule the struggling developer.
i am sorry if I was not able to deliver the idea with more clearly and with more humor.
I totally get your points. We're all in the same boat, but the root of the issue is simply today's expectations truly exceed any ability to set a due date.
Continuous delivery is the only way with each iteration biting off small chunks. If a dependency arises and management doesn't address it (like security getting in the way, or poor infrastructure) then the problem is not the developer's issue. Yet it's the developer who has to stand in front of a group of peers (who are not having the same issues) and report daily.
Retrospectives are another joke, I've seen idea after idea to improve never receive any traction because the desire to meet a due date exceeds the ability to fix technical debt. Developers are simply not allowed to create the tools and processes necessary to heal the toxic environment. In fact technical debt is almost never addressed, in favor of getting the new stuff out.
Any developer who's been around a while, knows there's nothing they can't accomplish, it's just a matter of time. Putting additional pressure on the developer is not the answer. What's need is shared responsibility and collaboration. Many drill sergeants don't do that; rather, they side with upper managers in order to shine and keep their job in this ultra competitive world.
I my last 7 years, I've only had 1 of 5 Agile teams actually make it pleasant to work there. The rest either just wanted to keep their jobs or were arrogant by nature. Arrogant leaders are a big thing in IT which is a total detriment to IT Teams.
i could not agree more with what you wrote, besides that in my last 7 years and 5 teams only 1 was not pleasant to work with, exactly for the reason you mentioned.
Retrospective were done just because it was cool to say we were agile, the pression was too high, tecnical debt never addressed, it was
but I managed to leave that team and then always found strong colleagues that shared passion and will to change, and good managers that fought on our side bringing our requests to the management, rather than just filtering them account ( yes yes, tell me and then i will never bring them up..)
Also please be aware I'm not talking to you directly, the content of your article is mostly good. It caused me a bit of pain as I read it based on my past experiences with everything you mentioned. Stand-ups can be great but they can also be tortuous. Retrospectives can be great and they can be worthless. Dependencies can be taken seriously or glossed over. Infrastructure is almost universally not enough on long standing projects. Security can be too tight. Complexity is over the top difficult and finally the tooling isn't quite there yet.
Tying in JavaScript with a different back-end is ludicrous but done all the time. How many hats are developers required to wear? It takes a minimum of 1.5 years to be a SME for Java or C# minimum. Typescript/JavaScript take the same amount of time.
I know. no problem. honestly, I regret picking such a straightforward blunt title which does not really reflect the overall mood of my post.
And I'm suffering from PTSD for being in Agile trenches too long....
sorry man.
hope you get well and wish you can find a nice team with smart colleagues and managers. lots of challenges but without stupid pressure
I apologize Davide, I think I was triggered from past experiences. Thanks for posting this.