Why do some developers consider Agile development to be nonsense? • Hacker News Board

Re: Why do some developers consider Agile development to be nonsense?

#101

Post by lostcolony » Mon, Apr 13, 2015, 3:41 PM UTC

jackmaney wrote: post #92

lostcolony wrote: post #85

Earlier quoted context omitted.

'PM' - well, there's a problem. We don't have project managers. Product -owners-, yes. But you have a point; a lot of places try to 'be agile', as something the devs do, without also including management. As a number of others in this thread even indicate. Management has to also change, or else there's a mismatch in expectations. As a dev doing SCRUM, we report point totals, and allow the business unit to prioritize…

Fine, "product owner" or "scrum master" or "person who schedules meetings and fiddles with the JIRA board". Whatever. I don't care what piece of jargon you want to substitute in. Let me ask you this: why should any customer or business unit give a flying fuck about your "points"? Customers and business units should have a strong voice in prioritization of tasks, yes. However, in the process of prioritization, an esti…

So what? Let them. They get estimates that are relative to each other (~this~ story will take longer than ~that~ story), and can turn them into time measurements them however they like if they want to; we're not committing to their estimate.

All we're committing to is to deliver what -we- choose to include in a sprint, will be delivered by the end of the sprint. We will choose what is in the sprint based on the prioritized backlog. How they prioritize those things doesn't actually matter to us. They think that 8 point story we pulled in is going to take us two days? Doesn't matter. They think that 8 point story we pulled in is going to take us two weeks? Doesn't matter. They're not the ones deciding how much we can take on in the sprint, nor are they the ones committing to get it done. All we are telling them by our pulling it in is that it will be done by the end of the sprint. And that's what I meant by management has to change; that reality has to be acceptable to them, that getting relative points, to tell them the approximate amount of work (or t-shirt sizes, or whatever) relative to other stories is all we can really tell them, and that we will pull in the prioritized stories based on what we think we can get done. If they don't trust us to do that, and want to micromanage, then -no- development methodology is going to help you, not agile, not waterfall, not -anything-, because you have systemic dysfunctionality.

Re: Why do some developers consider Agile development to be nonsense?

#102

Post by jackmaney » Mon, Apr 13, 2015, 3:42 PM UTC

cmdkeen wrote: post #70

To go through some of the points I fundamentally disagree with: "There is no place for an actual senior engineer on a Scrum team" - There absolutely is, who is peer reviewing the code, working with the BAs to design the architecture, identifying the technical dependencies in the backlog? Scrum is not a methodology for writing code, it is for getting a series of tasks done. All the things a senior dev needs to do on t…

> Scrum is not a methodology for writing code, it is for getting a series of tasks done.

0_0 Y...you didn't just write that, right? I'll be unusually charitable and give you a chance to think again about that sentence up there.

> "The story points are there to track productivity" - Oh noes the people paying you want to know how long the project is going to take to be done.

And yet, points aren't supposed to be translated to time intervals..... (Spoilers: in practice, they are.)

Re: Why do some developers consider Agile development to be nonsense?

#103

Post by tromobne8vb » Mon, Apr 13, 2015, 3:43 PM UTC

lostcolony wrote: post #85

jackmaney wrote: post #73

Earlier quoted context omitted.

"When actually estimating tasks, it's purely point based" The problem is that project managers and other business units don't give two flying shits about points. They want to know when things will be done. PM: "So, how long will it take you to have that new logging system implemented?" Developer: "It's a five point feature." PM: "So....two days, then?" D: "Well, I dunno...it's five points." PM: "Two days it is!" [put…

'PM' - well, there's a problem. We don't have project managers. Product -owners-, yes. But you have a point; a lot of places try to 'be agile', as something the devs do, without also including management. As a number of others in this thread even indicate. Management has to also change, or else there's a mismatch in expectations. As a dev doing SCRUM, we report point totals, and allow the business unit to prioritize…

Oh, I wish it were like this everywhere.

We have Product Owners. And PMs. And Dev managers, and QA managers. It's a giant ball of red tape and regret.

At one point the official 'scrum coach' actually convinced everyone that he had a magic formula for converting points to hours and that he could take the pointed backlog and produce a project plan out of it to produce familiar reports for management.

Everyone says we are doing Scrum, even the agile coaching team. But its really just waterfall done using Rally.

Re: Why do some developers consider Agile development to be nonsense?

#104

Post by jackmaney » Mon, Apr 13, 2015, 3:45 PM UTC

couchand wrote: post #97

jackmaney wrote: post #35

Earlier quoted context omitted.

