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

Agile Lite: Agile without all the burnout

github.com

Post reply on HN
Print view View original

221–230 of 292 posts

Re: Agile Lite: Agile without all the burnout

#221

Post by RandallBrown »

lordCarbonFiber wrote: post #70
RandallBrown wrote: post #59

Earlier quoted context omitted.

Nobody should make estimates. They're always wrong. Do your best to break tasks up so that all tasks are the same size. Then work on tasks. You'll find a stable average of tasks per amount of time and that will let you forecast how long things will take, how much they'll cost, etc. That's how you figure out when things will be done.

That act of breaking up and organizing tasks of the same size , that's what estimation is. This feature has these tasks, historically we complete these tasks in this time, so here's a hard minimum for a completion date (which implies cost). Slap on an appropriate fudge factor for dealing with other teams, testing and burn in, and general error bounds as needed. You've described scrum, what you're doing is scrum.

It's not scrum. There's no sprints or commitments.

Re: Agile Lite: Agile without all the burnout

#222

Post by pferde »

eeZah7Ux wrote: post #168
pferde wrote: post #14

Interesting idea. All I've experienced so far was "Agile Enterprise Edition" - cargo-culting all the agile terms, wasting developer time in overly-long standups, yet having a fixed, set-in-stone schedule and delivery plan. Hilarious.

Spot on. Agile, scrum, standups are just tricks to enforce micromanagement and take agency away from engineers.

Not quite. Agile, when done right, by small-to-medium teams, can be effective. However, whenever a big corporation tries to jump on the agile bandwagon, it turns into nightmare fuel.

Re: Agile Lite: Agile without all the burnout

#223

Post by tootie »

wool_gather wrote: post #202
tootie wrote: post #163

Earlier quoted context omitted.

The number one reason agile projects fail in my experience has absolutely nothing to do with planning session, sprint cadence or estimation. It's because the client was not properly prepared to accept iterative delivery or play their part as product owner. I see a lot of team organize themselves around a well-groomed backlog and set their priorities only to have clients come in and ask for deadlines and fixed scopes…

Ironically, such clients also seem to expect that whatever additions/changes they dream up should be able to be folded in to the plan willy-nilly. Whereas if they accepted an iterative process that would come naturally, without constant re-negotiation or ill will.

They can! That's exactly the point of agile and is how you get them onboard. When clients want a feature that is weird or complicated or whatever, the answer is never "no" the answer is "sure, now tell us where it fits in the priority list".

Re: Agile Lite: Agile without all the burnout

#225

Post by Drdrdrq »

beat wrote: post #131
Scarblac wrote: post #48

Earlier quoted context omitted.

The business wants to know how much feature X is going to cost and when they can expect it. They need to know that, because they need to decide if it's worth it in the first place, or because they need to plan follow-up actions for when the feature will be done. If the developer doesn't make estimates, you're just forcing other people to make their own estimates, that they'll hold you to.

Another bit of wisdom I got from Kent Beck is that there are three basic controls to every project... schedule, scope, and resources. You can only control two of them. And resources are generally fixed at the beginning of the project(1), so most projects are either scope-bound (we must have all these features), or schedule-bound (we must hit this hard date). If you're feature-bound, estimation failure means you'll be…

There is a fourth control of course which comes into play when nothing else will give room: quality. You can take many shortcuts to deliver in time, full scope, with the resources available. But the result will be buggy and/or unmaintainable.

Surprising amount of companies choose this path, I guess most without realizing it.

Re: Agile Lite: Agile without all the burnout

#226

Post by ben509 »

This seems like it repeats the same problem I generally have with most methodologies: it treats planning as being separate from development.

Plans go into (Jesus make the hurting stop) Jira while development goes into Git.

And, okay, all of this requires new tooling, that figures out what your "issues" are based on the state of your source repos.

But... Suppose you were doing (Something Like) TDD and your "planning" was to write a bunch of tests that broke.

Or you're even not doing TDD but you can detect stubbed out code and draw issues from that, possibly by reading related documentation.

