4 ms·

Jira isn’t the problem. The problem is software estimation, managers who require a date, probability, and ever letting process people touch agile. Software est

Jira isn’t the problem. The problem is software estimation, managers who require a date, probability, and ever letting process people touch agile. Software estimation is basically a useless craft. Rather than focusing on when things are being delivered I think it’s much more important to focus on are things being done most efficiently right now and making sure past obstacles don’t come back. Management often requires a date of delivery for broader strategic planning - which is understandable. However they confuse precision for accuracy. The reality is, unlike building a building, often the software being built has a ton of unknowable elements that are due to the software being bespoke in many crucial ways. The joint probability of a bunch of very positively skewed distributions “and”’ed together yields a random date skewed way too early. To solve this process people were brought in to “fix” agile but creating bullshit like story points and points poker and burn down charts and pigs and chickens. Then they graft all this into Jira to improve automation, structuring, and reporting. Agile used to not be like this. Not every project of every org was well adapted to agile, and it required management that gets once you embark on a software effort there’s a lot of indeterminacy involved. Pressure to stay lean and agile should be focused on the present, that efficiency is high and decisions are made quickly, regret is addressed to ensure it doesn’t come back, etc. The future takes care of itself if you take care of the present. I also like to describe the an uncertainty principle of software development. The more you try to measure it and predict delivery the slower it is, with worse outcomes, less reliably forecasting, with more attrition and burnout.

ohthehugemanate 3y ago
So many +1s for you. I want to add that if the team is focusing on the present, it becomes clear that estimation is a passive, descriptive (rather than active, proscriptive) act. No ticket has time pressure on it. The manager predicts the future timeline based on how long similar tasks took in the past, on average. No idea if one task will take 5 or 15 days, but 10 of them will take about 100 days. Once you understand that, there are many very simple ways for a competent manager to get development velocity out without adding work for the developers... and all management actually wants is average velocity and remaining work in similar units. If your team tries to keep tickets about the same size, ticket throughput is your velocity. At most the devs can slap gut instinct Easy/Medium/Hard labels on the tickets so they don't have to "right size" everything. Either of those (or a thousand variants), when coupled with the pile of work left to do (in the present understanding) can give a competent manager high precision long term estimates with confidence intervals. No need to make it more complicated (or time consuming!) unless the devs tell you they NEED more. In my experience, teams that focus on the present, and which are in control of their own process (ie adding or changing only when DEVS feel the need) typically end up evolving their own agile process... which is way more effective than OOTB processes like Scrum, and doesn't feel like a burden (the team drops anything that feels like a burden). Teams who have a process imposed upon them, on the other hand, spend years ranting online about how terrible agile is, and waste a lot of time in unnecessary bullshit.
- yunohn 3y ago
  > Teams who have a process imposed upon them In my experience, this is the vast majority of cases. Hence: > spend years ranting online about how terrible agile is
  - ohthehugemanate 3y ago
    Sad but true. And to make matters worse, those seem to be the same environments where businesspeople make target dates without engineering, and then get angry when the deadlines aren't met. Put another way, poor management is a human layer problem. No technology (whether process or tool) can solve that for you.