> The thing is, people are actually really good at relative estimation, it's absolute estimation that we completely suck at. That's the idea behind estimating in points: you free yourself from trying to think "how long will this take me?", which you'll inevitably get wrong, to "is this harder or easier than this other thing" which almost always is pretty easy to do. That sounds great on paper. However, every implemen…

You're right, eventually you have to convert points to some notion of time, if only so that you know how much work you can do in a sprint. The idea is that you make that conversion based on past observation, using a velocity estimate that represents the past performance of the team and takes into account who's on vacation this week. There also should be an open recognition that your actual velocity will vary somewhat…

In every implementation of agile that I've ever seen or encountered, something like this occurs:

"Okay, this story for Feature X, how many points should we give it?"

"Well, it'll probably take N days, so, let's say, M points."

Eventually, for the sake of consistency, a rough translation between points and time intervals is established.

Re: Why do some developers consider Agile development to be nonsense?

#105

Post by lostcolony » Mon, Apr 13, 2015, 3:49 PM UTC

jackmaney wrote: post #90

lostcolony wrote: post #89

Earlier quoted context omitted.

They don't, however, involve everyone. The standup does. That's key. If person A needs to talk to person B about an issue, and it's done in standup, it wastes person C, D, etc's, time, even though they don't need to be involved. Doing it with just the required people is, obviously, required anyway, and the problem a lot of people doing agile have is they end up wasting everyone's time by bringing it up during standup…

A 45 minute meeting that spawns off of a 15 minute meeting is still a total of 60 minutes of meeting time. And yes, while that 45 minutes involved fewer total people, that doesn't mean that others won't have spin-off meetings of their own.

But that 45 minute meeting had to happen anyway, apparently. It wasn't scheduled or mandated, it was decided by those two people it needed to happen. Meaning regardless of process, it was necessary. The issue is a lot of people seem to see "standup requires everyone", and "communication should happen", and conflate the two to "every meeting requires every person", which just is not the case, and then as they see all their time is taken up by pointless meetings they didn't need to attend, they blame agile. I've seen the same mistake in waterfall development shops, and people blamed the process there too, even though it's really just cultural.

Let me give you a specific example.

Persons A-H have a standup. It's 15 minutes.

Afterwards, A needs to talk to C about something, which will take 45 minutes. B needs to talk to D about something, which will take 45 minutes. F needs to talk to both A and H about something, for 45 minutes.

A talks to C, while B talks to D. Then A talks with F and H.

Total time taken (excluding the 15 minute standup) -

A - 90 minutes B,C,D,F,H - 45 minutes E,G - 0 minutes.

This is exactly what should have happened -regardless- of your process; these are meetings where only the required people are involved, no one's time is wasted.

What often ends up happening when you hear about day long status meetings and other such terribleness, is after the 15 minute standup, they go straight into discussions, with the entire team. That is -

A talks with C, with everyone still present. Then B talks with D, with everyone still present. Then A talks with F and H, with everyone still present. For a total time of 135 minutes (again, excluding the 15 minute standup). Meaning that -everyone lost 135 minutes-.

Now, if you're claiming that A never actually needed to talk to C, and B never actually needed to talk to D, and A never actually needed to talk with F and H, then that's an organizational problem that is, again, unrelated to agile (or waterfall, or anything else). You simply have people who insist on wasting others time, and regardless of your methodology you're going to run into that issue.

Re: Why do some developers consider Agile development to be nonsense?

#106

Post by couchand » Mon, Apr 13, 2015, 3:49 PM UTC

kabdib wrote: post #98

couchand wrote: post #48

Earlier quoted context omitted.

If you ask someone, "How long is it going to take you to finish designing and implementing that gozzlewog?" they won't have the foggiest idea. That's technically true but not useful. There are much better questions to ask, namely: - Will gozzlewog or foofaraw take longer to implement? - Is the difference minor or is it an order of magnitude? - Will shipping gozzlewog or foofaraw make a bigger impact on the business?…

Can't tell if serious or not. If a gozzlewog is something you haven't done before (and maybe nobody has done it) then you have much less data to go on. Coming up with an estimate for it can be really, really hard. Want to decompose it and estimate from there? Hey, you just fell into the trap. I wish I had a dollar for every time I've heard someone say "That turned out to be harder than I thought." And this is nearly…

Here's the thing: by the time you really know how long a feature will take to develop, you've done it. Until then you need to operate on an estimate. EDIT: I see you edited your comment to include the same sentiment while I was replying. Cheers!

