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

281–290 of 292 posts

Re: Agile Lite: Agile without all the burnout

#281

Post by [deleted] »

v-erne wrote: post #259
AlexCoventry wrote: post #249

Earlier quoted context omitted.

Maybe if you're building the n th monitoring dashboard or something. The work I find interesting is inherently uncertain, though.

Sure we all know this, but for business people with money this looks fishy. This xkcd sums up the problem perfectly: https://xkcd.com/1425/ How non technical person can tell the difference between task inherent uncertainty and Your incopetence? They cant that's why they will buy Your competition that will claim there is no uncertainty.

[deleted]

Re: Agile Lite: Agile without all the burnout

#282

Post by vitro »

beat wrote: post #174
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…

I just read a marvelous book called Handmade , by a fine furniture woodworker, and something he says over and over is "Go slow to go fast". The sales pitch to the business for a well-controlled agile process is that it maximizes productivity. Shifting priorities and poor planning undermine the productivity of the development team.

I remember one movie scene where old sniper teaches young one "To be slow is to be precise, to be precise is to be fast"

Re: Agile Lite: Agile without all the burnout

#283

Post by jgust »

chrisweekly wrote: post #113
jgust wrote: post #87

Earlier quoted context omitted.

> Always do the simplest thing. Can you clarify? If you meant "always search for the simplest solution" I agree. If you meant, "always do the easiest tasks" I don't.

Simple != Easy I highly recommend this Rich Hickey talk (transcription): https://github.com/matthiasn/talk-transcripts/blob/master/Hi...

Thanks!

Re: Agile Lite: Agile without all the burnout

#284

Post by droussel »

LifeLiverTransp wrote: post #195
jeletonskelly wrote: post #108

Earlier quoted context omitted.

Would you prefer the centralized planning model of waterfall? Of course none of these systems are perfect, but it's been a major step in a better direction for everyone involved.

What i would prefer, is to take a step back and look at all major interest partys involved, who will deform the development process. If management puts to much pressure on, a good process would give tech and the customer more chances to counter said pressure, to avoid tech debt and badly implemented features. I want a process that reacts to the situation, in favour of the product, in favour of longterm goals - who ac…

"Agile" is a set of principles and values as defined in the Manifesto for Agile Software Development. If how you work contrary to those principles, then you simply are not "Agile", no matter if you call it that.

"Agile" will never fix bad management, nor will anything else for that matter.

Re: Agile Lite: Agile without all the burnout

#285

Post by droussel »

PaulHoule wrote: post #5

The key thing people miss about agile (and project management in general) is that you have to tune the process to the situation. If you look at the PMBOK (Project Management Book Of Knowledge) it is really a comprehensive list of all the things you might have to think about while running a project. All of them are relevant to every project (e.g. hiring, communicating with the public) but some need a lot of attention…

>The timeboxing of planning is also a very bad idea. I worked at a place where we had a timebox of 2 hours for planning but really after that we were nowhere near a realistic plan for the sprint and it would take another 2 or 3 days of knock-down, drag-out meetings that would leave us all exhausted to understand what we had to do. After that the work was mostly downhill, at least the way I saw it, but one of the other team members would consistently burn the midnight oil at the end.

If your backlog is properly groomed and you have sufficient time for planning and the team has the last word on how much it tries to take in, then it works beautifully.

If my team was to have that problem, it would come up during the retro, we would add a few more hours for the planning event, hold more or longer grooming sessions, refuse to plan work which we can not yet estimate because the requirements are not clear, etc.

And btw, your "implementation of Scrum" wasn't working properly; probably because you weren't living up to the Agile principles.

Re: Agile Lite: Agile without all the burnout

#286

Post by plutonorm »

mongol wrote: post #127
plutonorm wrote: post #114

Earlier quoted context omitted.

I can honestly say that in 15 years and 8 companies I have never seen one that respects developers.

What does that mean, really? What is a sign of respect that you find missing?

It's an atmosphere. An air of dismissiveness that is hard to pin down. It comes out in various ways. Dismissal of estimates. Removal of autonomy, micromanaging. Transparent attempts to buy productivity with token gestures like, pizza or beer, when management is at risk of looking bad. Not having retrospectives, if they are held, nothing is ever taken on board and there may be slight eye rolling going on. Fictitious deadlines, that arise roughly every 2 weeks, plucked out of thin air to try and stress everyone out to get them to work harder. Just a very faint whiff of contempt hanging in the air, the developers never really belonging in the company. Like we are interlopers, a necessary evil, like... like an air conditioning unit in a boutique hotel. You cant build it into the wall because it's not a purpose built building and theres no space, but you also cant not have it in the room. So it just kind of sits there clashing with the otherwise well thought through and lovingly created decor. Something to be tolerated but also to be avoided.

I mean developers dont help themselves, they tend to let their desire for purity and craftsmanship get in the way of getting the job done. They over state the case for various development practices and management can sense it. Somehow the two kinds of personality just tend to lose faith in each other and it all unravels, until there is no trust left and all but the thickest skinned developers roll off.

Re: Agile Lite: Agile without all the burnout

#287

Post by joelesler »

y-c-o-m-b wrote: post #141

What we do where i'm at is the perfect amount of "agile" for me. Granted we're a small team, but it's worked VERY well for 3 years now. What we do: - Standup twice a week, never lasts more than 15 min - 1 hour "planning" meeting each sprint where we discuss new stories for the upcoming sprint and assign them points - 2 x 2-week sprints (1 release a month containing work from both sprints), this gives us flexibility f…

This is essentially how I run my team. Very close.

Re: Agile Lite: Agile without all the burnout

#288

Post by BurningFrog »

borski wrote: post #155
BurningFrog wrote: post #107

Earlier quoted context omitted.

> The business wants to know how much feature X is going to cost and when they can expect it. Of course they do. We all want things that are impossible to have. I want to know the AAPL stock price in 6 months. The traditional way to manage this impossibility is that engineering lies about it (they have to lie, because they can't know either), and once people are lying to each other, trust is unlikely to arise. The ag…

Engineering does not have to lie. All this takes is design and specification upfront, a well-defined feature set, and room for error. Also, avoiding scope creep is paramount.

“Walking on water and developing software from a specification are easy if both are frozen.” - Edward V Berard

Re: Agile Lite: Agile without all the burnout

#290

Post by JohnFen »

jdauriemma wrote: post #229
JohnFen wrote: post #179

Earlier quoted context omitted.

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.

I did not call Agile a methodology. I referred to "Agile methodologies", as in "methodologies that are intended to adhere to Agile principles".
Post reply on HN