Hacker News new | ask | show | jobs
by UK-AL 4083 days ago
IF teams are using Agile like that there doing it wrong. It's meant to be recipe for collaborative, relaxed, friendly environment. Not a pressured hot house. If your goal is to use Agile to push developers to their limits, you've already failed the Agile Test.

You can twist Agile, based on your vision of good team is. So you have to get the right people to implement it. You have to approach it from the idea of it being a collaborative, friendly, no blame etc for it to work.

I've only ever used estimates in story points to prioritize things(That's why its so abstract), not to monitor and push developers. If I wanted that, i'd use actual time.

The idea of everyone is junior is also bad implementation. It means even the most junior person is capable of contributing using their solution over a senior persons solution. The right idea wins, not the right person. I can understand why this pisses of senior people though.

2 comments

  IF teams are using Agile like that there doing it 
  wrong. It's meant to be recipe for collaborative, 
  relaxed, friendly environment.
I'm at a place where (IMHO) scrum works reasonably well. But some of the scrum language I hear people using kind of invites misunderstandings.

For example, "sprint" evokes runners running 100m at a pace they can't sustain for minutes, let alone weeks or months. And "committing to stories for this sprint" implies it's some sort of failure or emergency if the target is missed - when in truth nobody should be skimping on testing or staying late to get things done.

Yeah, I feel like the language is one of the worst things. A "scrum" is a bunch of sweaty men moving down a field in a pile. The idea of that makes me want to get a different job. I'm attracted to programming because I love sitting in chairs, not engaging in violent pile ups.

I agree with what you said about "sprint," as that is the second worst word in the canon.

And user stories is trying to change the term "feature" so that developers will be more user oriented in their thinking, but the term "story" is disturbing.

I forgot the other one: "epic." I can't put my finger on exactly what it is, but it really disturbs me. It's just too serious sounding, like it's presumptuous to declare any component of your program as "epic" before it is done. I can think of very few software systems or components that I would refer to as epic.

Are you writing the story of the flood? Is it the oddysey, the iliad, the history of your people? No, it's just some crappy new feature that's going to take your team a few months to complete. That is totally not epic.

> It's meant to be recipe for collaborative, relaxed, friendly environment. Not a pressured hot house.

The vast majority of work environments cannot be described as relaxed and friendly (hell, most of them probably aren't all that collaborative). Far more could be described as pressured hot houses.

That's the point. Managers often use management techniques that encourage that. It works if your on simple assembly tasks. I.E Worried if you gonna be fired if you don't make 200 widgets.

Doesn't work if you're on knowledge work.

A lot of people approach agile as its an extension of those approaches. When in fact it was a reaction to it, by trying the opposite approach.

So, what are you saying, then? That Agile isn't suitable for the majority of workplaces?
That those workplaces would fail regardless of any methodology.

That sort of technique would fail regardless when applied to software.

The first thing you do, is not use that approach.