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

Agile isn’t about speed, it’s about direction

tim.mcnamara.nz

Post reply on HN
Print view View original

31–40 of 66 posts

Re: Agile isn’t about speed, it’s about direction

#31

Post by majormajor »

marcosdumay wrote: post #24
AnimalMuppet wrote: post #15

Earlier quoted context omitted.

But if you can adjust the direction fast enough, you can quickly recover from the wrong direction. That is, it's about speed of adjusting , not just speed. (In sports, it's the difference between speed and quickness.)

Only if you adjust into the right direction, and keep it after the adjustment. Theoretically, scrum was aimed at adjusting faster. But if the adjustments just keep coming, you won't go anywhere.

If the adjustments just keep coming you have a business problem and no "process" will save you.

Re: Agile isn’t about speed, it’s about direction

#32

Post by cassianoleal »

nineteen999 wrote: post #21

It's about whatever some commentator thinks its about this week in order to get blog hits, sell more books, or to appear influential or as a thought leader etc etc etc. Most of us with a brain have looked at it and taken the best parts of what is there and incorporated into our workflow for ourselves and our teams, and dumped the rest. The rest just parrot on the same talking points with a different angle every week.

The problem is that organisations want a magic formula that will solve all their problems. So they buy an off-the-shelf process with no regards to how it even came to be.

Every time I see something not quite working the way it should in an agile environment, I refer back to the manifesto. Anything that feels like it's going more towards "the things on the right", I point it out.

Good managers are willing to listen. Most other engineers either already understand what's wrong or dislike the current processes anyway so are open to trying a bit less of them.

When all else fails or when something feels off, get back to first principles.

Re: Agile isn’t about speed, it’s about direction

#33

Post by simplotek »

jesuscript wrote: post #29
oceanplexian wrote: post #7

I guess the “No True Agile” crowd is as alive and well as they were 10 years ago. When it’s a failure, they always come out of the woodwork to let you know you weren’t doing it according to the orthodoxy. When you point out that it isn’t faster in practice, they gaslight you and claim that was never the point in the first place. In a way it reminds me of a cult. You do a series arcane rituals that have no scientific…

Woah woah woah. Hold up. You mean to tell me that someone just pulled stories, story points, point poker, scrum, and the master of the scrum, burn down charts, spikes, iterations, sprints, and retrospectives ... all out of their ass?

> (...) all out of their ass?

This blend of mindless contrarianism gets tiresome. If this discussion was about hand-writing, you'd be accusing left-ti-right languages of being pulled out of the ass as well just because it's the standard shared by most.

People feel the need to plan work, estimate work effort, and allocate resources to get stuff done. Some people adopted these methods and they get value out of them. Not everyone has the luxury of picking up tickets created by magic and "it's done when it's done".

If you have a better way of doing this then be my guest and use it, but I have a nagging feeling you'd shit on that too just to feel smarter than everyone.

Re: Agile isn’t about speed, it’s about direction

#34

Post by majormajor »

nsxwolf wrote: post #22
sakesun wrote: post #11

For me, Agile is about risk migitation by early knowledge building.

That could apply to waterfall also. You build all specifications and understanding up front, then you implement it to the specification.

My opposition to waterfall is that building understanding through investigation and specifications is inferior as a way to get the finished product you need in the time you want, generally much inferior than building understanding through implementation.

But I've always seen that somewhat orthogonal to team-level processes.

You can "Agile™" or "Scrum™" the shit out of waterfall, after all. Create a ton of tickets for spec writing, etc.

Re: Agile isn’t about speed, it’s about direction

#35

Post by majormajor »

cassianoleal wrote: post #32
nineteen999 wrote: post #21

It's about whatever some commentator thinks its about this week in order to get blog hits, sell more books, or to appear influential or as a thought leader etc etc etc. Most of us with a brain have looked at it and taken the best parts of what is there and incorporated into our workflow for ourselves and our teams, and dumped the rest. The rest just parrot on the same talking points with a different angle every week.

The problem is that organisations want a magic formula that will solve all their problems. So they buy an off-the-shelf process with no regards to how it even came to be. Every time I see something not quite working the way it should in an agile environment, I refer back to the manifesto. Anything that feels like it's going more towards "the things on the right", I point it out. Good managers are willing to listen. M…

It's a similar version of "build vs buy" discussions that happen at every level, from "do we even build an engineering team vs outsource to contractors" to "do we include leftpad or write our own method," and everything in between.

There are people out there with high amounts of resistance to using something someone else hasn't recommended or appeared to vet, at every level.

It's often about trying to manage downside risk vs trying to maximize upside. Orgs where people are more afraid of having someone they can blame than they are motivated to truly excel are going to lean towards things they can pay other people to decide for them.

Re: Agile isn’t about speed, it’s about direction

#36

Post by ProfMeowsworth »

majormajor wrote: post #34
nsxwolf wrote: post #22

Earlier quoted context omitted.

