This is my visceral response of the feelings I had when reading this post. I've not had good luck with Agile teams, some my own fault, some others fault. This is in no way meant to be a slight on Davide's article. It's just some thoughts... that's all.
Sounds to me like the same things poor managers push on development all the time. Software is never done. That's why we tried to move away from date setting to continuous delivery.
In total defense of those in the trenches, not even they are able to continually estimate correctly. Why? Because the frontend world's Npm ecosystem is a disaster not to mention the volume of things needed. A simple app requires 20 to 40 meg of Node Modules? Do we have any idea what all that shit is about?
Web Apis are easier due to standards centered around http protocols. But major unexpected things happen there too e.g. using SOAP to REST etc.
Security presents major obstacles which adds weeks in some cases just to get fundamental issues resolved.
I've been in IT since 1987, and have lived all the changes. Whats clear to me more than ever is the pressure to get it DONE is mostly a ridiculous expectation based on market pressure which has caught the highly paid planners unprepared.
I have yet to see companies have the proper Architecture in place to deliver rapidly. Sotware development is still a start from scratch endeavour. How can I say that? I've been a consultant my entire career. I have never once seen a internal company library of reusable components.
Your points are reminiscent of 60's style management which created toxic environments. You can hit a monkey as hard as you want to produce more, but if he doesn't know the answer it won't matter.
The real problem is in pushing up the reality of missed due dates because 3rd level expectations were simply wrong. You know, the quarterly planners. Somebody must push back and it rarely happens because, well, 1st line managers and Scrum masters would like to keep their job. So the trench person always takes the hit.
The points you made, make me glad I'm not on your team. I don't recognize any of them as collaborative in nature.
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
This is my visceral response of the feelings I had when reading this post. I've not had good luck with Agile teams, some my own fault, some others fault. This is in no way meant to be a slight on Davide's article. It's just some thoughts... that's all.
Sounds to me like the same things poor managers push on development all the time. Software is never done. That's why we tried to move away from date setting to continuous delivery.
In total defense of those in the trenches, not even they are able to continually estimate correctly. Why? Because the frontend world's Npm ecosystem is a disaster not to mention the volume of things needed. A simple app requires 20 to 40 meg of Node Modules? Do we have any idea what all that shit is about?
Web Apis are easier due to standards centered around http protocols. But major unexpected things happen there too e.g. using SOAP to REST etc.
Security presents major obstacles which adds weeks in some cases just to get fundamental issues resolved.
I've been in IT since 1987, and have lived all the changes. Whats clear to me more than ever is the pressure to get it DONE is mostly a ridiculous expectation based on market pressure which has caught the highly paid planners unprepared.
I have yet to see companies have the proper Architecture in place to deliver rapidly. Sotware development is still a start from scratch endeavour. How can I say that? I've been a consultant my entire career. I have never once seen a internal company library of reusable components.
Your points are reminiscent of 60's style management which created toxic environments. You can hit a monkey as hard as you want to produce more, but if he doesn't know the answer it won't matter.
The real problem is in pushing up the reality of missed due dates because 3rd level expectations were simply wrong. You know, the quarterly planners. Somebody must push back and it rarely happens because, well, 1st line managers and Scrum masters would like to keep their job. So the trench person always takes the hit.
The points you made, make me glad I'm not on your team. I don't recognize any of them as collaborative in nature.
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.