Has Agile Become Addiction to Instant Gratification?

https://sid-thinketh.medium.com/has-agile-become-addiction-to-instant-gratification-cd0d0bfacb6f

by Garbage • 5 years ago

131 105 5 years ago

sid-thinketh.medium.com

PaulHoule• 5 years ago

I don’t buy that marshmallow experiment.

In an obesity crisis world aren’t you better off eating one marshmallow rather than two?

Comevius• 5 years ago

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.

GDC7• 5 years 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• 5 years ago

I don't really buy the notion of superstimulus?

Why? McDonalds are not that delicious and I make better tasting burgers at home anyway.

shantnutiwari3• 5 years ago

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• 5 years ago

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.

bitwize2• 5 years ago

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.

NAHWheatCracker2• 5 years ago

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.

Zigurd3• 5 years ago

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.

beckingz2• 5 years ago

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.

Zigurd3• 5 years ago

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.

MattGaiser2• 5 years 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.

NAHWheatCracker2• 5 years ago

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.

afarrell2• 5 years ago

Retros which don’t occasionally produce items of investment work that flow into the team’s regular cadence are anemic.

quonn• 5 years ago

It would be better to do retros rarely or whenever requested (when there is a need). But that‘s not what Agile suggests.

shantnutiwari3• 5 years ago

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".

iratewizard3• 5 years ago

I get that waterfall has a bad reputation, but complex, heavily regulated systems are where waterfall projects shine.

Jtsummers3• 5 years ago

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.

shantnutiwari3• 5 years ago

yeah, waterfall has its uses. It's not the evil puppy killer everyone makes it out to be

MattGaiser2• 5 years ago

I can see why waterfall doesn't work, but as a dev, it is pretty nice to have a detailed spec. Covers my ass.

oxfordmale2• 5 years ago

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.

meheleventyone• 5 years ago

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.

social_quotient3• 5 years ago

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• 5 years ago

On the other hand, that's an hour during which none of those managers are bothering programmers.

jcims• 5 years ago

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.

emperorcezar• 5 years ago

Ah yes. They are no true Scotsman.

mbrodersen3• 5 years ago

That’s great! The more time managers don’t interrupt developers the better. Suggest that they extend the standups to 2 hours a day. It will make the developers even more productive (I am only half joking).

mindvirus• 5 years ago

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.

ryanSrich2• 5 years ago

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.

Closi• 5 years ago

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.

UK-Al05• 5 years ago

I mean two of those are agile goals.

Hitting a date by striping features, or a feature with fixed scope but no fixed date.

ryanSrich2• 5 years ago

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.

Zigurd3• 5 years ago

Look for "estimates" in The Manifesto for Agile Software Development and the 12 principles. Spoiler alert...

Jenk• 5 years ago

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.

afarrell2• 5 years ago

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.

lifeisstillgood• 5 years ago

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

tootie• 5 years ago

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.

ChrisMarshallNY3• 5 years ago

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/

carlmr3• 5 years 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.

ChrisMarshallNY3• 5 years ago

If I recall, Toyota was really the company that prototyped a lot of techniques that have informed Agile, and other Lean/JIT processes.

hutzlibu2• 5 years ago

"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.

ChrisMarshallNY3• 5 years ago

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."

dasil003• 5 years ago

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.

KKKKkkkk1• 5 years ago

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.

mycall• 5 years ago

Management is typically easier to change than developers. Dev needs a mental map of everything; mgt, not so much.

dudul• 5 years ago

The thing is management often doesn't realize that.

p1esk• 5 years ago

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.

feoren2• 5 years ago

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• 5 years ago

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• 5 years ago

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• 5 years ago

Well there is a term for those software environments; widget factories. It's derogatory and nobody that can avoid it works in those places.

FeepingCreature• 5 years ago

Bus factor is an engineer term. Easy to tell by how nobody with any sense of social etiquette would have invented it.

simmerup• 5 years ago

Same with ugly words like ‘grok’ and ‘meatspace’

Baeocystin• 5 years ago

Dark humor is common in all fields that butt heads with reality. (Engineers, Doctors, etc) It helps one cope.

wwweston• 5 years ago

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.

yyyk5• 5 years ago

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.

marcinzm• 5 years ago

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.

ncphil• 5 years ago

Yes.

platz• 5 years 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?

yyyk5• 5 years ago

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

bitwize2• 5 years ago

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• 5 years ago

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.

rajacombinator• 5 years ago

Agile is a jobs program for managers.

g051051• 5 years 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• 5 years ago

Agile is often instant gratification for management.

mattkevan• 5 years ago

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.

daemonhunter• 5 years ago

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.

Has Agile Become Addiction to Instant Gratification?

Related Stories