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

41–50 of 66 posts

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

#41

Post by righttoolforjob »

majormajor wrote: post #31
marcosdumay wrote: post #24

Earlier quoted context omitted.

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.

Where I currently work it's absolutely a process problem (of Scrum). The version of scrum they're running wants you to just get the committed stuff done, and it's irrelevant what it leads to. There is no room for understanding the end goal and making sure you reach it, with a set deadline as well.

You might as always happens attack them for not doing Scrum right, and I'll tell you that's the age-old cry of the agile-folks: you're not doing it right, and nobody ever was.

Fuck scrum, it's not agile, never was and never will be.

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

#42

Post by jesuscript »

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.

Well, who is in the position to change an Agile process in any company? If we have 20 years of using this system, we should have enough feedback from developers and the business to refine what Agile is. I can tell you very few developers have input on the overall process in most places.

It's not evolving into a better system because it's under the new bureaucratic regime of project managers. They are an institution now within the tech industry and are a self preserving entity. It's idiosyncratic for them to change this bureaucracy.

If a developer were to say, "here is what I think about the process that governs me", the governors will laugh you out of the room with a delicate smile and sweet fuck you along the lines of "woah, that's great feedback!".

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

#43

Post by nikau »

simplotek wrote: post #33
jesuscript wrote: post #29

Earlier quoted context omitted.

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

It's because a lot of agile is just plain stupid in real world use.

For example, story points are always being converted back to wall time because in the real world you have resources who can work x amount of hours and you need to plan around that.

What's the point of using an intermediate unit?

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

#44

Post by jesuscript »

expazl wrote: post #17
pan69 wrote: post #3

Earlier quoted context omitted.

That's scrum. Scrum uses agile but agile is not scrum.

Your comment strikes me as a bit odd, let me explain why. Yes you're correct in saying that op was talking about scrum not agile, but "scrum uses agile" is a very confusing phrase. Scrum predates agile by 8 years, so how could it use something that wasn't invented when i was created. Also agile isn't something "to use" since it's not a framework. Scrum is something that you use, since it is an actual framework, and o…

Damn, didn't even know Agile and Scrum had such deep lore.

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

#45

Post by wpietri »

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.

I think your contempt here is not a bad default position, but I think you misapply it here.

I was involved in the movement before the term "Agile" existed. I agree it is now on average horseshit, and have been saying so a long time. [1] But I think that one of the things that hasn't been broadly incorporated what is mentioned here: vigorously pursuing faster feedback loops.

So many places are so top-down and plan driven that their corporate structures and corporate cultures just don't let them take advantage of release-early, release-often approaches. Done right, it is hugely powerful because you get to learn ASAP when you are wrong. But in so many places people essentially don't want to know that. They would rather lose months or years to bad plans and bad practices than seek out the kind of real-world feedback that lets them know when something is wrong. People would rather feel smart and look smart than take the hit and learn from enough mistakes that they become actually smart.

Indeed, I think the reason that so much "Agile" is horseshit is that people reject the most important Agile changes such that they can keep on believing they're doing just great. They just don't want their process rub their noses in the fact that however fast they're going, it's not in the right direction.

[1] e.g., from 2011: https://williampietri.com/writing/2011/agiles-second-chasm-a...

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

#46

Post by wpietri »

nikau wrote: post #43
simplotek wrote: post #33

Earlier quoted context omitted.

> (...) 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. No…

It's because a lot of agile is just plain stupid in real world use. For example, story points are always being converted back to wall time because in the real world you have resources who can work x amount of hours and you need to plan around that. What's the point of using an intermediate unit?

Story points shouldn't get converted back to resource time. They're just a way of ballparking estimates sufficient to let product managers make broad choices, and to help teams keep from getting excessive amounts of worked crammed into an iteration.

So don't use them as an intermediate unit. If you want hours, just ask for estimates in hours. I think that's not a great idea for all sorts of reasons, but if you're in a culture that values output over outcome, you may not have a choice, and clearly plenty of projects succeed with GANTT charts and whatnot.

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

#47

Post by felipellrocha »

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…

> However, which process are you arguing for, in its stead?

You don't need to do any other process. You can just talk to people as problems arise and do that "in stead".

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

#48

Post by majormajor »

ProfMeowsworth wrote: post #36
majormajor wrote: post #34

Earlier quoted context omitted.

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.

Yeah, having running software forces you to prove a certain level of correctness and lets people test against it.

You can call a spec done arbitrarily and it's much harder to test that spec against any number of edge cases; and harder to visibly inspect "do these two specs get along" than "did this API call to this other place succeed?" "It doesn't compile" or "it throws an error" or "it doesn't do what it should" are all much more concrete and force you to confront "we might not understand the problem as well as we thought."

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

#49

Post by wpietri »

righttoolforjob wrote: post #37
ebiester wrote: post #23

Earlier quoted context omitted.

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

> The alternative is to just do what makes sense, without calling it anything.

You argue in favor of not calling things things, and then go on to call a lot of things things. You demonstrate why we need to name things: to talk about them more effectively.

What makes sense to one person may not make sense to another. I agree that each team should decide based what's right for them based on the people and the problems. But to do that beyond the trivial, we need to name things.

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

#50

Post by majormajor »

righttoolforjob wrote: post #41
majormajor wrote: post #31

Earlier quoted context omitted.

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

Where I currently work it's absolutely a process problem (of Scrum). The version of scrum they're running wants you to just get the committed stuff done, and it's irrelevant what it leads to. There is no room for understanding the end goal and making sure you reach it, with a set deadline as well. You might as always happens attack them for not doing Scrum right, and I'll tell you that's the age-old cry of the agile-…

What prevents the committed stuff from going in the right direction? Is it that the business leaders keep changing the direction or that the from the business leaders direction is unclear? Or something lower-level? I was picturing the former in the above convo.
Post reply on HN