Agile at 20: The Failed Rebellion • Hacker News Board

Re: Agile at 20: The Failed Rebellion

#81

Post by paavohtl » Sun, Jul 25, 2021, 6:58 AM UTC

andi999 wrote: post #29

If nobody does something there is a chance it doesn't work. The most problematic point to me seems to be point 3 'customer collaboration'. Does anybody know how to do that in real life? What does the sales team sell then? And more important how do you prevent feature creep from the customers side wanting more and more things during the process? To me I only see this working if you sell working time instead of a produ…

> To me I only see this working if you sell working time instead of a product.

This is what we do at the consultancy I work at - billing is simply based on time & materials. We work from our customer's premises (when there isn't a global pandemic) and we have people from the customer integrated into our team, so customer collaboration is constant and continuous. Feature creep doesn't really happen, because all parties know what the budget is and how much our time costs.

Re: Agile at 20: The Failed Rebellion

#82

Post by underdeserver » Sun, Jul 25, 2021, 7:07 AM UTC

TedDoesntTalk wrote: post #58

forgotmypw17 wrote: post #52

I've seen Agile at a handful of shops, a couple dozen projects. I've seen it implemented well just once... The "scrum master" was a dedicated role, filled by a technically able person, who sometimes helped a little bit with the coding. This individual had read several books and taken a course on Agile. They were sincerely passionate about Agile and wanted to implement it effectively. The "project manager", a DIFFEREN…

This sounds soul-crushing and I hope never to work in such an environment.

It's not.

The time spent in those retrospectives and planning sessions are about the technical aspects - how talks should be broken down, how overall design of interacting components should look like. It's 100% actual work.

I'd take these over another bs "status sync" any day.

Re: Agile at 20: The Failed Rebellion

#83

Post by ipnon » Sun, Jul 25, 2021, 7:09 AM UTC

nerdponx wrote: post #47

disk0 wrote: post #40

Earlier quoted context omitted.

People (read: Twitter users)[0] have discussed the parallels between Maoist/Marxist theory and both Agile and extreme programming—albeit less fever-dreamy [0] A couple of said theory tweets, from memory https://twitter.com/mmabeuf/status/1352450003231506432 https://twitter.com/mmabeuf/status/1323758677099270147

But this is a joke... right? I hope? Side note: I have never actually read anything written by Mao before. That stuff is a very unsettling combination of stone-cold and unhinged. Maybe it's just because we know the "full" history now, maybe it's just the phrasing of the translation. Yikes.

Reading Mao himself is imperative to understanding why China went through the troubles it did. Maoism was the engine of misery in revolutionary China.

Re: Agile at 20: The Failed Rebellion

#84

Post by ipaddr » Sun, Jul 25, 2021, 7:10 AM UTC

hyperman1 wrote: post #70

ipaddr wrote: post #39

Earlier quoted context omitted.

That's a junior approach thinking you know more than your pm and have no respect if they didn't come from your ranks. In the end if you are difficult you become easy to replace.

I'll give 2 examples. One was a CEO who hadn't any technical background, but he knew what ICT could and could not do for his company. One day we rewired all of our network, a massive weekend job. He was there, even if the only thing he could do was pulling network cables out of bags and straightening them. He saw who and what worked or not, he saw where we struggled even if he didn't understand a word of our technica…

That's not a CEO job. His job is to make sure the enterprise is funded and sets a vision.

The first example must be a small company.

2. This sounds like a manager in an enterprise level company

If you choose to work where a multi-level manager structure exists you should give that manager respect because he has to navigate a political landscape that takes certain skills.

Besides managing people and knowing what customers want have nothing to do with knowing your specific skills. Should the CEO know marketing, accounting, legal, etc as well as the experts in their positions?

Re: Agile at 20: The Failed Rebellion

#85

Post by arendtio » Sun, Jul 25, 2021, 7:12 AM UTC

lalos wrote: post #13

Agile got widespread adoptions because of the micromanagement undertone of it, starting with the daily scrum. It's a slippery slope, way to easy to over do. The risk is it starts something to be gamed/incentivized instead of actual progress.

One of the problems with Scrum is that it describes something close to a process (Plan > Dailys > Review > Retro > Repeat), while the Agile Manifesto states 'Individuals and interactions over processes and tools'.

On the one hand, it is the reason why Scrum is so successful in corporate environments, on the other hand it is also somewhat non-agile. That is why I tend to call Scrum the least agile Agile Methodology and a good starting point for Agile transformations.

Just don't forget to keep moving on as your Retros lead you the way.

Re: Agile at 20: The Failed Rebellion

#86

Post by ipaddr » Sun, Jul 25, 2021, 7:14 AM UTC

watwut wrote: post #59

ipaddr wrote: post #39

