1:00:38 "I think respecting the ppl who are choosing to make your organisation successful" I couldn't agree more, as I like to point out to ppl (when the situation deems it necessary bcs some may not be aware of their surroundings or just painfully oblivious); Just bcs we are technically at the "lowest level" hierarchical, does NOT mean that we (the software engineers) are low level...
to the point of systems thinking is about knowing what "it" depends on, I always hate it when people (usually fellow technical folks) answer questions with "it depends". if the question provided little context, don't just give a non-answer of "it depends"; ask for clarifications for more contexts and the questioner's experiences.
The problem is Dogma. Structured planning with waterfall doesn't work with complex systems with moving specifications. Agile dogma doesn't work when the customer is unsure, technically, about what they want but they have a solid deadline. Thinking in an agile (lower case) way would mean that you take what is needed to deliver from customer and product owner and have a vision which narrows (or not) as time progresses. Agile usually doesn't work when it hits the immediate demands of deadlines that are set before work is started. Have multiple domain experts and a unified guided vision to filter and push back on noise and don't over-specify. Frameworks and dogma don't work on larger projects as no two projects are the same.
Also while talking to the users as a dev probably would be very productive, I've also seen this turning out to be a detriment. Additionally, the levels of stress I would feel would grow even more, and it sometimes was already that high borderline psychosis was very real
Training systems is financial markets forecasts, sports and sports betting, anything where dynamics affect dynamics like game theory or risk analysis imho 1:40:39
I was hoping to walk away with more "aha" moments from Diana, but I do have to say your quote: “you know I have so I’ve definitely witnessed people using jira not as a way of recording those things we want done and why but as a way of not having to engage directly with other people. yeah like we use we use systems of record to avoid personal interaction because if I write it down on the card I won’t get challenged on it yes so the it’s a really tricky thing” was a huge "YES" moment, with how well you articulated that exact experience I've had.
I kinda completely missed out on agile letting you predict and plan better and better via more accurate estimations - on the contrary, retrospectively I think estimations were all pretty much bullshit
I'm liking the off-axis webcam position Diana is using. Very effective in these sort of videos.
Amazing podcast!!
these grandparents are truly ahead of their time knowing more about computer stuff than your average 20yo programmer
1:00:38 "I think respecting the ppl who are choosing to make your organisation successful"
I couldn't agree more, as I like to point out to ppl (when the situation deems it necessary bcs some may not be aware of their surroundings or just painfully oblivious); Just bcs we are technically at the "lowest level" hierarchical, does NOT mean that we (the software engineers) are low level...
to the point of systems thinking is about knowing what "it" depends on, I always hate it when people (usually fellow technical folks) answer questions with "it depends". if the question provided little context, don't just give a non-answer of "it depends"; ask for clarifications for more contexts and the questioner's experiences.
The problem is Dogma. Structured planning with waterfall doesn't work with complex systems with moving specifications. Agile dogma doesn't work when the customer is unsure, technically, about what they want but they have a solid deadline.
Thinking in an agile (lower case) way would mean that you take what is needed to deliver from customer and product owner and have a vision which narrows (or not) as time progresses. Agile usually doesn't work when it hits the immediate demands of deadlines that are set before work is started.
Have multiple domain experts and a unified guided vision to filter and push back on noise and don't over-specify. Frameworks and dogma don't work on larger projects as no two projects are the same.
Fascinating talk! Thank you!
Great topic! Thank you!
Feature-driven is so much more of an accurate term than scrum, agile, or any of the other terms that people use as a defense of their process.
Great topic
Also while talking to the users as a dev probably would be very productive, I've also seen this turning out to be a detriment. Additionally, the levels of stress I would feel would grow even more, and it sometimes was already that high borderline psychosis was very real
Training systems is financial markets forecasts, sports and sports betting, anything where dynamics affect dynamics like game theory or risk analysis imho 1:40:39
I was hoping to walk away with more "aha" moments from Diana, but I do have to say your quote:
“you know I have so I’ve definitely witnessed people using jira not as a way of recording those things we want done and why but as a way of not having to engage directly with other people. yeah like we use we use systems of record to avoid personal interaction because if I write it down on the card I won’t get challenged on it yes so the it’s a really tricky thing”
was a huge "YES" moment, with how well you articulated that exact experience I've had.
I kinda completely missed out on agile letting you predict and plan better and better via more accurate estimations - on the contrary, retrospectively I think estimations were all pretty much bullshit
And how to not build poorly performing bloatware...
Developers have taken the "premature optimisation is bad" dogma and removed the "premature" part.