This is why no estimation should be done in advance.
I don't know what kind of agile methodologies are you applying but agile is about delivering value to a product not moving tickets on time.
Agile techniques also help to move out the focus from engineers by understanding how sw development really works. If you, at any time, find yourself blaming somebody (e.g. because he/she is not in time) instead of blaming the system then you're sure you're not doing agile.
I take this article as anti-pattern recipe to any sw project management.
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 dont know how you could come to the conclusion I blame somebody for not being done.
the point is : and i always to it with a smile ( without sarcasm) - If you are not done, it's not a problem. Just let us know. Agile means being able to quickly react. If you dont let team mates and superiors know whats the real status, it's impossible to react.
Of course I meant you as a generic project mgmt guy. Anyway, "bugs" section depict exactly the blaming culture we should eradicate. Instead of questioning why an engineer missed an input validation we should ask ourselves how to improve the system so that this doesn't happen anymore.
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
did not mean to sound so harsh on the bug section.
but unfortunately, I had a couple of examples in mind which happen many years ago and seriously, there was not much in the system that could have been improved. simply my colleague at the time was very very sloppy.
believe me, you could have not missed that bug if you had run your code at least once after writing it.
In this case it is an HR problem. That person shouldn't have made its way there in the first place. It will repeat in other ways whatever measures you take.
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
:) Why I point out this is sometimes you may be wasting resources on things you cannot fix. The approach that ”introduce a workflow so that it never happens” should be taken with care or introducing systems for such people will consume your resources instead of the actual work.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is why no estimation should be done in advance.
I don't know what kind of agile methodologies are you applying but agile is about delivering value to a product not moving tickets on time.
Agile techniques also help to move out the focus from engineers by understanding how sw development really works. If you, at any time, find yourself blaming somebody (e.g. because he/she is not in time) instead of blaming the system then you're sure you're not doing agile.
I take this article as anti-pattern recipe to any sw project management.
I dont know how you could come to the conclusion I blame somebody for not being done.
the point is : and i always to it with a smile ( without sarcasm) - If you are not done, it's not a problem. Just let us know. Agile means being able to quickly react. If you dont let team mates and superiors know whats the real status, it's impossible to react.
Of course I meant you as a generic project mgmt guy. Anyway, "bugs" section depict exactly the blaming culture we should eradicate. Instead of questioning why an engineer missed an input validation we should ask ourselves how to improve the system so that this doesn't happen anymore.
did not mean to sound so harsh on the bug section.
but unfortunately, I had a couple of examples in mind which happen many years ago and seriously, there was not much in the system that could have been improved. simply my colleague at the time was very very sloppy.
believe me, you could have not missed that bug if you had run your code at least once after writing it.
In this case it is an HR problem. That person shouldn't have made its way there in the first place. It will repeat in other ways whatever measures you take.
absolutely. and whenever he is right now, I am pretty sure he still does. :-)
:) Why I point out this is sometimes you may be wasting resources on things you cannot fix. The approach that ”introduce a workflow so that it never happens” should be taken with care or introducing systems for such people will consume your resources instead of the actual work.