Earlier quoted context omitted.

That's a junior approach thinking you know more than your pm and have no respect if they didn't come from your ranks. In the end if you are difficult you become easy to replace.

That being said, non technical PM always turned to be bad. Theoretically they don't need knowledge, but practically they do and it shows.

They can turn out fine if you have a strong lead or senior developers.

Re: Agile at 20: The Failed Rebellion

#87

Post by eesmith » Sun, Jul 25, 2021, 7:14 AM UTC

Agile both succeeded and failed because it's defined as "not waterfall."

Since no one does pure waterfall, everyone does Agile.

Even this essay encourages that interpretation: "Everyone in this group had deep experience writing software, and they were all looking for an alternative to documentation-driven, heavyweight software development processes that ruled the day."

Did that "everyone" include Mac development in the 1980s? Or Amiga development? Not from what I've read of the history.

Did it rule the day for the development of gcc, the Linux kernel, Perl, or CPython? No.

I pulled out my 1996 copy of Steve McConnell's "Rapid Development." Page 271 says:

> In addition to providing explicit support for morale, Microsoft gladly trades other factors to keep morale high, sometimes trading theme in ways that would make other companies shudder (Zachary 1994). I've seen then trade methodological purity, programming discipline, control over the product specification, control over the schedule, management visibility -- almost anything to benefit morale.

The Zachary 1994 citation is the book "Show-stopper! : the breakneck race to create Windows NT and the next generation at Microsoft" at https://archive.org/details/showstopperbreak00zach . A quick read (search for 'documentation') shows Windows NT development did not use a 'documentation-driven, heavyweight software development processes'.

And of course oodles of small software projects in the microcomputer and early web era were written with no formal software development processes at all.

This "rule the day" statement must therefore be interpreted within a narrow context.

Re: Agile at 20: The Failed Rebellion

#88

Post by mirekrusin » Sun, Jul 25, 2021, 7:14 AM UTC

AndrewKemendo wrote: post #41

The fundamental problem with Agile is the fundamental problem with all product development: The customer doesn't know what they want Agile assumes as a first principal that including the customer throughout the development process will align the building team and the customer to come to the same conclusion. This is almost never actually true. Having built and managed a lot of products I can state fairly confidently t…

I don't think agile was meant to take everything client says without critical thinking. Quite opposite actually, it encourages dialogue. Often developers know better how to solve certain problems.

Early in my career somebody said something like "make sure you distinguish between > and >.". This thought stuck with me for years and in my opinion has been reposible for success I witnessed.

It's important to unwrap "what they want" so you, as developer, can apply more first principle thinking to arrive at "what they need".

BAs have tendency to project their own solutions, however when unwrapped so you see the problem that needs solving, you may arrive at solution that is simpler (like orders of magnitue is not that rare in my experience), reflects reality better, takes advantage of somehow hidden from BAs PoV system internals etc.

Agile enouraged dialogue is the platform where those ideas can surface.

Re: Agile at 20: The Failed Rebellion

#89

Post by ipaddr » Sun, Jul 25, 2021, 7:19 AM UTC

emptysongglass wrote: post #55

ipaddr wrote: post #39

Earlier quoted context omitted.

That's a junior approach thinking you know more than your pm and have no respect if they didn't come from your ranks. In the end if you are difficult you become easy to replace.

My PM does know more than me. And he's good at directing where the team should invest it's efforts. That's why he's my PM. You seem to have completely missed my point, which is that technical leads and PMs should have domain knowledge and that this is why DevOps is not in danger of failing at competent companies.

I get your point that someone rose from your ranks and you respect them over someone who who has a background in pm but not your product.

That technical pm is a luxury and will move on at some point. You don't need him your team with a strong lead or more senior developers could work with a regular pm and get the job done.

Re: Agile at 20: The Failed Rebellion

#90

Post by forgotmypw17 » Sun, Jul 25, 2021, 7:20 AM UTC

Celeo wrote: post #61

forgotmypw17 wrote: post #52

I've seen Agile at a handful of shops, a couple dozen projects. I've seen it implemented well just once... The "scrum master" was a dedicated role, filled by a technically able person, who sometimes helped a little bit with the coding. This individual had read several books and taken a course on Agile. They were sincerely passionate about Agile and wanted to implement it effectively. The "project manager", a DIFFEREN…

I'd certainly like to be in an environment that has the dedicated people to those roles that so often are either combined or eschewed entirely, but 16+ hours of meetings per sprint sounds incredibly draining.

It wasn't particularly draining, because the large windows allowed a more relaxed pace, ensuring that nothing was missed, and a time for joking around.

And it was not "16+ hours of meetings", but two days of taking a break from coding to do more social work, also having a 2-hour lunch together in the middle :)