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

151–160 of 174 posts

Re: Less is more agile

#151

Post by icedchai »

randomdata wrote: post #123
moreira wrote: post #76

Earlier quoted context omitted.

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

Yes, it definitely varies by org size. I worked in a medium size org and the “dev manager” could not even look at a git repo. In a years time he was never able to set up his dev environment, despite “wanting to get more into the code.”

Re: Less is more agile

#152

Post by twawaaay »

azangru wrote: post #139
twawaaay wrote: post #131

There is a whole industry of selling "Agile" to corporations that is peddling this shit. If you are implementing a set process from a book you are by very definition anti-agile. When I implement agile at companies I don't even call it agile. And the only initial practices are: * transparency -- you can't fix what you can't see * improvement loop -- you need to learn from your mistakes and feed the results into next c…

What you described here is perfectly consistent with scrum, which Holub and Farley ridicule. > feed the results into next cycle Right, so you have a concept of cycles; in scrum these would be thought of as sprints (larger cycles) or single days of work (smaller cycles) > transparency -- you can't fix what you can't see Yep. In scrum, this would would be addressed by daily scrums (transparency and coordination on a da…

Every team and situation is different.

The point of agile is to teach your team to solve problems. To build ability to spot whenever something can be improved and then understand what is expected of them and the tools at the disposal.

An "agile from a book" is just a set of answers to some common problems. Your team will be none the wiser about how to deal with other problems that were not addressed by the book author.

Re: Less is more agile

#153

Post by intelVISA »

disgruntledphd2 wrote: post #103
intelVISA wrote: post #77

Earlier quoted context omitted.

We in tech are the only ones smart enough to fall for all the well-paid productivity sinks, when was the last time your physician had a scrum master?

They'd be called a ward director or something, but equivalent roles do exist in hospitals, which are analogous to enterprises.

Fair, would they have the same frequency of exposure?

Re: Less is more agile

#154

Post by shoo »

scombridae wrote: post #126
ineptech wrote: post #70

Earlier quoted context omitted.

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.

I've worked in a similar environment.

The motivation to batch releases was largely driven by a desire to do full end-to-end integration testing of changes between a number of entangled backend and frontend systems. It often took days to stabilise all the components in the single pre-production staging environment used for end to end integration testing, then run through the test plan. Perform batched end-to-end testing of system was the process bottleneck.

Monthly releases created similar crunch dynamics of changes being delayed by a month if they weren't stable enough to enter the monthly test cycle. Since end to end testing is the bottleneck, you don't want to feed in low quality inputs (rushed changes that are likely to cause issues and then trigger re-tests of the entire slow end to end test process).

I'm not saying this is the best way to do this, it definitely isn't, but there can be some reasoning behind it.

Re: Less is more agile

#155

Post by rufflez »

I understand that 30 years of experience has to count for something, and maybe some people are fortunate enough to be able to work in an environment that is devoid of all the politics that "Agile" leaves in its wake.

My own years of experience have taught me that estimates will always be sought by the customer. They may even shop around for a better price with a different software vendor/low code solution etc.

If the development team doesn't know the estimate, how is management expected to know? Simply put, management will be held to whatever number (of person hours) they provide, and are also expected to keep it low enough to close the deal. Deadlines are part of doing business, no matter how much we try to dance around that fact. This is why management will immediately turn around and convert story points into hours. These guesstimates will then become deadlines. I hate having deadlines for creative work, and would rather not be bothered by them, but they exist nonetheless.

Until you convince your customers to accept "NFC" and still do business with you, Agile will remain a quixotic idea for the corporate world

Can we please not fool the next generation of software developers into believing all this bs?

Re: Less is more agile

#156

Post by beny23 »

rufflez wrote: post #155

I understand that 30 years of experience has to count for something, and maybe some people are fortunate enough to be able to work in an environment that is devoid of all the politics that "Agile" leaves in its wake. My own years of experience have taught me that estimates will always be sought by the customer. They may even shop around for a better price with a different software vendor/low code solution etc. If the…

The problem is that all too often do customers think they know what they want but actually have NFC what they need.

Unless there is a constructive dialogue between the people who build it and the people that want it, it will end disastrously. Just think of all the failed white elephant projects that get “negotiated” on the golf course.

Until there’s an acceptance that being agile isn’t just something developers do but has to be adopted by the whole org, it’s not going to work. I know it sounds a bit dreamy but I’ve worked in big orgs that did agile rather well, so it is possible…

Re: Less is more agile

#157

Post by rufflez »

beny23 wrote: post #156
rufflez wrote: post #155

I understand that 30 years of experience has to count for something, and maybe some people are fortunate enough to be able to work in an environment that is devoid of all the politics that "Agile" leaves in its wake. My own years of experience have taught me that estimates will always be sought by the customer. They may even shop around for a better price with a different software vendor/low code solution etc. If the…

The problem is that all too often do customers think they know what they want but actually have NFC what they need. Unless there is a constructive dialogue between the people who build it and the people that want it, it will end disastrously. Just think of all the failed white elephant projects that get “negotiated” on the golf course. Until there’s an acceptance that being agile isn’t just something developers do bu…

When it comes to money, the person footing the bill will get pushy rather fast. So I am curious how such a process works closer to the business side of the project, even in a big org

Re: Less is more agile

#158

Post by baobabKoodaa »

pjc50 wrote: post #99
chii wrote: post #16

Earlier quoted context omitted.

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

> if it doesn't work for a couple times, you get fired That is .. not a reliable description of the outcomes for management consultants, who can inflict spectacular disasters sometimes and still come out ahead. Largely because they deliver the right magic ritual.

Management consultants run powerpoint decks, not scientific experiments.

Re: Less is more agile

#159

Post by rufflez »

intelVISA wrote: post #77
samizdis wrote: post #8

> Recruiting people does not work by doing laundry lists of questions asked by HR drones that don’t understand context or demand 10 years of experience in a technology that’s 8 years old. Five rounds of interviews, tests and exams where people have to recite algorithms by heart are pretty pointless. I second that sentiment. I've worked in places small and autonomous enough that the office manager would handle the adm…

We in tech are the only ones smart enough to fall for all the well-paid productivity sinks, when was the last time your physician had a scrum master?

What is a scrum master expected to do? Not being sarcastic here, I am genuinely curious

Re: Less is more agile

#160

Post by rufflez »

meheleventyone wrote: post #110
mihaigalos wrote: post #100

I loved this article. Countless times I had to estimate Jira "tickets" (actually called issues in Jira terminology) in hours. To this day, I fail to understand why and I haven't gotten a pertinent answer other than "the business needs it for planning, they're paying us, so you do it." Yet this contradicts at least 2 Agile Manifesto pillars: 1. People and interactions over processes and tools (fostering the estimation…

Businesses want to be able to forecast and goals are often set aggressively and ahead of knowing whether they are achievable. There are three basic levers to wiggle at that point. Money, time and project scope. Money can only really be applied early by staffing up, adding more people to a late project will invariably make it later. Thanks Mythical Man Month. So for anything in flight that looks like it will miss a de…

Indeed. This is the best description of the conundrum of Agile I have read so far
Post reply on HN