That could apply to waterfall also. You build all specifications and understanding up front, then you implement it to the specification.

My opposition to waterfall is that building understanding through investigation and specifications is inferior as a way to get the finished product you need in the time you want, generally much inferior than building understanding through implementation. But I've always seen that somewhat orthogonal to team-level processes. You can "Agile™" or "Scrum™" the shit out of waterfall, after all. Create a ton of tickets for…

The whole point of Scrum, in my opinion, is to create a working increment in the sprint. That’s the mechanism for managing risk. Finishing tickets for writing specs don’t achieve that. Unfortunately, it’s a common practice though.

Re: Agile isn’t about speed, it’s about direction

#37

Post by righttoolforjob »

ebiester wrote: post #23
oceanplexian wrote: post #7

I guess the “No True Agile” crowd is as alive and well as they were 10 years ago. When it’s a failure, they always come out of the woodwork to let you know you weren’t doing it according to the orthodoxy. When you point out that it isn’t faster in practice, they gaslight you and claim that was never the point in the first place. In a way it reminds me of a cult. You do a series arcane rituals that have no scientific…

Fine. Let's assume that Agile is worse than the alternative. I am willing to accept that. However, which process are you arguing for, in its stead? "Programming, Motherfucker?" Shapeup? (Shapeup gets pretty close to agile in spirit.) Spiral Model? (I am assuming you're not arguing for RUP or others.) Conceptually, I like shapeup. I think spiral model is fine - I'd argue that a lot of "agile" shops are closer to spira…

The alternative is to just do what makes sense, without calling it anything. Junk shit like what scrum has become, for example not discussing technical stuff during standup (why the fuck not? that's what our job is about), artificially splitting stories into 2 week boxes (why the fuck should I break down something that isn't naturally breakable?), why create a card for every thing I'm working on (fucking control freak heaven), etc. It's completely juvenile, gaslighting, cargo cult scientology.

Continuous integration => of course, for me, never worked at a place where it didn't happen and that was before agile was even a thing. If I hopped on a project where it didn't make sense though, I should be free to ditch it.

There is no one way to write software that works for every project and there is no one process that works for every project. Just let the experienced folks decide what to use instead of leaning on some bullshit fixed crap process.

Re: Agile isn’t about speed, it’s about direction

#38

Post by agumonkey »

baby wrote: post #20
oxfordmale wrote: post #10

This quote summarises everything that is wrong with Agile. >> rarely well implemented. The Agile Manifesto was published in 2001, over two decades ago. After all this time, and the involvement of a lot of clever people, even Agile advocates are stating it is rarely well implemented. Doesn't that suggest that Agile, as a management technique, has failed? True Agile is appears to be as elusive as the holy grail.

Isn’t agile just like 5 sentences that are pretty vague? If so what does it mean that it’s badly implemented? That sounds like the “they are not interpreting the bible correctly” type of argument.

I think it was Ward Cunningham who discussed that on a video. People in his group would interpret with nuances and good sense. But the thing became a fad and enterprise world turned it into an accounting exercise.

Re: Agile isn’t about speed, it’s about direction

#39

Post by simplotek »

cassianoleal wrote: post #32
nineteen999 wrote: post #21

It's about whatever some commentator thinks its about this week in order to get blog hits, sell more books, or to appear influential or as a thought leader etc etc etc. Most of us with a brain have looked at it and taken the best parts of what is there and incorporated into our workflow for ourselves and our teams, and dumped the rest. The rest just parrot on the same talking points with a different angle every week.

The problem is that organisations want a magic formula that will solve all their problems. So they buy an off-the-shelf process with no regards to how it even came to be. Every time I see something not quite working the way it should in an agile environment, I refer back to the manifesto. Anything that feels like it's going more towards "the things on the right", I point it out. Good managers are willing to listen. M…

> The problem is that organisations want a magic formula that will solve all their problems. So they buy an off-the-shelf process with no regards to how it even came to be.

I feel we need to take a step back and look at the organizational problem. Is your job to get things done in a team environment or waste time and effort reinventing the wheel of how to organize work in software development projects? If you're there to ship software then you adopt pre-established organizational methods and adapt them to better suit your team and org's needs.

It turns out that planning projects with high levels of uncertainty and frequent changes in goals and requirements is hard, and thus a JIT/dead reckoning approach to planning with all the stakeholders involved provides acceptable results while minimizing uncertainty.

So what are you going to do, if your goal is to get stuff out of the door? Are you going to reinvent the wheel or are you going to get stuff done with standard approaches?

Re: Agile isn’t about speed, it’s about direction

#40

Post by jcutrell »

jfdi wrote: post #14

Well it’s both imo - i.e., agile is about velocity.

Any good process should care about both the vector and the magnitude.

The saddest state of affairs, and most common, is when highly capable people have a high magnitude with an incorrect (or inconsistent) vector, leading them nowhere.

Post reply on HN