[HN Gopher] Has Agile Become Addiction to Instant Gratification?
___________________________________________________________________
Has Agile Become Addiction to Instant Gratification?
Author : Garbage
Score : 115 points
Date : 2021-09-04 13:06 UTC (2 days ago)
(HTM) web link (sid-thinketh.medium.com)
(TXT) w3m dump (sid-thinketh.medium.com)
| Jenk wrote:
| I have a mildly different perspective, that is also shown in the
| quote about testing infrastructure that I think the author missed
| - it's not so much about instant gratification as it is
| identifying how to see the results.
|
| Take the second suggestion, for example, where the author appears
| to imply that tech debt, test coverage, etc are "2nd rate tasks"
| yet the speaker in the quote addresses this very point about how
| Facebook learned the hardway to ignore such things.
|
| Instead of shrugging shoulders and blaming instant gratification,
| how about taking some measures of the impact that tech debt is
| making? Are you seeing outages as a result? Are you wasting
| resources as a result? What kind of cost savings could you expect
| by fixing it? How many bugs have you released that could have
| been caught by better test coverage? How much time is wasted on
| testing that could be automated?
|
| Those are killer KPIs to measure, and extremely satisfying, in my
| humble opinion.
| lifeisstillgood wrote:
| I am fascinated by _how_ to measure those things.
|
| While its _valid_ to ask devleads to estimate, I want to reach
| into the codebase and get some metrics. Can you label the
| functions that are "techdebt"? When did they run ? etc
| afarrell wrote:
| It takes a lot of time and effort to measure those things.
| Presenting those measurements also requires some political
| skill, since bugs/outages/resource waste can also be
| misattributed to individuals.
| platz wrote:
| > "What about the defect? It is highest priority. And it is
| needed fast. So let's fix it for the short term and add a tech
| debt to fix it permanently".
|
| > I must admit that I have committed this mistake as well.
|
| Is OP implying that the defect is not the highest priority?
| ChrisMarshallNY wrote:
| Good article, but it doesn't really introduce any concepts that I
| haven't heard (or said) already.
|
| There was the line about "not introducing much process and
| structure," as basic Agile principles. I completely agree (and
| have said so, myself[0]), but the issue is that software folks
| (and engineers, in general), don't like "blurred lines." We need
| empirical data, measurable artifacts, concrete results, etc., so
| that "fuzzy logic," (what I consider) "true" Agile really needs,
| is difficult, in practice.
|
| This is why I think that experienced engineers, that treat the
| vocation as a "craft," are often better suited to "true" Agile.
| They understand the ramifications of decisions that need to be
| made quickly (without having to run a formal risk analysis and
| methodology review).
|
| Remember that the authors of the Manifesto were all highly
| experienced and capable engineers. They wrote a document that
| basically chronicled the way that they, themselves, approached
| development.
|
| As for bugs and tech debt; personally, I abhor debt, of any kind.
| That posture has served me very well, in life. Tech debt is just
| another loan shark.
|
| I like to run on what I call "constant beta." The application is
| _always_ what I consider to be "bug free" _(we all know it isn
| 't, but let me have my happy place)_. If I encounter a bug, I
| stop all forward movement, and fix it; even if it is a "small"
| bug.
|
| As you can imagine, this was not something my managers used to
| allow, but, as I no longer have a manager, I do it this way.
|
| It works _wonderfully_.
|
| [0] https://littlegreenviper.com/miscellany/concrete-galoshes/
| carlmr wrote:
| >If I encounter a bug, I stop all forward movement, and fix it;
| even if it is a "small" bug.
|
| Reading through the Toyota production system this is one of the
| things that is recommended for finding issues early before they
| become big issues. Stop the manufacturing line, find out what's
| wrong, fix it, continue.
|
| At the beginning you will be stopping a lot, and I still am in
| awe of the manager that got this technique approved the first
| time, but after a while you will find that you just produce
| fewer bugs by virtue of a) recognizing patterns in how you
| produce bugs and avoiding them, and b) not having to work
| around as much technical debt, these clever workarounds are
| what bites you later.
| ChrisMarshallNY wrote:
| If I recall, Toyota was really the company that prototyped a
| lot of techniques that have informed Agile, and other
| Lean/JIT processes.
| carlmr wrote:
| I think so, but I never saw this stop the process type
| quality thinking from any agile proponents.
| marcosdumay wrote:
| The manufacture Lean and JIT were disseminated by Toyota.
| But the software development things called of Lean and JIT
| aren't exactly equivalents of the manufacture versions of
| them.
|
| I also disagree that the equivalent of stopping the
| production when you spot a defect is fixing your bugs as
| soon as you see them. The equivalent would be something
| more meta, as asking yourself why that bug was created and
| changing the way you work (like in adding a linter rule).
| [deleted]
| carlmr wrote:
| >The equivalent would be something more meta, as asking
| yourself why that bug was created and changing the way
| you work (like in adding a linter rule).
|
| Which is exactly what you do after stopping that
| production line and finding the issue.
| xorcist wrote:
| The very idea that software should be produced by the same
| production techniques we use to manufacture cars is a
| sickness, and the sooner it can be eradicated from popular
| culture the better.
|
| It's everywhere from Lean to that insufferable Mary Sue of
| the Phoenix book. It makes for decent storytelling, but it
| has nothing to do with how any successful software has ever
| been made. There is no assembly line and we do not pause
| it. It is a parable that is actively unhelpful. Lean
| manufacturing was not even invented to develop or design
| cars, so it's purported origins doesn't even make sense.
|
| See also "software is like construction work" which used to
| be popular before. That wasn't useful either, and anyone
| who's seen the construction business knows it's nothing
| like management literature of yesteryear would make it out
| to be.
|
| Sorry for the rant. I don't hate agile. This just happens
| to be a sore spot, comparing software to "a car" is
| intellectually lazy. We should be able to do better. It's
| easy to imagine the day when someone asks why we can't
| design cars the same way we design software. Not the other
| way around.
| dasil003 wrote:
| > _I completely agree (and have said so, myself[0]), but the
| issue is that software folks (and engineers, in general), don
| 't like "blurred lines." We need empirical data, measurable
| artifacts, concrete results, etc., so that "fuzzy logic," (what
| I consider) "true" Agile really needs, is difficult, in
| practice._
|
| This is a good observation, but it's not just engineers: the
| fact is most people don't like ambiguity, and the more it cuts
| across org structure lines the less they like it. This is no
| big deal as long as the org structure lines are well drawn and
| business are covered adequately, however at scale it also
| limits the type of changes that can be done without massive
| pain, and creates a risk when new needs are identified that are
| not well served by the existing structure.
| hutzlibu wrote:
| "The application is always what I consider to be "bug free" (we
| all know it isn't, but let me have my happy place). If I
| encounter a bug, I stop all forward movement, and fix it; even
| if it is a "small" bug."
|
| I have the luxory of no manager either, but I like to move fast
| and not have the cost of context switch, to immediately fix
| every small UI bug or glitch, like I used to.
|
| I rather keep track of them and usually wait, till I drown in
| warning messages - and then I take the time to properly clean
| up and refactor things.
|
| I found out, this way I am more efficient. Because since I
| suffer from perfectionism, I would get lost in fixing and
| improving small things. Now I mostly ignore them and focus on
| the important stuff and only fix things immediately, if they
| are in the way.
| ChrisMarshallNY wrote:
| Believe it or not, I move _very_ fast. In fact, I often have
| to stop, because the rest of the team can 't catch up.
|
| A lot of that, is because I've been writing code for over 30
| years, and a lot of my personal process is "muscle memory."
| hutzlibu wrote:
| I see, we have to do a coding competition at some point ;)
|
| But sure, routine helps. And probably also what you are
| building. I am mainly working on a big project with lots of
| legacy code involved, that is just not right. I cannot just
| fix anything I come across. I would never get the priority
| things of my list.
| rubyn00bie wrote:
| Agile is nothing but mental masturbation for people in middle
| management. Full stop. Anyone who doubts it has simply never
| worked somewhere that functions correctly. Agile does nothing but
| waste people's time under the guise of: being more productive.
| And I have seen it done "well" and it's still dog shit. It's
| plagued by gatekeepers and process... "but that's not agile" I
| hear people screaming. Oh yes, it fucking is, stands become
| silos, retros exist to silence people, and inaction is the only
| constant as shit spirals down the agile toilet bowl.
|
| Here's the rub no one on the business side will tell you: they
| have ZERO way to judge what any of us do. None. So they push for
| bullshit methodologies and measures to avoid constantly panicking
| that they cannot manage you. Agile let's them feel in control and
| important by wasting time through process. That's the whole
| fucking reason it exists in 99% of your organizations. Not
| because it works but because no one in the business side could go
| a day without diapers otherwise.
|
| If there is one giant con in software engineering it's truly
| agile and all the money people waste on it. If someone has some
| sort of agile accreditation, I wouldn't hire them because they
| operate on dreams and bullshit. They're going to be the first to
| get laid off because they offer no value. Not gonna hire them. Is
| everyone who has some sort of agile certification that awful? No
| but I'm not going to bother to find out because I don't care.
|
| God damn, agile "methodology" is truly trash. The reason most
| products are totally shitty and features have no uptake: agile.
| It's not doing agile wrong, it's actually fucking agile that
| causes the problem.
|
| But literally fucking no one has the social capital to go to
| upper management and say "this methodology is madness, we've been
| doing it for years invested X, and it has to stop." You'd just
| get fired.
|
| Agile is no replacement for lacking organizational skills,
| autonomy, or communication but is given to us as one every day.
| In conclusion: fuck, Agile!
| tootie wrote:
| Betteridge's law of headlines. No. I've never seen this be a
| problem. You set a definition of done for every ticket and stick
| to it. QED. If you can't do that, then process isn't your
| problem. It's maturity.
| KKKKkkkk1 wrote:
| Agile is a way for non-technical managers to exercise arbitrary
| power over engineers. Your work is turned into a factory-style
| production line and you're reduced to playing a game of musical
| chairs over yellow stickys with other engineers at the daily
| standup. That the rules are "fuzzy" just underlines the fact that
| the exercise of power is arbitrary.
|
| These fuckers even have a joke about how a bus hits an engineer
| and no harm is done to the project. How inappropriate is it to
| make jokes about a bus hitting your colleagues.
| FeepingCreature wrote:
| Bus factor is an engineer term. Easy to tell by how nobody with
| any sense of social etiquette would have invented it.
| simmerup wrote:
| Same with ugly words like 'grok' and 'meatspace'
| walshemj wrote:
| You know where those come from ?
| Baeocystin wrote:
| Dark humor is common in all fields that butt heads with
| reality. (Engineers, Doctors, etc) It helps one cope.
| wwweston wrote:
| Process (agile or not) always has three goals: legibility,
| scalability, and fungibility.
|
| Both management and devs alike can be concerned about the bus
| factor, which falls under fungibility.
|
| Of course, an organization can have (or lack) humanity beyond
| those three goals. And hire people who have (or lack) the
| requisite humanity to bring to their role. If someone treats
| the bus factor or general fungibility casually, that's a
| problem.
| arglebarglegar wrote:
| yeah bus factor is an engineering term, sorry
| mycall wrote:
| Management is typically easier to change than developers. Dev
| needs a mental map of everything; mgt, not so much.
| p1esk wrote:
| I'm a developer and I often see the opposite: a manager has a
| good mental map of everything, and developers develop
| separate chunks of functionality. Unless you're a software
| architect or a very senior dev, like a team lead, you won't
| see the big picture.
| dudul wrote:
| The thing is management often doesn't realize that.
| yyyk wrote:
| >Agile is a way for non-technical managers to exercise
| arbitrary power over engineers
|
| Agile was explicitly invented by engineers for engineers, just
| look at the history of the original manifesto.
|
| One big problem is that it was built for self-managing teams
| composed only of engineers and established businesses are not
| built like that at all. There are non-technical people which
| are necessary and have legitimate business needs. Some of these
| are managers with power, so of course they're going to (ab)use
| the process to get what they need.
|
| You can either change the structure of the business itself to
| be more Agile-like (good luck with that in an established
| company, especially a non-tech one), or adopt a more realistic
| posture which invariably involve concessions and deviations
| from the Agile model, but ends up better for all involved.
| feoren wrote:
| To be fair, I'm pretty sure the term "bus factor" (also known
| as "lottery factor" for the less morbid version) was invented
| by developers. I use that term all the time, and think a lot
| about what would happen if I were "hit by a bus". Maybe grim
| humor is not your style, but I'd recommend you look past that
| because that complaint is detracting from your otherwise valid
| points here.
| lanstin wrote:
| For a senior, a great way to reduce the bus factor is to
| periodically stop all work in things other people can do.
| (Catch up on your reading, or write that cool code
| transformer you can't stop thinking about or whatever). Hep
| when asked but very passively "why don't you share your
| screen and we can try to debug it" instead of "try again, it
| should work now." It might go really well or might show what
| areas you need to grow the team capabilities, but either way
| you get to know how great the code transformer idea really
| was.
| systemvoltage wrote:
| As a person who has worked on factory-style production line, it
| is not as bad as you guys make it out! Manufacturing is a
| unique beast and tons of new problems to solve. To be fair, I
| worked as a manufacturing engineer and not as a production line
| worker. Is it that bad to work on software tickets? I suspect
| there is a good variety of problems to solve?
| Rapzid wrote:
| Well there is a term for those software environments; widget
| factories. It's derogatory and nobody that can avoid it works
| in those places.
| marcinzm wrote:
| >Agile is a way for non-technical managers to exercise
| arbitrary power over engineers.
|
| I mean, that's because managers do have arbitrary power over
| engineers in most places. No project planning approach will
| ever make that go away if it's true in your org. Blaming agile
| for the inherent broken power dynamic of your company just
| makes it harder to fix the underlying issues.
| Animats wrote:
| Agile is often instant gratification _for management_.
| yyyk wrote:
| Agile these days is more like a particular sort of religious
| cult, where's there's no way to disprove the central mantras and
| there's this eeeevil mythical[0] enemy the cult is meant to
| overcome. The solution is always more of the cult's mantras. That
| said, if some company succeeds with an officially non-Agile
| process, they are still being Agile since they chose the process
| suited for them. So Agile is always right.
|
| The good in Agile:
|
| * Think about your processes and your progress.
|
| * Inefficient processes should be culled.
|
| * Overmanagement is bad.
|
| The bad in Agile:
|
| * Complete ignorance of the legitimate needs of everyone in
| business who is not a professional software engineer (most of the
| Agile mantras are actively harmful here, and are discreetly
| walked back as in this entry).
|
| * Iteration is not a value in itself.
|
| * Programmers should be managed, at least so long as the typical
| corporation has the structure it has, and Agile doesn't provide
| good tools here (at least none that programmers like...)
|
| [0] https://loufranco.com/blog/waterfall-is-a-myth
| NAHWheatCracker wrote:
| Every one of the suggestions at the end of the article sounds
| like music to my ears as a developer.
|
| It's too bad that it's mostly advice to managers who are the
| least likely to read this stuff or take it to heart.
| mattkevan wrote:
| Agile, or at least in the organisations I've worked at, seems to
| be detached form any sense of reality and practiced as a sort of
| religious dogma - according to the Agile coaches, all our
| problems are caused by the fact we're just not Agiling hard
| enough. We just need to expunge our minds of all impure waterfall
| thinking and reach the next level of Agile holiness and all our
| troubles will disappear.
|
| There's also a big push for Lean UX - basically the UX design
| process squeezed into the dev team's schedule. Sounds great, but
| never works well. It's like trying to complete a jigsaw puzzle a
| piece at a time without being able to see the picture on the box.
| g051051 wrote:
| > Agile is sold as a snake oil panacea by the so-called Agile
| leaders and coaches. The landscape is full of hype and
| overpromises.
|
| Absolutely! I'll go even farther and say that Agile is actively
| toxic to software development.
| bitwize wrote:
| Agile is about measuring and tracking, full stop. The difference
| between Waterfall and Agile is that Agile promises short
| iterations and _continuous_ measuring and tracking throughout.
| But the important bit is that everything you do as a developer is
| tracked, recorded, and KPIs extracted from it so the company can
| see if it 's hitting its OKRs and if not, what can be done.
|
| Yeah, I know, that's not Agile according to the Agile Manifesto.
| Forget the Manifesto. You think the CTO approved an Agile
| transformation because of a fucking manifesto? NUMBERS. How much
| money can we save and how much more profitable can we become by
| delivering exactly the software, and only the software, our users
| need with ruthless efficiency? This, and ONLY this, is Agile in
| the enterprise. Shove your manifestos. You have sprint
| commitments you need to fulfill. Get back to work.
| imbnwa wrote:
| The crazy thing is how much time I see spent talking about how
| "web developers" or "Electron" is ruining software when the
| elephant in the room is business, i.e. the market, choosing
| cost efficiency. Michael O'Church repeatedly yelled this from
| the rooftops but no one wanted to hear it.
| [deleted]
| rajacombinator wrote:
| Agile is a jobs program for managers.
| PaulHoule wrote:
| I don't buy that marshmallow experiment.
|
| In an obesity crisis world aren't you better off eating one
| marshmallow rather than two?
| shantnutiwari wrote:
| yeah the marshmallow experiment is too simplistic. I was
| reading somewhere that rather than measuring self-discipline,
| the researchers just measured which kids listened to the adults
| / did what they were told.
| toss1 wrote:
| Yup, as much as I like the idea behind the original analysis
| of the experiment, another likely insight is that it more
| effectively tested for socio-economic class.
|
| For someone in a wealthy and stable environment, it is
| rational to wait 20min for the larger reward, as there is a
| high expectation that the promised event will occur as
| planned. However, in a poor and unstable environment, it is
| often more rational to take the bird-in-the-hand, as there is
| considerable uncertainty about whether the promised 2nd
| marshmallow will actually arrive.
| Comevius wrote:
| The marshmallow experiment is too simplistic, but for millions
| of years we usually were better off eating both marshmallows.
| Now we have supermarkets with products full of sugar. You can
| consume an unhealthy amount of sugar eating a few fitness
| granola bars, half a liter of fruit juice, or a single bar of
| chocolate.
|
| We are especially vulnerable to superstimulus (exaggerated
| signals), which is what makes McDonalds, TikTok or surgically
| augmented breasts so popular. More sugar, more salt, more silly
| faces, more breasts. Even if we don't prefer them our brain is
| drawn to them. They used to be important signals. Youtube video
| thumbnails almost always feature people making faces, TikTok is
| short videos of people making faces. It's a race at providing
| better superstimulus. A lot of our culture these days is a
| constant bombardment of stimulus and we are not especially
| adapted to it.
| kiba wrote:
| I don't really buy the notion of superstimulus?
|
| Why? McDonalds are not that delicious and I make better
| tasting burgers at home anyway.
| Ceiling wrote:
| I suspect the OP would argue that the stimulus you receive
| from McDonald's is not the taste, but rather the variety,
| sugars, salts, ease, etc.
| test6554 wrote:
| By the time someone realizes this they've already bought
| and taken a bite of the burger.
|
| McDonald's is not the best burger. But for the cost, speed,
| and effort involved, it's pretty good.
|
| We could make all kinds of things ourselves but largely we
| don't.
| GDC7 wrote:
| > It's a race at providing better superstimulus
|
| Couldn't agree more. if this trend continues, the only
| possible consequence is drugs becoming a form of art.
|
| When external stimuli won't do it anymore people will seek to
| directly stimulate themselves with chemicals.
|
| I think society would also find out that the risk benefit
| analysis of club drugs and LSD vs. social media and junk food
| is tilted heavily in favor of the former
| [deleted]
| bitwize wrote:
| The marshmallow experiment was originally done on kids. A kid
| isn't going to get fat eating two marshmallows instead of one
| in a trial that's run once, and they're not going to have the
| forethought to decide to eat less rather than more because
| obesity epidemic anyway.
| mindvirus wrote:
| Honestly the best project management I've seen was a well
| maintained document listing high level projects, with named
| owners. Every week or two it got copied up and trimmed by the
| tech lead, and we would talk about it for 20-30 minutes.
|
| For junior people, we'd pair them with a more senior person to
| help break down work but other than that there was very little
| overhead.
| [deleted]
| ncphil wrote:
| Yes.
| daemonhunter wrote:
| I just feel exhausted with scrum. Everything feels like yet
| another status report and "Why isn't it done yet?" I think we all
| may have bit into agile as process that revolutionized process
| because we have this natural tendency to value process and think
| that is getting us closer to if not the product.
| ryanSrich wrote:
| I've used strict versions of agile, as well as a dozen quasi-
| versions. They were all horrible. Both for managers and ICs.
|
| It seems what works the best, as least for B2B SaaS, is driven
| more by building a feature that works, instead of trying to hit a
| date, or stripping the feature down to nothing in order to hit
| that date.
| UK-Al05 wrote:
| I mean two of those are agile goals.
|
| Hitting a date by striping features, or a feature with fixed
| scope but no fixed date.
| ryanSrich wrote:
| Fair enough, but in every instance I've encountered agile
| it's taken on the methodology of stripping away - "ex: well
| we can't build XYZ by date, so we should just aim for X".
| Meanwhile, X is essentially useless without Y and Z.
|
| I also think setting dates makes things go slower. We don't
| use delivery dates at my company. Instead, we have quarterly
| cycles. Whatever gets done in that cycle gets done. We only
| aim to deliver one big feature per quarter, but it ends up
| being 2-3 because we're so conservative. This also takes the
| pressure off of releases.
| Closi wrote:
| Eh, it's all horses for courses.
|
| Sometimes you have to hit a date, sometimes you don't.
|
| Sometimes having something is better than nothing, other times
| unless you have all the functionality it's worthless.
|
| Sometimes you can know all the requirements upfront, other
| times they are ambiguous and require testing and failing.
|
| The only way to be wrong is to pick one methodology and apply
| it to all circumstances. There are times pure agile will work,
| there are times waterfall will work, and there are times that
| neither of these are right and you have to do something else.
| Zigurd wrote:
| Look for "estimates" in The Manifesto for Agile Software
| Development and the 12 principles. Spoiler alert...
| Zigurd wrote:
| Instant gratification is just one pitfall of not understanding
| Agile before you do it. The article has a lot of useful
| suggestions at the end.
|
| A thing that gets lost in a lot of discussions about Agile, even
| the ones like this one that invoke the intent of the Manifesto
| for Agile Software Development, is that there are material
| advantages to Agile over the systems analysis style of project
| planning and management. It isn't just mindfulness over following
| a recipe.
|
| Agile was needed because replanning with complete functional and
| implementation specs, and complete task estimates and coder
| assignments needed for a resource-leveled critical path analysis
| is way too onerous. That lead to not replanning as tasks,
| knowledge, and goals change, which is worse.
|
| There are tools, like having an MVP milestone, doing decision
| tree analysis at key milestones, etc. that are compatible with
| Agile, and there are techniques, especially metrics, that are
| voodoo or just adornments on Agile-as-management-fad. Knowing why
| Agile was needed vs what was used before is key to understanding
| what is compatible, and what is an impediment to agility.
| beckingz wrote:
| Gratification in the form of working software provides business
| value. Sooner is better, for some values of working software.
|
| This insight that replanning is easier with agile methods is
| pretty key.
| Zigurd wrote:
| It is not just easier. Agile avoids assigning people to tasks
| until tasks are started in an iteration, or continuously as
| in kanban style Agile.
|
| This means you give up that beautiful "network diagram" CPM
| schedule estimate with no overloaded resources. But because
| of the nature of most software development projects, it
| becomes a burden, or a lie, within weeks.
| beckingz wrote:
| Yup. Avoiding the overhead of heavy project management
| practices is also great.
|
| Of course, it becomes less great when you start getting
| dependencies between teams and 2 week sprint delays mean
| that it takes months to get something cycled through
| different teams.
| MattGaiser wrote:
| > Doing retrospectives once in a while to slow down and look
| back. Managers and leaders should talk the least in such retros.
| Encouraging feedback sessions within team.
|
| And act upon them. I have sat through so many retros which turned
| out to mostly be about writing a report. Now, retros are
| something I try to get done as quickly as possible.
| NAHWheatCracker wrote:
| Every time I join a new team, I get my hopes up for
| retrospectives. I contribute ideas about how we can improve how
| we work for the first few months.
|
| Then I realize that my suggestions are ignored and "action
| items" never have follow up. I revert to contributing nearly
| nothing. I usually come up with a "what we did better" item so
| that I don't appear completely disengaged from the process.
| quonn wrote:
| It would be better to do retros rarely or whenever requested
| (when there is a need). But that's not what Agile suggests.
| afarrell wrote:
| Retros which don't occasionally produce items of investment
| work that flow into the team's regular cadence are anemic.
| shantnutiwari wrote:
| Agile has become overused and cliched.
|
| My sister works as a project manager at one of the big UK banks.
| They are anything but agile--projects take months and have to be
| planned out to the smallest detail for legal and compliance
| reasons. Makes sense, as the smallest decision affects millions
| of people, and there are regulations to satisfy.
|
| She complains she now has to do daily standups with other project
| managers. But she has no idea what they do, they have no idea
| what she does, and it's a matter of just talking "Yeah, doing the
| same thing I was doing yesterday".
|
| But since there are like 20 managers in just her group, this
| takes an hour everyday.
|
| And she's like--we're not in software, why are they forcing this
| scrum thing on us?
|
| I tried to tell her about the Priesthood the Agile, the Saviours
| of Our Codes, bless them, the Agile Manifesto Priests, but
| decided it would be too much history, so I just nodded and said
| "meh".
| iratewizard wrote:
| I get that waterfall has a bad reputation, but complex, heavily
| regulated systems are where waterfall projects shine.
| oxfordmale wrote:
| The problem is that waterfall is a myth propagated by the
| Agile evangelists. Development waterfalls were not frozen and
| rigid as claimed by Agile advocates, but we're in fact fluid
| allowing certain steps to start before others were finished.
| tonyedgecombe wrote:
| Everywhere I've seen it management had the expectation that
| the requirements were frozen, that the project would be on
| time and costs were fixed.
| oxfordmale wrote:
| This gives a good historical overview:
| http://www.bawiki.com/wiki/Waterfall.html
|
| Wikipedia gives a shorter version:
|
| In fact Royce, known for his 1970 paper from which the
| Waterfall model for software development was mistakenly
| drawn, demonstrated that while the development of large
| software systems required a more thorough approach, there
| was inherent risk in a single-pass sequential approach.
| He proposed an iterative approach and advocated that
| projects should pass through this at least twice.
| MattGaiser wrote:
| I can see why waterfall doesn't work, but as a dev, it is
| pretty nice to have a detailed spec. Covers my ass.
| jrochkind1 wrote:
| Waterfall is indeed the domain of valuing covering your ass
| over producing business value.
| [deleted]
| Jtsummers wrote:
| That's been my world. And no, it doesn't shine. It's the
| worst way to manage a complex project that anyone has
| conceived of short of anarchic project management with no
| plans and no deliberate coordination. Waterfall is a great
| way to fuck up a complex system.
|
| It is unresponsive to change. The smallest ambiguity will
| result in the undesirable outcome of building the wrong
| thing. The only good thing about Waterfall is that
| contractors can make bank on the rework, but their customers
| will be screwed every time.
| greesil wrote:
| So it's better than anarchy? Admittedly it's a low bar to
| clear, but what would you propose as better?
| cjfd wrote:
| Not much planning. Direct contact with the people who use
| the software. Good coding practices, preferably TDD. No
| time pressure. This is pretty much agile how it should be
| in theory but not in practice. Agile in theory is
| actually a very good development process. Agile in
| practice tends to be a bit worse. Waterfall always is the
| hell. My boyfriend is at the moment doing waterfall
| development. He hates it. So much useless paperwork.
| aaaaaaaaaaab wrote:
| Yeah, that's fine for developing the new landing page for
| the company website. Not so much for developing mission
| critical systems.
| cjfd wrote:
| I disagree. Among the things that I listed was TDD. If
| one practices that consistently one can create highly
| reliable software. In fact one might argue that using TDD
| for the new landing page for the company website might be
| overkill. Maybe you do need a bit more planning for your
| 'mission critical system' in order to perhaps attain
| performance goals. However, I will tell you here and now
| that if you just do TDD for your mission critical system
| and you do it well you will already be better than most
| programming going on for so-called missions critical
| systems in many, many places.
| iratewizard wrote:
| TDD is cargo cult.
| cjfd wrote:
| It really is not. TDD is for highly competent
| programmers.
| dragonwriter wrote:
| > TDD is cargo cult.
|
| No, but like any practice that becomes known of outside a
| narrow group of highly-competent, highly-motivated
| experts in the relevant area, TDD can be (and often is)
| cargo cult _ed_. It is thus often the case that people 's
| only practical contact with "TDD" is with a cargo cult
| application of it.
| cjfd wrote:
| This is true. The most important way in which TDD can
| turn into a cargo cult practice is to test every class
| and every method separately. This then turns into the
| testing of implementation details that are very much
| subject to change. It can also lead to the testing of
| trivialities, like 'can the standard library of my
| language still add elements to a container'. One should
| in most cases write tests about somewhat higher level
| properties of a system where the user might actually
| recognize the tests as being about stuff that they value.
| In most cases one would write tests about a small set of
| closely related classes. There should also be tests about
| somewhat larger clusters but there should be fewer of
| them because they tend to be more brittle and have worse
| performance.
| iratewizard wrote:
| And here come the cultists to tell me it's not a cult.
| TDD is at best training wheels for an incompetent junior
| developer. All of the TDD cultists I've worked with in
| the past have needed a lot of extra hand holding in how
| to properly design architecture, how to write more
| legible code and have never been allowed to go anywhere
| near interface design or development.
| iso1631 wrote:
| > So it's better than anarchy?
|
| Sometimes, but in my experience anarchy (which adds some
| business value, in a non specific way) is often better
| than waterfall (which adds none and actually hinders by
| preventing small quick schemes that add value now for the
| promise of value in years to come)
| feoren wrote:
| A small team of smart people all working together with a
| shared goal, a clear vision, flexible roles, open
| communication with subject-matter experts, and a manager
| who acts as a shield against external forces (obsessive
| changes, design by committee) and as a provisioner of
| resources to the team?
| mmarq wrote:
| Amen
| shantnutiwari wrote:
| yeah, waterfall has its uses. It's not the evil puppy killer
| everyone makes it out to be
| meheleventyone wrote:
| It's everywhere now as a management fad. My Aunt works for the
| Environment Agency and has been 'agile' for a few years. The
| mind boggles.
| [deleted]
| social_quotient wrote:
| Without know any details I can easily say 20 managers in a room
| for an hour giving updates is for sure not "agile".
|
| It also contributes to a lot of the other examples in this
| convo chain. Bad agile is bad. Just like bad waterfall is bad.
|
| A key tenant to agile is the reduction of inefficient
| processes. So in the next retrospective I would nominate that
| there are no longer weekly 20 person meetings.
| twic wrote:
| On the other hand, that's an hour during which none of those
| managers are bothering programmers.
| social_quotient wrote:
| True and believe me I get the point... but the scrum master
| job is supposed to play defense so people don't bother the
| dev team.
| jcims wrote:
| It just sounds like a scrum of scrums on a tricky project.
| I'm on a major project now where there are 80-90 people
| across around a dozen workstreams trying to stay coordinated
| on a fast moving project in a highly regulated industry. We
| usually wrap in 20-30 mins but it has definitely taken hour
| in the past just due to the sheer number of interdependencies
| and hard gates.
| social_quotient wrote:
| 20-30 sounds reasonable. And should more in the weeds
| discussion be needed it should become the source of
| specific follow ups.
|
| It's the standing 1 hour meeting where some people leave
| thinking it's a waste of time. The waste is what agile is
| about, or not about. If it's productive, needed, or even
| just healthy then it's appropriate IMO.
|
| Thx for sharing.
___________________________________________________________________
(page generated 2021-09-06 23:02 UTC)