11 ms·
Has Agile Become Addiction to Instant Gratification?
- PaulHoule 5y agoI don’t buy that marshmallow experiment. In an obesity crisis world aren’t you better off eating one marshmallow rather than two?
- Comevius 5y agoThe 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.
- GDC7 5y ago> 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
- kiba 5y agoI don't really buy the notion of superstimulus? Why? McDonalds are not that delicious and I make better tasting burgers at home anyway.
- test6554 5y agoBy 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.
- Ceiling 5y agoI 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.
- deleted 5y ago[deleted]
- shantnutiwari 5y agoyeah 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 5y agoYup, 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.
- bitwize 5y agoThe 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.
- NAHWheatCracker 5y agoEvery 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.
- Zigurd 5y agoInstant 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 5y agoGratification 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 5y agoIt 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 5y agoYup. 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 5y ago> 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 5y agoEvery 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.
- shantnutiwari 5y agoAgile 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 5y agoI get that waterfall has a bad reputation, but complex, heavily regulated systems are where waterfall projects shine.
- Jtsummers 5y agoThat’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.
- mindvirus 5y agoHonestly 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.
- ryanSrich 5y agoI’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.
- Closi 5y agoEh, 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.
- UK-Al05 5y agoI mean two of those are agile goals. Hitting a date by striping features, or a feature with fixed scope but no fixed date.
- ryanSrich 5y agoFair 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.
- Zigurd 5y agoLook for "estimates" in The Manifesto for Agile Software Development and the 12 principles. Spoiler alert...
- Jenk 5y agoI 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.
- afarrell 5y agoIt 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.
- lifeisstillgood 5y agoI 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
- tootie 5y agoBetteridge'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.
- deleted 5y ago[deleted]
- ChrisMarshallNY 5y agoGood 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/ https://littlegreenviper.com/miscellany/concrete-galoshes/
- carlmr 5y ago>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 5y ago
- rubyn00bie 5y agoAgile 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!
- KKKKkkkk1 5y agoAgile 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.
- mycall 5y agoManagement is typically easier to change than developers. Dev needs a mental map of everything; mgt, not so much.
- dudul 5y agoThe thing is management often doesn't realize that.
- p1esk 5y agoI’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.
- feoren 5y agoTo 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 5y agoFor 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.
- deleted 5y ago[deleted]
- ncphil 5y agoYes.
- platz 5y ago> “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?
- yyyk 5y agoAgile 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 https://loufranco.com/blog/waterfall-is-a-myth
- bitwize 5y agoAgile 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 5y agoThe 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.
- rajacombinator 5y agoAgile is a jobs program for managers.
- g051051 5y ago> 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.
- Animats 5y agoAgile is often instant gratification for management.
- mattkevan 5y agoAgile, 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.
- daemonhunter 5y agoI 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.
- fukmbas 5y agoToo many MBAs and not enough engineers