People are bad at estimating, particularly if they're doing it alone, don't have much information or are trying to estimate absolutely. But we're pretty good at estimating relatively, doing it in groups (witness bean counting contests) and even with just a little information we can make improved estimates.

So the ideal task planning in my mind goes like this: the team gathers around the backlog to see what we think the next priorities are. Briefly we chat about each one, enough that everyone has a basic sense of what it is and no one is blindsided. We intentionally don't want to talk about it enough to implement it, just enough to get a sense for it.

The team then collectively estimates the size of each item with a hidden bid system: each person picks a number on an arbitrary scale (let's call it points) that only has meaning relative to the point values of the other things on the list. Once we have a handful, it becomes pretty easy to say "foo is harder than bar, but not as bad as qux".

Re: Why do some developers consider Agile development to be nonsense?

#107

Post by couchand » Mon, Apr 13, 2015, 3:52 PM UTC

jackmaney wrote: post #104

couchand wrote: post #97

Earlier quoted context omitted.

You're right, eventually you have to convert points to some notion of time, if only so that you know how much work you can do in a sprint. The idea is that you make that conversion based on past observation, using a velocity estimate that represents the past performance of the team and takes into account who's on vacation this week. There also should be an open recognition that your actual velocity will vary somewhat…

In every implementation of agile that I've ever seen or encountered, something like this occurs: "Okay, this story for Feature X, how many points should we give it?" "Well, it'll probably take N days, so, let's say, M points." Eventually, for the sake of consistency, a rough translation between points and time intervals is established.

I've seen that happen, too, but I've also seen it work.

Re: Why do some developers consider Agile development to be nonsense?

#108

Post by zimpenfish » Mon, Apr 13, 2015, 3:54 PM UTC

wilsynet wrote: post #68

zimpenfish wrote: post #53

Earlier quoted context omitted.

I've been in standups that lasted an hour a day. That'll destroy your morale pretty damned quick.

They are doing it wrong. 8 people should not take an hour to say: What did I do yesterday, what am I doing today, is there anything blocking me? There should not be a discussion of every point. The only discussion should be "oh let's talk about that impediment after the meeting with a smaller group of people" or "let me follow up with you after lunch". The standup is 10-15 minutes. If it is longer, it needs to be sto…

There were frequently 10-15 people in the standups. And sure, you can say "if it's longer, it needs to be stopped" but management doesn't work like that.

Re: Why do some developers consider Agile development to be nonsense?

#109

Post by jackmaney » Mon, Apr 13, 2015, 3:54 PM UTC

lostcolony wrote: post #101

jackmaney wrote: post #92

Earlier quoted context omitted.

Fine, "product owner" or "scrum master" or "person who schedules meetings and fiddles with the JIRA board". Whatever. I don't care what piece of jargon you want to substitute in. Let me ask you this: why should any customer or business unit give a flying fuck about your "points"? Customers and business units should have a strong voice in prioritization of tasks, yes. However, in the process of prioritization, an esti…

So what? Let them. They get estimates that are relative to each other (~this~ story will take longer than ~that~ story), and can turn them into time measurements them however they like if they want to; we're not committing to their estimate. All we're committing to is to deliver what -we- choose to include in a sprint, will be delivered by the end of the sprint. We will choose what is in the sprint based on the prior…

> So what? Let them. They get estimates that are relative to each other (~this~ story will take longer than ~that~ story)

First, they'll ask how much longer ~that~ task will take to complete than ~this~ task. Then, they'll ask how long ~this~ task will take to complete. Then, they'll use this little trick called "math"[1].

> and can estimate them however they like if they want to; we're not committing to their estimate

Well, guess what? If you refuse to give deadlines, then they'll be established for you. I don't know about you, but I'd rather have a say in my deadlines (where possible).

[1]: http://dilbert.com/strip/2002-05-19

Re: Why do some developers consider Agile development to be nonsense?

#110

Post by Nizumzen » Mon, Apr 13, 2015, 3:59 PM UTC

ddoolin wrote: post #51

outsidetheparty wrote: post #26

Earlier quoted context omitted.

>Agile development is about making connections to your team members: individuals and interactions over process and tools. See, this kind of vague, fuzzy feel-good description is exactly why it seems to me that the one thing everyone seems to agree on about Agile is that everyone else is doing it incorrectly.

Agreed. I'd like to see some solid experiences that counter the author's claims being used in the wild that fit where he says it doesn't work well (anything other than small, short projects). Nearly everyone is taking the "it's not us, it's you!" approach. A lot of things work well in theory. That doesn't really make them good ideas if they can almost-never be implemented properly.

Yeah. Communism is great in theory as well. It doesn't work though.