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

121–130 of 174 posts

Re: Less is more agile

#121

Post by redditor98654 »

BlargMcLarg wrote: post #101
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…

>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. I wouldn't describe it as such. Such descriptions are how managers got the idea they can put development teams into their bubbles while restricting their access to assets required, demanding they go through multiple layers of management to get simple things done…

Is this really true? That most teams depend on a separate team for th CI/CD stuff?

I have only worked at AWS and all teams here completely own their deployments and operations. I thought this was how everyone does it.

Re: Less is more agile

#122

Post by he0001 »

Aren’t all business models at odds with agile (agile is one but hardly taught in economics schools, or?)? It sure feels like it, as soon as a agile process gets formalized towards business, it crashes. Execs wants metrics, which gets abused from both sides of it. And to create relevant metrics you need details which just adds to the bureaucracy and slows things down. As there are deliveries to consider and business contracts, management and sales wants hard deadlines to sell. Thus you need to estimate everything to give management an idea if and how relevant something is to do in relation to what needs to be done from a sales perspective. It always ends up in bureaucratic hell because the more formalized something gets, the more data it needs to be accurate and deterministic, which is a goal from management.

Re: Less is more agile

#123

Post by randomdata »

moreira wrote: post #76
ilaksh wrote: post #60

Earlier quoted context omitted.

The managers and executives need to have visibility into git commits and deployments. They should literally be able to see the front end and read the progress on the back end code, along with some simple reports as it goes. If they can't understand that stuff they should not be making decisions. But basically it's a list of stuff done, with proof, and stuff left to do. Then they can see the progress bar moving and ma…

> If they can't understand that stuff they should not be making decisions. That doesn't seem right. As a developer, if I were the CEO of a company, I would not be able to read progress from the legal team, or finance team, or any other team. What's going on with that lawsuit? No idea. Do I know how long it'll take to wrap that up? Nope. I can't understand any of their jargon. I still gotta make decisions about it. I…

In a sufficiently large organization, managers are hired to have technical (or legal, or financial) knowhow and to use that expertise to provide information to the CEO to not take time from those doing the work. Likewise, those doing the work often aren't even permitted to communicate with the CEO.

In a small organization, the reality is that many hats must be worn. That may mean developers play manager to some degree, but also the CEO must be prepared to step into the trenches.

Re: Less is more agile

#124

Post by thejackgoode »

I disagree with “don’t estimate” part. If it’s hard, it doesn’t mean it’s wasted effort. And it’s very valuable to business to know with higher degree of precision how much things cost to develop.

It depends on many things, but from my experience, it’s possible, we went from 40% to 10% margin of error per quarter. When there’s a will, there’s a way.

Re: Less is more agile

#125

Post by jraph »

beAbU wrote: post #117
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 re…

Maybe your software team is just efficient and you lack bullshit processes and broken organization that would prevent you from working.

At this point, we could very well stop using the word agile because if nobody knows or agrees on its meaning, it became a meaningless word.

I understand your point about agile vs Agile but we can't rely on people (not) putting the upper case A at the right place, and even on agreeing on the meaning for these words.

Re: Less is more agile

#126

Post by scombridae »

ineptech wrote: post #70
dfee wrote: post #46

Earlier quoted context omitted.

Point 2 is very interesting. Any anecdata to corroborate?

Sure. I worked on a legacy (monolith, >5 years old, no automated test coverage) thing and managed the teams that turned it in to a modern (microservices, ci/cd, full test coverage) thing. So, kind of a naturally occurring A/B test. Five years ago, we deployed once per sprint, and it was a big deal: the test pass takes this many days, the change management team needs this much time, etc. So quite often, finishing a st…

All you have to say is "rolling release," or "why releasing according to lunar phase is dumb." That you need to explain it the way you did is another example of the bs job creation mindset, aka, agile.

Re: Less is more agile

#127

Post by BlargMcLarg »

redditor98654 wrote: post #121
BlargMcLarg wrote: post #101

Earlier quoted context omitted.

>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. I wouldn't describe it as such. Such descriptions are how managers got the idea they can put development teams into their bubbles while restricting their access to assets required, demanding they go through multiple layers of management to get simple things done…

Is this really true? That most teams depend on a separate team for th CI/CD stuff? I have only worked at AWS and all teams here completely own their deployments and operations. I thought this was how everyone does it.

I didn't say most, but many. And yes, this does happen in plenty of spaces, for no good reason other than management decision. Dev teams own the code, but they don't own the DB, the pipeline, the environment, etc.

It creates a lot of friction and bottlenecks, while keeping developers from improving.

Re: Less is more agile

#128

Post by Aeolun »

redditor98654 wrote: post #121
BlargMcLarg wrote: post #101

Earlier quoted context omitted.

>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. I wouldn't describe it as such. Such descriptions are how managers got the idea they can put development teams into their bubbles while restricting their access to assets required, demanding they go through multiple layers of management to get simple things done…

Is this really true? That most teams depend on a separate team for th CI/CD stuff? I have only worked at AWS and all teams here completely own their deployments and operations. I thought this was how everyone does it.

> I thought this was how everyone does it.

Everyone that has any sense, yes.

Any company with a legacy ops/dba/it team? No. These people are now called devops because it’s trendy, and they have too much political capitsl to suddenly get rid off (plus such fun things as thinking devs are too irresponsible to touch prod).

Re: Less is more agile

#130

Post by Closi »

ilaksh wrote: post #60
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…

The managers and executives need to have visibility into git commits and deployments. They should literally be able to see the front end and read the progress on the back end code, along with some simple reports as it goes. If they can't understand that stuff they should not be making decisions. But basically it's a list of stuff done, with proof, and stuff left to do. Then they can see the progress bar moving and ma…

Why would an executive with access to Git be better at estimating progress than the team doing the work?
Post reply on HN