Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Less is more agile

beny23.github.io

Post reply on HN
Print view View original

21–30 of 174 posts

Re: Less is more agile

#21

Post by smcleod »

chii wrote: post #16
Surfactant7 wrote: post #2

> Allen described his work as a consultant when he goes into a new organisation: > - First he observes > - Then he would try to identify the biggest problem > - Then he would try change it (i.e. run an experiment) > - Then if that works, run another experiment > - If it doesn’t work, go back It's probably no accident, but this is pretty close to the scientific method.

> - Then if that works, run another experiment > - If it doesn’t work, go back The problem is that if it doesn't work for a couple times, you get fired, or at least seen as incompetent. Management want magic rituals that fixes everything, not the scientific method.

I agree this happens at places with a toxic management culture (one could argue that almost all management culture is toxic).

This can however work in places that are (truly) leadership focused where you A) fail fast and B) clearly outline your intention to accept failure as part of the process of improvement.

Re: Less is more agile

#22

Post by sodapopcan »

peteradio wrote: post #20
sodapopcan wrote: post #14

Earlier quoted context omitted.

That's super interesting and I didn't know this history. However, misinterpreting someone's ideas doesn't make it not real if people are actively practicing them.

The link is the man who coined the term. Would you say waterfall today is strictly adherent to NOT testing code before delivery of subassembly? That's the coiners definition.

No, I'm saying that the article states that waterfall, _as is used today_, was misattributed to the coiner, and that's about all it says. That doesn't mean that waterfall doesn't exist and it certainly doesn't prove that the agile folks invented waterfall to have something hate on.

Re: Less is more agile

#23

Post by thayne »

peteradio wrote: post #6
Ecstatify wrote: post #4

Earlier quoted context omitted.

Could you elaborate?

Waterfall is not practiced, its an ill-defined strawman meant to be the "other wrong way of doing things". At best its a self-deprecating measure meaning the more agile you are, the less you know where you are going, and the more waterfall your project management appears the more you know what you are doing. Is that supposed to sell me on agile? I want the strawman.

I've never worked somewhere that did waterfall. But I did have classes where waterfall was tought as the way to do software development.

Re: Less is more agile

#24

Post by j45 »

An idea I’ve begun to understand better is the the higher the formality.. often the lower the average velocity, experience, capability and trust in and among the team.

Standards, structures and processes are still something I wouldn’t do without, but the configuration or extent can vary based on the team.

Re: Less is more agile

#25

Post by andsoitis »

stephc_int13 wrote: post #19

Agile was a relatively good idea, I welcomed the Agile manifesto with open arms because freaking UML was all the rage at the time. Unfortunately, Agile quickly turned to be even worse than what preceded. Corporate bureaucracy should be fought against at all times and by all means. If you work in software, you are valuable enough to have a say, and a choice about who you work for. Not everything has to turn into a bul…

people > process

creative work requires a different environment than widget-making.

Re: Less is more agile

#26

Post by bracketslash »

stephc_int13 wrote: post #19

Agile was a relatively good idea, I welcomed the Agile manifesto with open arms because freaking UML was all the rage at the time. Unfortunately, Agile quickly turned to be even worse than what preceded. Corporate bureaucracy should be fought against at all times and by all means. If you work in software, you are valuable enough to have a say, and a choice about who you work for. Not everything has to turn into a bul…

What would you recommend as a better alternative?

Re: Less is more agile

#27

Post by zac23or »

> Don't estimate I agree. But in my experience, the real problem is out of the developers' hands:

1. On a project, my team worked hard not to miss any deadlines. it worked, but the project was delayed for other reasons, and the PO told his superiors that the project was delayed because of the development team anyway.

2. On another project, my team didn't need to estimate or have a deadline. BUT at every meeting the boss said the project was behind schedule. WE WERE LATE EVEN WITHOUT A DEADLINE. Total nonsense.

If your boss is crazy, your job has a lot of politics, etc, nothing will work, and this kind of environment loves to embrace Agile methods.

Re: Less is more agile

#28

Post by stephc_int13 »

bracketslash wrote: post #26
stephc_int13 wrote: post #19

Agile was a relatively good idea, I welcomed the Agile manifesto with open arms because freaking UML was all the rage at the time. Unfortunately, Agile quickly turned to be even worse than what preceded. Corporate bureaucracy should be fought against at all times and by all means. If you work in software, you are valuable enough to have a say, and a choice about who you work for. Not everything has to turn into a bul…

What would you recommend as a better alternative?

As little middle management as possible.

Flat hierarchy is an other kind of bullshit, clearly established leadership is important.

When you absolutely need middle management, force them to also do some real work, if they can’t, don’t hire them.

Most of the bureaucracy problems are magically going away when middle management is gone.

Re: Less is more agile

#29

Post by duncan-donuts »

bracketslash wrote: post #26
stephc_int13 wrote: post #19

Agile was a relatively good idea, I welcomed the Agile manifesto with open arms because freaking UML was all the rage at the time. Unfortunately, Agile quickly turned to be even worse than what preceded. Corporate bureaucracy should be fought against at all times and by all means. If you work in software, you are valuable enough to have a say, and a choice about who you work for. Not everything has to turn into a bul…

What would you recommend as a better alternative?

Not op but I’ve worked in Agile™ shops, places that are agile, and waterfall-y enterprise stuff. The biggest difference I’ve noticed between Agile and agile shops is that ceremonies or lack thereof make no difference. Pointing doesn’t matter, extensive grooming doesn’t matter, extensive planning doesn’t matter, sprints don’t matter, etc. Grooming your work does matter but 30 minutes is enough for a high performing team to hash out a week’s worth of work. Planning does matter but it should be kept to high level product goals and nothing more. Sprints should only be used if you have something you’re actually sprinting towards. Most of the time that’s not the case. Points straight up don’t matter.

All of this being said this puts a lot of pressure on product managers because it’s hard for them to express how long something will take. The key here is that even if you do all the ceremonies you don’t really know how long it’ll take anyway.

The only way you can work like this is if you have built up trust from your PM. If you can throw all of the shit away and give the PM what they want they’ll go to bat for you. For agile to work there has to be an incredible amount of trust that every team member is going to do what they say. And the lack of trust is when you get Agile™

Re: Less is more agile

#30

Post by eyelidlessness »

mpyne wrote: post #15
burnished wrote: post #11

Earlier quoted context omitted.

Nope. Waterfall is still used and used correctly in situations where there are large and important contractual or compliance obligations. You wouldn't use an agile methodology in construction, you waterfall the hell out of that. Same for hardware projects where fab times can be very lengthy. I don't blame you for coming to the conclusion you have, but you'd do well to signpost when you suspect something is true vs ha…

> You wouldn't use an agile methodology in construction, you waterfall the hell out of that. On the contrary, Mary Poppendieck has a wonderful presentation she gave on how the Empire State Building was built in record time by literally doing it as a more agile-style construction. https://chrisgagne.com/1255/mary-poppendiecks-the-tyranny-of... Likewise, American manufacturers by WWII had already gotten very good at bu…

I won’t wade into the intricacies of defining Waterfall or whether it has merit, but it definitely should be mentioned that Kanban—a capital A Agile technique which most capital A Agile advocates find unstructured and unpredictable (as in tends towards lowercase a agile)—was popularized by an auto manufacturer, where safety and liability are at least as much a concern as construction.
Post reply on HN