yladiz 3y ago
> Software estimation is basically a useless craft. It depends on how you're thinking about estimates. Just saying they're useless is arguably missing the benefit of the process. Estimates are not generally useful in and of themselves (as in, the estimate value isn't particularly useful), but the process around agreeing on the value within a team is. If you're on a team and estimating a task during refinement, and there are wildly different estimates from the different team members, then the definition and/or understanding of the task is wrong and it needs more clarity and discussion. Another thing is that date estimates are problematic, and estimates should more generally be used to estimate complexity, and while they might be linked in some way, they're not the same. The issue with estimates, in my opinion, comes down to the process after the value has been determined. If it's used as a benchmark or metric in some way, then you get into problematic situations. I also do disagree with this: > The reality is, unlike building a building, often the software being built has a ton of unknowable elements that are due to the software being bespoke in many crucial ways. Honestly, software development is not as complex as people like to believe and there aren't as many unknowable elements as people like to think, and in my opinion this line of thinking is just an excuse to not actually think about what needs to be done to complete a task.
- CodeMage 3y ago
  > Honestly, software development is not as complex as people like to believe and there aren't as many unknowable elements as people like to think, and in my opinion this line of thinking is just an excuse to not actually think about what needs to be done to complete a task. Funny, I've been hearing this constantly over the 24 years of my professional experience as a software developer and I've yet to see it proven true. Unless we're talking about toy examples like Hello World, developing quality software is devilishly complicated and, in my opinion, downplaying this complexity as an "excuse" is in itself an excuse to compromise quality. EDIT: Fixed a few words my phone auto-"corrected" for me.
- fnordpiglet 3y ago
  I’d say just discussing how a task will be implemented susses out whether it’s understood. Estimation isn’t a useful part of that discussion. Estimation is almost exclusively for the benefit of management is determining when something will be done. I would say if this is true in your work: > Honestly, software development is not as complex as people like to believe and there aren't as many unknowable elements as people like to think, and in my opinion this line of thinking is just an excuse to not actually think about what needs to be done to complete a task. You’re probably working on fairly rote easily producible stuff. That’s not a knock for sure - buildings are complex projects but are easily producible and rote, and contain some but not many unknowns. I imagine in modern times (I’ve not tried to do it for about 25 years tho, and it definitely was complex then!) making modern websites and e-commerce stuff is fairly rote and predictable and mostly a design process. Developing something innovative is full of unknowns that can only be determined by trying to do it. Building arbitrary scale SaaS data services, complex cryptographic platforms, more recently AI stuff, all are replete with unknowns. Developing complex business systems as well.
BurningFrog 3y ago
Right. The problem is, as usual, us. We imperfect people being who we are, and doing what we do. And part of who we are is that we blame Jira, because it's so much easier than to fix ourselves.
antran22 3y ago
I agree with your opinion. The problem is that managers have the notion of software estimation as a "craft". It should not be considered a craft at all, and once you held estimation to the importance of being a "craft", it is going to be a massive burden. It should be just a numerical representation of your gut feeling and past team experience. Software engineering always has to account for uncertainty. You may try to deal with it before starting the project (waterfall) or in the process (agile). Management seems to think that by pressuring the team they can just do away with uncertainty and make their strategic planning seems more concrete, and make questionable decisions like publishing untested code. It's a power struggle all the way from the top brass to us lowly devs, but management need to understand that this is always going to bite them in the ass on the long run.

ohthehugemanate 3y ago

So many +1s for you. I want to add that if the team is focusing on the present, it becomes clear that estimation is a passive, descriptive (rather than active, proscriptive) act. No ticket has time pressure on it. The manager predicts the future timeline based on how long similar tasks took in the past, on average. No idea if one task will take 5 or 15 days, but 10 of them will take about 100 days. Once you understand that, there are many very simple ways for a competent manager to get development velocity out without adding work for the developers... and all management actually wants is average velocity and remaining work in similar units. If your team tries to keep tickets about the same size, ticket throughput is your velocity. At most the devs can slap gut instinct Easy/Medium/Hard labels on the tickets so they don't have to "right size" everything. Either of those (or a thousand variants), when coupled with the pile of work left to do (in the present understanding) can give a competent manager high precision long term estimates with confidence intervals. No need to make it more complicated (or time consuming!) unless the devs tell you they NEED more. In my experience, teams that focus on the present, and which are in control of their own process (ie adding or changing only when DEVS feel the need) typically end up evolving their own agile process... which is way more effective than OOTB processes like Scrum, and doesn't feel like a burden (the team drops anything that feels like a burden). Teams who have a process imposed upon them, on the other hand, spend years ranting online about how terrible agile is, and waste a lot of time in unnecessary bullshit.

yunohn 3y ago
> Teams who have a process imposed upon them In my experience, this is the vast majority of cases. Hence: > spend years ranting online about how terrible agile is
- ohthehugemanate 3y ago
  Sad but true. And to make matters worse, those seem to be the same environments where businesspeople make target dates without engineering, and then get angry when the deadlines aren't met. Put another way, poor management is a human layer problem. No technology (whether process or tool) can solve that for you.

yladiz 3y ago

> Software estimation is basically a useless craft. It depends on how you're thinking about estimates. Just saying they're useless is arguably missing the benefit of the process. Estimates are not generally useful in and of themselves (as in, the estimate value isn't particularly useful), but the process around agreeing on the value within a team is. If you're on a team and estimating a task during refinement, and there are wildly different estimates from the different team members, then the definition and/or understanding of the task is wrong and it needs more clarity and discussion. Another thing is that date estimates are problematic, and estimates should more generally be used to estimate complexity, and while they might be linked in some way, they're not the same. The issue with estimates, in my opinion, comes down to the process after the value has been determined. If it's used as a benchmark or metric in some way, then you get into problematic situations. I also do disagree with this: > The reality is, unlike building a building, often the software being built has a ton of unknowable elements that are due to the software being bespoke in many crucial ways. Honestly, software development is not as complex as people like to believe and there aren't as many unknowable elements as people like to think, and in my opinion this line of thinking is just an excuse to not actually think about what needs to be done to complete a task.

CodeMage 3y ago
> Honestly, software development is not as complex as people like to believe and there aren't as many unknowable elements as people like to think, and in my opinion this line of thinking is just an excuse to not actually think about what needs to be done to complete a task. Funny, I've been hearing this constantly over the 24 years of my professional experience as a software developer and I've yet to see it proven true. Unless we're talking about toy examples like Hello World, developing quality software is devilishly complicated and, in my opinion, downplaying this complexity as an "excuse" is in itself an excuse to compromise quality. EDIT: Fixed a few words my phone auto-"corrected" for me.
fnordpiglet 3y ago
I’d say just discussing how a task will be implemented susses out whether it’s understood. Estimation isn’t a useful part of that discussion. Estimation is almost exclusively for the benefit of management is determining when something will be done. I would say if this is true in your work: > Honestly, software development is not as complex as people like to believe and there aren't as many unknowable elements as people like to think, and in my opinion this line of thinking is just an excuse to not actually think about what needs to be done to complete a task. You’re probably working on fairly rote easily producible stuff. That’s not a knock for sure - buildings are complex projects but are easily producible and rote, and contain some but not many unknowns. I imagine in modern times (I’ve not tried to do it for about 25 years tho, and it definitely was complex then!) making modern websites and e-commerce stuff is fairly rote and predictable and mostly a design process. Developing something innovative is full of unknowns that can only be determined by trying to do it. Building arbitrary scale SaaS data services, complex cryptographic platforms, more recently AI stuff, all are replete with unknowns. Developing complex business systems as well.

BurningFrog 3y ago

Right. The problem is, as usual, us. We imperfect people being who we are, and doing what we do. And part of who we are is that we blame Jira, because it's so much easier than to fix ourselves.

antran22 3y ago

I agree with your opinion. The problem is that managers have the notion of software estimation as a "craft". It should not be considered a craft at all, and once you held estimation to the importance of being a "craft", it is going to be a massive burden. It should be just a numerical representation of your gut feeling and past team experience. Software engineering always has to account for uncertainty. You may try to deal with it before starting the project (waterfall) or in the process (agile). Management seems to think that by pressuring the team they can just do away with uncertainty and make their strategic planning seems more concrete, and make questionable decisions like publishing untested code. It's a power struggle all the way from the top brass to us lowly devs, but management need to understand that this is always going to bite them in the ass on the long run.