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

111–120 of 174 posts

Re: Less is more agile

#111

Post by beny23 »

duncan-donuts wrote: post #29
bracketslash wrote: post #26

Earlier quoted context omitted.

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 te…

The worst thing about Agile is the commercialisation that came with agile training coaches and certifications. It always boggles my mind when realising how many people think “agile” means sprints, backlog grooming, Fibonacci sizing or planning poker and not what’s in the manifesto.

When you take it back to its roots and cut out all the Scrum or SAFe nonsense and adapt it to your team it can really work.

Note, I’m not saying estimates are bad per se and can imagine teams for whom it does work, but it would have to be something that the team is happy with not an impose-from-above methodology…

Re: Less is more agile

#112

Post by beny23 »

lkrubner wrote: post #47

The only practice that I've found to be reliably agile is simply having more one-on-one meetings and less large group meetings. Large group meetings tend to waste time for at least some of the people in the group. Often, if you get 8 people together, most of the conversation is between 3 or 4 of those people, while the other 4 or 5 are bored and disengaged. One on one meetings tend to be productive since the meeting…

I’m not a fan of ceremonies/rituals and always have to laugh when looking up the dictionary definition of ceremony/ritual which implies something that gets because “we’ve always done it” but is actually pointless. Pretty much on the nose. If something is useless, then change it!

Re: Less is more agile

#113

Post by valenterry »

teeray wrote: post #39

Everything in my experience aligns with what this post states. The best teams had processes that they developed themselves, organically. However, there is a very real, pressing need from middle management to answer “what’s going on with X” when upper management asks. “I don’t know” is not an answer and neither is “we don’t know when it will be done.” These conversations ultimately control the flow of funding. So we m…

Yes that's right.

What's missing here is that this doesn't come for free. Requiring to always be able to get information about "what's the progress" without delay means that someone must constantly calculate the current progress. And this is difficult and requires a human that can estimate all the things, including resources (will a dev get sick next week?) and delays from other teams, external blockers and their chance of happening (will the clould environment fail again this week?) and so on.

If this is desired (it may well be) a resource for this has to be planned and implemented _in advance_. That costs a lot of money. And even then, it can just give an estimate in the form of a probablity curve.

If the management has not planned for this, they can either not expect to get status information all the time but have to request it, then wait for it to be calculated and have to accept it will delay the project by the time it takes to calculate it. Or they have to live with an extremely vague and unprecise estimation.

And unfortunately, all methods, be it SCRUM, v-model xt or a randomly assembled method, will not automatically calculate a good estimate. Otherwise no one would complain. :)

Re: Less is more agile

#114

Post by beny23 »

zogomoox wrote: post #92
lkrubner wrote: post #47

The only practice that I've found to be reliably agile is simply having more one-on-one meetings and less large group meetings. Large group meetings tend to waste time for at least some of the people in the group. Often, if you get 8 people together, most of the conversation is between 3 or 4 of those people, while the other 4 or 5 are bored and disengaged. One on one meetings tend to be productive since the meeting…

Group meetings, the next exponent of that is SAFe (so called Scaled Agile Framework) where you'll see 2-day-long meetings with 80+ people. I am not a fan.

I think Martin Fowler said it best: SAFe is “Shitty Agile For enterprises”

Re: Less is more agile

#115

Post by O__________O »

Agile is a way being, not a thing to be.

For the majority of people, they just want to know what to do and expecting them to “become agile” is like asking them to change their beliefs related to politics, religion, etc. — AND more importantly, practice them.

If you want to become more agile, focus on improving yourself and finding others that align to what you feel is agile.

____

* Personally, to me, Boyd’s OODA model of agility is the the most adaptable. Problem is it’s not a check list and requires you to internalize is. For example, most people think being agile is always about speed, but it’s not, it’s about dynamically controlling yourself in to optimally control what is not yourself; sometimes most agile thing to do is be slow, or even do nothing — to see what happens, force someone else to act, etc. People that to me felt the most agile are the ones that enjoy being agile all the time and playing agility games.

Re: Less is more agile

#116

Post by MiyamotoAkira »

xlii wrote: post #93

