[flagged]
This is not 8chan.
Dear Agile, I’m Tired of Pretending (2018)
171–180 of 420 posts
Re: Dear Agile, I’m Tired of Pretending (2018)
#172Earlier quoted context omitted.
> Can we stop pretending we can forecast the unknown Within reason. Ive worked in orgs where there is no estimate at all, and that bring a different set of problems (unbound projects and no work getting done because of the complete lack of pressure). Now you're totally right: software engineers rarely do the same thing (or even similar things) twice, so estimating is somewhere between "very hard" and "impossible". "S…
I feel as you should be able to provide an estimate even if it something that you have not completely done before. One should spend some time to gauge how much of this new thing is really "new" and what parts should be easy to figure out. Then, try to look at resources about those unknown parts, and that should allow to provide a rough estimate. And when road blocks come up just communicate early, and then if PM/boss…
Great! Please let us know when cancer will be cured.
In other words, "I don't know" is sometimes a complete answer. I don't know. Period.
This is supposedly one of the main points of this religion (agile). Some things are unknowable. So you move ahead a bit, and reassess. If you are scrumming, that is usually 2-3 weeks, and don't get me started on that arbitrary limit. But, you try to move forward for a bit, learn something, and then that might
1) let you know enough to know how to estimate
2) give you some information on what not to try next (I tried a, b, and c, and they all failed)
3) give you guidance on what to work on next (d seems promising, I can flesh it out more and see if it still seems like a promising avenue).
You proceed on, and eventually get your hands around the problem, or the person writing checks decides this is not an economical search (because that is what this is, search on a multidimensional surface) and change/delete the requirement.
That's what agile is supposed to be, with a nod to the fact that yes, we can estimate writing a single database query or something fairly well, so in some cases estimates can be useful at this scale.
The bane of my existence is the endless pressure for estimates. I'm doing research; no one has done this stuff before. It is truly unknowable. If it was known it would be in a paper somewhere, and I would merely be implementing that paper. So I get told "break it down into smaller chunks", as if my 30 years of success didn't teach me how to break down problems. Thanks PM that has never coded or produced anything intellectually novel before! I'm surely being dumb and/or obstinate!
I got that written in my previous performance review, that I don't know how to plan and break down problems, because I flatly refuse to play this game. You get punished for trying for hard things. It's nonsense. "I don't know" cannot be changed by insisting on an estimate.
Re: Dear Agile, I’m Tired of Pretending (2018)
#173Earlier quoted context omitted.
> Can we stop pretending we can forecast the unknown Within reason. Ive worked in orgs where there is no estimate at all, and that bring a different set of problems (unbound projects and no work getting done because of the complete lack of pressure). Now you're totally right: software engineers rarely do the same thing (or even similar things) twice, so estimating is somewhere between "very hard" and "impossible". "S…
I feel as you should be able to provide an estimate even if it something that you have not completely done before. One should spend some time to gauge how much of this new thing is really "new" and what parts should be easy to figure out. Then, try to look at resources about those unknown parts, and that should allow to provide a rough estimate. And when road blocks come up just communicate early, and then if PM/boss…
Well here's the thing. Often I'm asked for my estimate in the same meeting I first see the story. I have no way of researching before giving an estimate.
> ... and then if PM/boss don't understand there is not much you can do but probably look for a better gig.
If only it were that simple.
Re: Dear Agile, I’m Tired of Pretending (2018)
#174Earlier quoted context omitted.
"How long will X take?" "I don't know, I've never done X before." "Yeah, yeah. It doesn't have to be perfect analysis, just a rough idea for scheduling. Not written in stone, ha ha." "Uh, a week?" "Okay, great, so if I say 8 days you should have it done by then?" "Yeah, I hope so." "Great, thanks." Day 3: actually doing X requires unforeseen Y and Z which will each take a month. "We need to add Y and Z to the schedul…
Yes. This happens at my shop all the time and it's absolutely terrible. Each sprint starts out positive and ends with panic attacks.
I've solved this by not panicking about software someone else owns. Worked out OK so far. They can fix their processes and expectations (I'll help!) to get more value out of me, or choose not to. Not my problem. Environment gets too toxic, well, see ya, and good luck (you'll need it).
Re: Dear Agile, I’m Tired of Pretending (2018)
#175Earlier quoted context omitted.
> Can we stop pretending we can forecast the unknown Within reason. Ive worked in orgs where there is no estimate at all, and that bring a different set of problems (unbound projects and no work getting done because of the complete lack of pressure). Now you're totally right: software engineers rarely do the same thing (or even similar things) twice, so estimating is somewhere between "very hard" and "impossible". "S…
I feel as you should be able to provide an estimate even if it something that you have not completely done before. One should spend some time to gauge how much of this new thing is really "new" and what parts should be easy to figure out. Then, try to look at resources about those unknown parts, and that should allow to provide a rough estimate. And when road blocks come up just communicate early, and then if PM/boss…
>I feel as you should be able to provide an estimate even if it something that you have not completely done before. One should spend some time to gauge how much of this new thing is really "new" and what parts should be easy to figure out. Then, try to look at resources about those unknown parts, and that should allow to provide a rough estimate.
This isn't personal, just a comment on a way of thinking that is not uncommon: each of those sentences are insane and not based in reality. You may "feel" these things are possible, but that's about as far as it goes. "Just look up all the unknown stuff." OK.
Re: Dear Agile, I’m Tired of Pretending (2018)
#176> let’s stop pretending Agile was some sort of cure all But we won't. That's why snake oil salesmen were so effective: we want to believe in the cure-all. No matter how often you chastise, people'll keep buying it, because they're aspirational. They want there to be greener grass on the other side, and they're willing to try anything to find it. The business doesn't actually care about Agile at all. It just has heard…
I think this is one of the most realistic responses here.
I think it's in most party's self-interest to keep playing the "agile panacea" game.
1. Salesman sells something that doesn't exist, pats self on back
2. Engineers asked to build integration/features on arbitrary timeline
3. Doesn't happen, everybody unhappy
4. Scapegoat needed. Says we didn't agile right. Project Manager hired / Deck of Fibonacci cards bought.
5. Go back to 1
Re: Dear Agile, I’m Tired of Pretending (2018)
#177I've been developing software for over 20 years, and I still can't estimate how long something will take me when I've never done it before. This uncertainty needs to become more than just a stick to beat developers about the head and shoulders with. Most of the time the PMs understand this, but there have been many projects where they just don't get it. I have suffered great anxiety from being forced to give estimate…
Sometimes it's good to give people what they ask for [insist on], even if it does not make a sense.
No anxiety needed.
Then calmly explain that the reason things didn't work out as [they] expected is because in real world things doesn't work the way they want or fantasy about.
Suggest better approach. If they refuse and keep doing [asking] the same thing all over again and expect a different result - then let it be their insanity [or anxiety], not yours.
Re: Dear Agile, I’m Tired of Pretending (2018)
#178I've been developing software for over 20 years, and I still can't estimate how long something will take me when I've never done it before. This uncertainty needs to become more than just a stick to beat developers about the head and shoulders with. Most of the time the PMs understand this, but there have been many projects where they just don't get it. I have suffered great anxiety from being forced to give estimate…
>That's when I knew it was time to leave that team Currently in that situation. My "agile" estimate blew up by a factor of as much as 10, just because the ask was conceptually very simple, even to the domain experts I consulted. And by bad luck the way I was implementing the story it happened that the issues unfolded one-at-a-time, rather than somewhere in the beginning where we could have broken things up into more…
why in the world would you ever use the end of a sprint as a hard deadline?
That's broken from the get-go.
Re: Dear Agile, I’m Tired of Pretending (2018)
#179Earlier quoted context omitted.
There are times when something truly original is being built and it's a valid argument for estimate uncertainty. But a significant portion of the industry is engaged in building CRUD app #237 or Ho-Hum SaaS #17, and a significant percentage of estimates end up wrong because some developer who was bored with his job decided to use a blingy new Javascript framework he had no experience with because he wanted a challeng…
If the software is truly that unoriginal, use something off the shelf. The issue is that in literally every non-toy product I've every been involved in the product owners will always turn CRUD app #237 or Ho-Hum SaaS #17 into something significantly more custom and much more complex. >because some developer who was bored with his job decided to use a blingy new Javascript framework he had no experience with because h…
> The issue is that in literally every non-toy product I've every been involved in the product owners will always turn CRUD app #237 or Ho-Hum SaaS #17 into something significantly more custom and much more complex.
YES! The cost of custom-everything design and bespoke gee-whiz is vastly under-appreciated, IMO. CRUDy Android and iOS apps using built-in widgets and simple color theming? Relatively easy to estimate, and pretty damn fast. Custom-everything, we want both to look pretty similar (so, probably Material-ish given current trends, which you'd think would come for free at least on Android but... doesn't), custom animations everywhere, oh I hate that default date picker on this particular Samsung phone (and sure, it's god-awful) can we customize it, and the designer came up with this layout for this form that requires all kinds of twisty-bendy manipulation to reproduce versus something more straightforward but that's what the "stakeholders" approved so let's do that.
Et c. et c. and pretty soon the app's 10x as expensive (no exaggeration!) because you couldn't live with the easiest-for-the-user-anyway default styles with some custom coloring.
And the Web's at least as bad. Often you're also making your page way less usable and breaking it on certain browser/device combos due to the extra effort you put in to make it "pretty", at great cost.
[EDIT] in fact I've in the past suggested providing design points for "pretty gee-whiz versus not-actually-bad straightforward implementation" to make product owners choose between getting e.g. three normal (and OK-looking but not "pretty") features or one pretty feature in a sprint, to make this cost more visible and give owners on a budget more flexibility in shipping features, but it never caught on—in particular designers hate, hate, hate the idea, I think because it might expose that their work is sometimes (often...) more expensive than it's worth (and vastly more expensive than they're being paid, since it also eats huge amounts of developer time) given you've got some developers with even a hint of aesthetic and UX sense on a project.
Re: Dear Agile, I’m Tired of Pretending (2018)
#180I agree that almost all of the orgs I encountered that were Doing Agile were pretty horrible. On the other hand, I've also been in orgs that were very successful in developing software in a way that we would recognise as being agile. We just didn't make a big deal out of it. And we didn't do standups (most of the time), or 2 week sprints, or retrospectives. We didn't even pair consistently: we split up on trivial stu…
Agile has fallen into the hands of big consultants. Now the focus is on process, with more meetings and presentations than ever before.
Am tired, just dead bones tired of all of it. It's all just this or that money making scheme with guys like me caught in the middle. I despised Waterfall, fell into scrum and in the past ten or so years kinda sorta saw one project where agile basically worked right. The rest has been mostly waste. I've worked on billion dollar systems on down to just little nothings. Doesn't matter, companies are struggling to make anything work. I think there's just too much complexity and they all believe IT solutions can manage that complexity. It's failing like never before while expectations have never been higher.
Message to the Fortune 500: Just get rid of anyone with the title "scrum master" they're dead weight. You were fooled, deal with it. I am trying to move my team over to Kanban right now, but we have all this reporting crap up the chain all designed around CA Rally, the worst productivity tool ever made.