And your working set of issues, then, are all the tests / stubs detected in active branches.

(And this needs some logic to clean up the duplicates, and needs to be smart enough to notify people when things finish. And you want smart tests like TestNG that can identify dependencies.)

And it needs to serve aspects outside development; let's say functions that touch the UX must be certified by a designer / tester. That person should be able to digitally sign code (maybe even just a handle and date is enough) and then those changes are known good.

The reason I bring this up is because of a big deficiency in the issue trackers: identifying a new issue is cognitively/technically/procedurally expensive.

One of the big things language designers try to do is make elements lightweight. Python added inline assignment because they saw people would repeat code just to avoid creating a new variable name.

And when we're doing issues, planning out a new issue means setting up a meeting or opening a ticket in Jira and filling out a ton of paperwork, etc.

It seems like it ought to be as light-weight as defining a new test, or writing out a stub function.

Re: Agile Lite: Agile without all the burnout

#227

Post by cromulent »

JohnFen wrote: post #179
hopler wrote: post #100

Earlier quoted context omitted.

"commitments" do not exist in Agile. Agile was created to remove commitments and insert collaboration in it's place. You don't have to make big promises when your client has ongoing clear visibility into your progress.

That is technically be true, but I've worked at four shops that have implemented Agile methodologies and it hasn't been true for any of them, nor for most of the engineers I personally know but don't work with. I do personally know one person who works on a team that this is true, but he's the only one. This may be doing Agile wrong, but if something can be so easily done wrong that it's common, I count that as serio…

agile is not a methodology though - it's a set of principles. Many so-called "Agile methodologies" put structures in place that prevent agility.

Re: Agile Lite: Agile without all the burnout

#228

Post by andmarios »

sailfast wrote: post #3

As a developer, seeing another developer suggest that they just take a vacation and leave the project leads and stakeholders to talk about what should be done in a month is really weird. That will not lead to the absence of a death march - it is a recipe for a death march. Not only will you not have an accurate assessment of the tasks but they will not be ordered correctly, and likely way overscoped for the timeframe…

It says that the sprint planning takes about 45 minutes. What I take that this means, is that there is a backlog with stories and tasks which was created and refined by the dev team. These stories include specifications, estimates and more.

So what the project leads actually do, is to decide which of these backlog items will get into the sprint. That's all.

Re: Agile Lite: Agile without all the burnout

#229

Post by jdauriemma »

JohnFen wrote: post #179
hopler wrote: post #100

Earlier quoted context omitted.

"commitments" do not exist in Agile. Agile was created to remove commitments and insert collaboration in it's place. You don't have to make big promises when your client has ongoing clear visibility into your progress.

That is technically be true, but I've worked at four shops that have implemented Agile methodologies and it hasn't been true for any of them, nor for most of the engineers I personally know but don't work with. I do personally know one person who works on a team that this is true, but he's the only one. This may be doing Agile wrong, but if something can be so easily done wrong that it's common, I count that as serio…

I'd push back on calling Agile a methodology. [The Agile Manifesto](http://agilemanifesto.org) a set of ideals, that's all. These ideals often run afoul of conventional wisdom in traditional management/business/sales circles, so we end up with a set of procedures masquerading as "Agile" in order to not upset prevailing sensibilities.

Re: Agile Lite: Agile without all the burnout

#230

Post by jdauriemma »

LifeLiverTransp wrote: post #90
EngineerBetter wrote: post #24

If you're getting burnout doing agile, you're doing agile wrong. Don't do sprints. Have a continuous backlog. Don't do overtime. Don't make estimates. Always do the simplest thing. Only ever do the most important thing, as defined by the stakeholder. I've written and talked about this at great length. The fact people suggest agile gives you burnout reinforces my experience that Scrum is largely misinterpreted and peo…

Its never the wrong socialism. Maybe actual agile as imagined is incompatible with captialsim and human nature?

Agile was created to sell software to clients, so I think was intended to be very compatible with capitalism.
Post reply on HN