I'm seeing a lot of people making Agile something it isn't/shouldn't be. There's a difference between core Agile (as in Agile Manifesto) and one of the many commercial imagination of it. Agile wasn't meant for project management but instead as as a tool to organize work in development teams and respond to situation arising in such landscape. It was "weaponized" by business but (at least from my experience) everything…

That last example, as you recognise at the end, was an agile flow, as per the Manifesto, they found what worked for them well. However they wanted to call it.

Any other flow in which management wants to standarized the process, fails at agility. I don't consider those Agile. Just because I call the fruit Orange Blue, doesn't make it so.

Re: Less is more agile

#117

Post by beAbU »

xlii wrote: post #93

I'm seeing a lot of people making Agile something it isn't/shouldn't be. There's a difference between core Agile (as in Agile Manifesto) and one of the many commercial imagination of it. Agile wasn't meant for project management but instead as as a tool to organize work in development teams and respond to situation arising in such landscape. It was "weaponized" by business but (at least from my experience) everything…

The big mistake you're making is capitalizing the word "agile".

At $WORK we are agile as a software team, but we don't practice Agile. It's a subtle but important difference imo.

Unfortunately the word "agile" has picked up some baggage over the years that means to many folks the word translates into a rigid framework of practices, philosophies and ceremonies. This to me is the total antithesis of what being agile really means.

Re: Less is more agile

#118

Post by beny23 »

quickthrower2 wrote: post #59
ineptech wrote: post #42

I generally agree, couple observations: 1. If the people on the team can't change the process, it ain't agile 2. Sprints aren't a failure of agile, they're a failure of devops. Once you start deploying multiple times a day, nobody will care when one sprint ends and the next begins and it'll be fine 3. Estimates aren't literally the devil, execs need to have a rough idea how big it is, just don't get more granular tha…

Point 2, even with CI/CD multiple times a day, with zero flaky tests and a sweet build time and automated test time, it sounds like you still need almost zero time between the final git push and merge to $BRANCH causing a deployment. What about review? Code review? QA? Showing off to stakeholders? These things add a delay, and there is a 'crunch' around the end of sprints where things are artificially urgent. I am no…

Sounds to me that the artificial crunch is the problem. And if you have the capability to deploy quickly, I don’t see any value in sprints they tend to artificially delay deployments, reviews or retrospectives. If something needs talking about, don’t wait for a ceremony in a week and a half when everyone has forgotten about it.

I’ve been part of teams working this way without sprints and artificial crunch on mature and large scale services, so it really isn’t a MVP/startup only deal…

Re: Less is more agile

#119

Post by MiyamotoAkira »

quickthrower2 wrote: post #59
ineptech wrote: post #42

I generally agree, couple observations: 1. If the people on the team can't change the process, it ain't agile 2. Sprints aren't a failure of agile, they're a failure of devops. Once you start deploying multiple times a day, nobody will care when one sprint ends and the next begins and it'll be fine 3. Estimates aren't literally the devil, execs need to have a rough idea how big it is, just don't get more granular tha…

Point 2, even with CI/CD multiple times a day, with zero flaky tests and a sweet build time and automated test time, it sounds like you still need almost zero time between the final git push and merge to $BRANCH causing a deployment. What about review? Code review? QA? Showing off to stakeholders? These things add a delay, and there is a 'crunch' around the end of sprints where things are artificially urgent. I am no…

Separate deployment from release (Feature flags). Then you can do QA and show to stakeholders whenever in whichever environment. You can even use it for Code Review, though I prefer pair/ensemble programming to CR (better to correct things as you go than after the fact)

Re: Less is more agile

#120

Post by beny23 »

thayne wrote: post #23
peteradio wrote: post #6

Earlier quoted context omitted.

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.

I used to work in banks where you had teams of architects create high level design (HLD) docs that get turned over to the design team to produce low level designs (LLD) that the get turned over to developers how are meant to write the code, then to be turned over to the testing team. With massive handover meetings at every stage and forests of paper for milestone documentation that had to be signed off.

Never had my soul be destroyed as completely and I seen such a massive waste of time and money.

Post reply on HN