Earlier quoted context omitted.
What's stupid in wanting to get an idea of how much a project costs in order to decide if it's a good idea to pursue, let alonr allocate resources?
Nothing, inherently, except perhaps the fallacy of comparing a pair of jeans to the rather chaotic and unpredictable world of bespoke systems development. One is inherently known (a pair of jeans you've presumably already manufactured), the other is one big unknown, basically.
Dear Agile, I’m Tired of Pretending (2018)
61–70 of 420 posts
Re: Dear Agile, I’m Tired of Pretending (2018)
#62Agile never gave organizations a holistic, viable alternative to Waterfall. Because there’s a difference between theory and practice. Product work is more about practice. When we complain about “AINO” (Agile In Name Only), we’re not being honest with ourselves. I agree with most of the article. Specially the keep-learning part. All Agile did was put software development teams unfairly under a microscope. I believe Ag…
I was interested in comp sci precisely because I didn't have to talk to people, an area where every interaction is a performance. I want to be alone - what's so wrong with that?
You need to talk to people to be able to produce the software they need, ultimately.
Re: Dear Agile, I’m Tired of Pretending (2018)
#63You don’t hear the name Joel Spolsky much any more, but he was pretty influential in software process thinking in the 90’s - not really for being particularly insightful or original, but more because he was one of the first people who thought of writing a blog about software design. One of his early “observations” about software project management was that “you wouldn’t buy a pair of jeans without knowing how much th…
That's one of the big reasons that I've become a proponent of Donald G. Reinertsen's approach to product development. He emphasizes a variation of the cost benefit formula + urgency, called Cost of Delay for prioritizing that basically boils down to "Value / Time Remaining" because your cost is the time remaining. It naturally prioritizes work based on shortest time to value because, unless the value proposition is e…
Tech Debt is not little, or we wouldn't carry it around, rather than devote time (and risk of revealing new unknowns) to fixing it. My agile experience has always favored conquering little stuff first, since ppl recognize stories more than points (which vary in value, over time). This, unfortunately, sometimes leads to the hilariously subversive act of splitting a story up into as many tiny pieces as possible so that some people may inflate that "What have you done for me lately" list while more tangible coding is done by others.
Re: Dear Agile, I’m Tired of Pretending (2018)
#64Earlier quoted context omitted.
That's one of the big reasons that I've become a proponent of Donald G. Reinertsen's approach to product development. He emphasizes a variation of the cost benefit formula + urgency, called Cost of Delay for prioritizing that basically boils down to "Value / Time Remaining" because your cost is the time remaining. It naturally prioritizes work based on shortest time to value because, unless the value proposition is e…
> including tech debt Tech Debt is not little, or we wouldn't carry it around, rather than devote time (and risk of revealing new unknowns) to fixing it. My agile experience has always favored conquering little stuff first, since ppl recognize stories more than points (which vary in value, over time). This, unfortunately, sometimes leads to the hilariously subversive act of splitting a story up into as many tiny piec…
He also doesn't place any type of value in points or other, bluntly, useless metrics for measurement. The entire focus is around delivered value. You can break it into however many stories you want, the value is the same. The measurement of how many things you delivered or how much time they took is not important to the company.
What's important is how much value was been delivered to the company. It's the only metric that matters.
Re: Dear Agile, I’m Tired of Pretending (2018)
#65I was prepared for our weekly "I Hate Agile" post, but this one is actually really great. It's a lot of the arguments I make to Agile haters. The fundamental problem that drives most agile failures isn't in the team's execution, it's in the business' expectations. One side is signed up for incremental delivery, and one side is set up for a fixed scope and deadline and the result is misery. I think this article makes…
Re: Dear Agile, I’m Tired of Pretending (2018)
#66Agile never gave organizations a holistic, viable alternative to Waterfall. Because there’s a difference between theory and practice. Product work is more about practice. When we complain about “AINO” (Agile In Name Only), we’re not being honest with ourselves. I agree with most of the article. Specially the keep-learning part. All Agile did was put software development teams unfairly under a microscope. I believe Ag…
I was interested in comp sci precisely because I didn't have to talk to people, an area where every interaction is a performance. I want to be alone - what's so wrong with that?
I think it's doable; say you are the sole developer of a massively used library. The programmers being your only users - they read the API docs, submit an occasional feature request/bug report.
Re: Dear Agile, I’m Tired of Pretending (2018)
#67And it turns out that it's not unusual for software developers (and consequently software development organizations) to spend more time in the we don't know what we're doing phase than the we do know what we're doing phase. That sucks from a management point of view, but no amount of process is going to make the problem go away. The best you can do is manage the risk. We don't need good processes or methodologies nearly so badly as we just need management enlightenment about how software development actually works.
Re: Dear Agile, I’m Tired of Pretending (2018)
#68I was prepared for our weekly "I Hate Agile" post, but this one is actually really great. It's a lot of the arguments I make to Agile haters. The fundamental problem that drives most agile failures isn't in the team's execution, it's in the business' expectations. One side is signed up for incremental delivery, and one side is set up for a fixed scope and deadline and the result is misery. I think this article makes…
That's just one example of the general value I like to ascribe to "AINO": it gives you a useful mental model of the delta between what you have and a known good process, making it quite easy to name the missing pieces. This usually doesn't make it easier to actually fix their absence, but at least you know where to start with damage mitigation. When waterfall fails, you just throw your hands in the air and say "more of the same".
Re: Dear Agile, I’m Tired of Pretending (2018)
#69Earlier quoted context omitted.
I was interested in comp sci precisely because I didn't have to talk to people, an area where every interaction is a performance. I want to be alone - what's so wrong with that?
There is nothing wrong with that, but careers under capitalism are about _signaling value_. I hope you find a place (or have found a place) where you're appreciated. :)
Re: Dear Agile, I’m Tired of Pretending (2018)
#70I have a theory that commercially successful software development methodologies are like diets: they have to be almost impossible to follow. This ensures that when you fail to lose weight/achieve bug free software, you blame yourself for not following the rules exactly, rather than the rules for not working.
I know such a simple rule is probably causing a lot of you to cringe, but I can very easily fit just about any activity of value you or your team embarks on into that question, and it's a rule the entire company can get behind.