Hacker News Reader

Comment by outsidetheparty | Hacker News Reader

This matches my experience.

We recently brought on a couple of PM consultants who are deep into Agile as a methodology, and decided to give it a go -- it's been about six months now and productivity has basically ground to a halt as we spend more and more meeting time endlessly sorting tasks into different little arbitrary piles instead of actually making forward progress. It's made communication with the non-software part of the company much more difficult, because they keep getting hung up on the jargon; we have to slice up tasks arbitrarily to get them to fit into "sprints," which go out of date minutes after the morning standup when the first non-planned bug report lands. Sizing is frequently an exercise in post-facto book-cooking: 'How long will that bug take to fix?' is like asking 'How long is it going to take to answer 23 across in next Sunday's crossword puzzle?' It might be fifteen seconds, it might take all day; until I have a chance to look at the puzzle I'm just pulling numbers out of my ass. The short timeframes encourage everyone to twiddle around the edges of things instead of doing real feature development; the arbitrary milestones serve mostly to make everyone feel like they're constantly falling behind.

I've discussed this with a bunch of people. Everyone seems to agree that we're doing Agile wrong, but even the strongest proponents of the methodology seem to be in complete disagreement on what the "right" way to do it is, or how that would be an improvement over the way we were doing things before.

So yeah. Not a fan.

View on HN

>Everyone seems to agree that we're doing Agile wrong

The fact that we've all heard this line (yet never heard a solution) should make it pretty clear that it's more of a management religion than an engineering practice. "You're doing it wrong" is the perfect built-in, pre-packaged defense to the Agile system that agile managers/consultants/etc can rattle off with zero effort and an air of superiority. Had a bad experience? Well, you were doing it wrong. It's not an issue with the system.

I recently worked at a place that was the text book example of agile/scrum development methodologies -- Which I don't mean figuratively, I mean in the literal sense, their big claim to fame was that they were the subject of a case study on the success of Agile methodologies. So, having worked in a place that was studied for "getting it right," it's extremely annoying to see all critiques of agile had waved away under the flag of "you did it wrong"

Just about every complaint in the article existed at this place as well. For me, at the tip top of the list was meetings. Planning would take hours. Sometimes it would be split up over two days. That is two days out of the 10 you have available for development eaten up by talking about what you're going to develop. Then there's a meeting to show what we did in those 10 days. Then another meeting to talk about what we think we did in those 10 days and how it could be better (which was of course done through stupid time wasting games ("I wish I could have ___" "I was happy when ___", "I should start doing ___"))

Then layer on top of all that a whole hierarchy of people whose whole job description is to be "agile" -- which not a single developer was able to explain to me the meaning since the day I started.

I'm ranting too much, but the whole agile thing just gets under my skin. It's such a massive waste of time. Leaving that company was a happy happy day. I now work at a place where 'planning' takes 15 minutes in front of a white board. Engineering discussions take as long as they need with the relevant parties whenever needed. Other than that, you're left alone to fucking do your job.

> ...doing it wrong...

Back when I was a wee lad, with nary a keyboard callus upon my digits, I learned about a little thing called Murphy's Law. In brief, it says that if anything can be done incorrectly, someone will eventually do it that way. It was a warning to those designing things, to make doing the wrong thing impossible, or at least much more difficult to do accidentally.

As a result, among those taught about Murphy's Law, "doing it wrong" was a design flaw. If, for instance, you could destroy radio reception in a handheld device by holding it in a particular way--a way that did not cause pain or discomfort in an ordinary human hand--it was the fault of the device manufacturer, not the user.

If you can do Agile "wrong", then it is a problem with Agile.

As for myself, I just think to myself that someone, somewhere, has weaponized an idiot, and has launched it against me. It is equal parts Inspector Clouseau, Mister Gumby, Ali G, Drunken Master, and a particularly evil djinn. He will do exactly what you ask, in the most malicious manner possible. He will follow a process with absolute rigor, and produce the worst possible outcome.

I firmly believe that such people actually exist--individuals so brutally incompetent that they are indistinguishable from malicious trolls. So you might as well plan around a person intentionally trying to break your design while still maintaining the plausible deniability of not breaking any of your rules.

Agile cannot hold up under the assault of a weaponized idiot. There are simply too many possible attack vectors.

"Weaponized idiocy" has entered my lexicon. Thank you, sir :-)

>individuals so brutally incompetent that they are indistinguishable from malicious trolls.

The concept of "functionally evil". Declaring someone "evil" implies motivation; "functionally evil" just means "assume evil for practical purposes".

It's arguably worse than actual evil, because (per Dumas fils) rogues sometimes rest.

I agree with what you're saying, but I also wonder, if not agile, then what do you see as a better alternative?

It sounds like you're suggesting that Agile methodologies have flaws that allow projects to be easily sabotaged. While I agree with this, I'm not sure I see an alternative? Is any development methodology going to be immune to this problem?

Human communication is messy, subjective, and open to all the imperfections that come along with the human condition. Unless you're working alone, any development methodology is going to be susceptible to "people problems". I don't see this as something that's unique to agile. I'm sure I could come up with hundreds of ways that idiocy, incompetence, and maliciousness could sabotage waterfall projects as well.

People within the software industry have a great advantage, in that they use their skills to both solve business problems and automate the solutions. Increasing the efficiency and effectiveness of the software team is a business problem.

There are some common elements to that problem that encourage the re-use of certain solutions--source control, for instance. The only mandate that needs to descend upon the team from above is to examine and improve your own processes.

There is only one other profession of which I am aware that can, given the opportunity, make every tool that is required for the job. That is the blacksmith. If a blacksmith discovers that a certain specialty tool would be useful for a routine task, he could either modify an existing tool or make the new one from scratch. No sane customer would barge in and demand that he use the "wrong" tool for the job. You might just find that red-hot tongs are the wrong tool for proctology.

But that happens to software professionals all the time. And that's where the weaponized idiot comes in. Allowing the customer to tell the skilled worker which tools to use sets up the situation where you could be performing surgery with a grapefruit spoon, while wearing oven mitts, or knocking down a brick wall with a rubber mallet and a hamburger spatula from an outdoor grill set. The unbelievable outcome is that sometimes that task still gets done.

A development process is a tool that software professionals use to do their jobs. If management needs another tool to help them do their jobs, those software professionals would be all too happy to make one. But let's not try to weld those two different tools together and call it a supertool. Agile is one of those welded-together things now, and the different parts might not work well together in your shop.

If your team cannot work without such a process, it may be because the business has neglected to hire a workable mix of masters, journeymen, and apprentices. Too many masters, and they may come into conflict. Too many apprentices, and they may struggle for direction. Too many journeymen, and they will leave to be masters elsewhere.

The only development methodology you really need is to make sure that every team has at least one master on it, and to let them pick their own tools and apprentices. If they can't get the work done with that level of autonomy, fire them and hire someone else. That's not a problem you can fix by going Agile.

Taking on a new development process in the middle of a project is much harder than starting on a new one. In particular, as you mentioned there's an issue of legacy bugs. There's mounds of information available suggesting strategies for taking care of this, but ultimately you'll be in an unfortunate transition while you're still handling legacy bugs that makes it hard to move forward.

Most of my experience with agile is in the XP flavors, where the mantra is no bugs. I know it's hard to believe, but I promise it's an achievable goal if the whole team single-mindedly works towards that goal.

You're right, estimating is hard. 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.

> 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 implementation of Agile that I've ever seen or heard of eventually translates points to time intervals ("How many points should this be?" "Well, a one day task is three points, so...").

Well, then, to give you a piece of anecdotal evidence; my experience where I currently am is that we never talk about how long it'll take, unless it's so small and trivial we can say "Give me an hour and I should have a first pass in place". Even then we're not saying it's ~done~, just that we're familiar enough with the code that we can get some prototypal code in place in a time frame. When actually estimating tasks, it's purely point based, and then those can and do vary with how much time they actually eat up, but tend to average out just fine.

"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!" [puts deadline of two days from now into JIRA]

We had three types of PMs:

- Middle management mover-and-shaker. Most recent technical contribution to a product: Some time in the last ice-age. Super power: secret meetings that lasted for hours, discussing how much all the devs were late, and who to blame.

- Underflunky. Ran daily stand-ups to gather status. Last technical contribution to a product: Never. Perpetually terrified. Super-power: "Since we need this done by the end of today, let's have a bunch of meetings about it. Are you available for an hour at 10, 2 and 5?"

- Fantastically technical PM. Last technical contribution to a product: Helped debug a gnarly problem over in the other building about ten minutes ago. Super-power: Writing intelligent specs that devs understood and that actually described shit that would work. Achilles heel: Incredibly over-worked and a burnout in five months.

We had one or two of the latter PMs on the last project I was on. They were great; every other PM did negative work.

I did get our underflunky PM to start calling our scrum meetings "Status".

'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 stories based on that, and based on the need for the feature. Point totals above 8 or so we try and break down into more stories. The only guarantee we give is that if we include it in a sprint, we will get it done in that sprint. We can estimate it at ~8 hours (~two days of a single dev's time; we build in slack, for meetings, context changes, dev tasks, and the unexpected), but we aren't guaranteeing that you'll have it in two days; it'll be the end of the sprint. Any more exact estimate is only for other devs, in case they're reliant on it being in place for something they're working on.

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.

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 estimate of time for the task--be it your estimation or theirs--will be a factor. If all you tell them is a number of points, then guess what? They'll back into their own time estimations from your points.

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.

> 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

Your experience dictates those things.

Mine does not.

You claim my experience can not exist.

I claim my experience can.

You also seem to ignore what I'm saying; we give deadlines. The end of the sprint. Whatever we take on will be done at the end of the sprint; they have control over what we take on by the backlog. Beyond that, we refuse to give any commitment (instead just giving relative weights to how long a task will take, to help in prioritization), and we are sufficiently empowered to not care if they try to commit us to something despite that. But they usually don't (the only time it's ever more immediate is "a bug was seen in prod and I want to know what caused it!", in which case that becomes our first priority task; again, because we consciously choose to undercommit ourselves, there is slack for that sort of thing to occur without delaying the schdule), because we work with them, listen to them, advise them, and they see that we are trying to help them do what is best for them, without causing a bunch of tensions and clusterf*ery. And because we undercommit we usually deliver more than we commit to, with time used to make sure things are reliable, so they have come to trust us.

In short, I hear a bunch of presumptions from you about what management -always will do-, whereas I know this from experience to be false. Management -can- adapt to viewing things along sprint boundaries. At least, mine has. Perhaps your problem isn't that a process is bad, but that your managers insist on micromanaging you and that you're not sufficiently empowered to push back?

> You claim my experience can not exist.

I have done no such thing.

Obvious troll has become quite obvious.

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 between sprints. One goal is to reduce that variability by improving your estimation (with practice!), but you anticipate and prepare for the variability. That's why you have a backlog (in case you need more work) and why you develop units of work that are independent (in case you need to push one).

For all these reasons it's a mistake to think of an equivalence at the level of tasks such as one day is three points or something like that.

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.

Legacy bugs? What the hell are legacy bugs?! What about, you know, normal bugs. Normal, unforeseen problems that happen all the time that you can't account for. Do you just add 25% time to any project to cover for those? I'm not sure how that solves the issue when you have to slice everything up into tiny chunks, where a few chunks could contain all of the unknown unknowns.

It's good to realize the known unknowns, but it's the other kind that will get you.

Legacy bugs are those in the codebase from before the team started working with a test first, no bugs mantra.

As I alluded to there are many approaches to this problem, but one that I like is more or less just what you suggest: set aside some amount of time every sprint to tackle the legacy codebase. The eventual goal is to bring it up to the newly accepted standard which requires tests, but realistically that will take a while. Live bugs provide a sort of direction to help facilitate updating the legacy codebase. Setting aside a set amount of time each sprint makes sure that the issues don't get swept aside.

It's important to get to the point where fixing live bugs isn't impeding the development of new features, but until then it's simply pragmatic to set aside some amount of time to hedge against new issues, while also having the discipline to set one aside if it can wait until the next sprint.

As an aside, some of the best patterns on the subject of dealing with legacy systems can be found in the later chapters of Domain Driven Design by Eric Evans, particularly chapter 14, Maintaining Model Integrity.

Well there is an interesting concept - you're talking about jargon like "sprints" yet referring to "Agile" which is a very, very broad church.

I like Scrum for the power of the retrospective, if people actually talk about issues, the the team really is empowered you can change those problems: a) Talk through how to handle bugs. There is no prescriptive answer, if you have a problem with defects then fix it, or develop a system to deal with them. You don't have to bring a bug into sprint after all, and if you do then get your Project Owner to drop an equivalent bit of work out. b) Refinement is a crucial part of the process, if you can't break up the task into 1/2 weeks worth of work for a team odds are you don't fully understand the task, which means you can't provide forward estimation, which means management can't trust you're numbers. c) "Project Managers" don't exist in Scrum, so a PM consultant guiding you on agile feels very, very wrong.

If your organisation can't commit to you working full (pretty much) time on a project working on a set of things that have been committed to without pulling you in another direction then odds are Scrum isn't going to work for you.

Scrum is very clear that there are certain things you need to do in order to say you're doing Scrum. Doing "Agile" screams following no particular sub methodology but cobbling something together. There's nothing wrong with that evolving, but it helps to be able to describe why you've gone in that direction. In your case it seems like you've had something foisted on you by external people talking out of their rear.

> If your organisation can't commit to you working full (pretty much) time on a project working on a set of things that have been committed to without pulling you in another direction

See, this is the thing: on the one hand it's supposed to be all about committing to a specific direction ahead of time and not letting yourself be pulled somewhere else -- on the other hand it's supposed to be all about developers being empowered to work on what's most important at the moment (I mean it's right there built into the name!) Those seem in direct conflict.

We don't have organizational pressure pulling us in different directions -- we have reality pulling us in different directions. I'm not going to tell a customer "no, you can't have that bug fix or that new feature yet, we have a Methodology to follow."

> "Project Managers" don't exist in Scrum.

Right. Just project owners, product owners, scrum masters....

> In your case it seems like you've had something foisted on you by external people talking out of their rear.

I think you're onto something there. (They keep changing their minds, too: one week it's fibonacci sizing, next week it's T-shirt sizes. One week it's scrums, next week it's kanban. The actual working process seems to stay the same, only the jargon shifts around.)

>developers being empowered to work on what's most important at the moment There's the problem, the "moment" is the sprint. If you're need for a flexible time frame is less than a week then Scrum isn't going to work for you. There are other methodologies that might work (Kanban say), but I'd also question whether you're doing pure development or mixing in support as well.

> "Project Managers" don't exist in Scrum. > Right. Just project owners. Uh huh. "Product Owners" should never, ever, ever be Project Managers or anything like them! They're supposed to be from the business end of things. The worst projects I've ever seen in Scrum land have been developing for project manager's needs (the only time PMs get to be POs) and it went horribly because they act like project managers not business people focusing on what they actually need the product to do.

If your consultants are confusing Kanban and Scrum then I'd run screaming for the hills. I've literally just come out of a retrospective where we had a discussion about switching from Scrum to Kanban for a load of impact analysis heavy work, they are different beasts both good at different things.

"Productivity ground to a halt for six months"

My experience feels the same way. I am beginning to think Agile works for UI dev and small teams of inexperienced folks building relatively simple projects. If you have a large team building something complex, the constant meetings and tool updates destroy productivity. What's worse ... they destroy developer morale if you are actually a good dev IMHO.

The classic success cases for Scrum were projects that had (a) been done before, and (b) been done by the same team.

So they had lots of experience.

If you ask an assembly-line worker "How long is it going to take you to install this transmission?" they'll be able to tell you within a few seconds. But that's not engineering.

If you ask someone who's written essentially the same app five or six times before "How long will it take you to finish feature X?" they'll be able to tell you with pretty high confidence.

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. Ask them again, when they've re-implemented it a few times, and they'll have an idea then. Until then you can decompose the problem and do analysis on the pieces and make assumptions, but you still won't know how long it'll take until it's done because the industry has been doing this for like 70 years and the one thing we know is that scheduling unknowns and unknown unknowns is still very, very hard.

Scrum works if you've done it before. Apply it to green fields or systems with known wicked behavior, and you're likely to fail in quite a few ways, including pissing off your developers and boiling off the good ones for better work environments.

An actual example I've seen: you can ask a field technician "how long will it take to install this piece of equipment in the field?" and get a pretty good answer. You can't ask a data scientist "how long will it take to build a statistical model to predict how long jobs out in the field will take?" and get anything at all useful.

And you certainly can't ask "how long will it take to build a statistical model to predict how long it'll take a data scientist to build a statistical model?"...

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?
  - Is that difference small or large?

All of theses are easier to estimate and are more useful, too.

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 always the case when you're doing something new. So you hem and haw and pad and you're late anyway . . .

But my stand is that you're actually not late, you're actually on time and it's just that the estimate you made (or that someone made for you) sucked. You don't even suck at estimating because you can't reliably estimate something you haven't done before.

Oh sure, small things. But not big things. Probably not even medium-size things.

Imagine you're in a scrum planning session and someone says, "Hey, we tagged you for implementing Gozzlewogs" and you have absolutely no idea what a gozzlewog is, or maybe you read about them a while back so you're the person that people come to when they hear "gozzlewog." But you're on the hook for it, and they want an estimate and the answer of "I don't know" apparently isn't on the table.

So do you:

- Dig in your heels and say "I don't know" anyway?

- Lie and say "Two weeks" because half of the dev team is in your shoes and doing the same thing, and you'll all slip together? Besides, next sprint it'll be the same bullshit, except with frumwidgets in addition to the deep, complicated and tricky stuff you discovered while investigating gozzlewogs.

Now, clearly this is broken, and it's not even the fault of Agile, but rather the middle management that thinks developers are fungible and cog-shaped, and that everything can be decomposed and predicted, and that you can have a schedule with a granularity of days when your known unknowns are at the scale of multiple weeks.

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".

Cheers, indeed. (Sorry about the edit . . . it's the way I think). Happy we're in agreement.

Part of my problem with Agile is that my bad experiences have made me cynical and somewhat allergic to it. I react badly to being micro-managed and gamed by managers who are fundamentally out of touch with the reality of writing software, and who are interested in making the deck hands row ever faster so they can look good.

It's roughly 2-4 hours worth of meetings in 2 weeks. That "destroys" productivity?

If you are doing Scrum, the development team should be doing something like over 2 weeks:

Daily standup: 15 mins x 10 days = 150 minutes = 2.5 hours Backlog grooming: 0.5 - 1 hour Sprint planning: 0.5 - 1 hour Retrospective: 1 hour Demo: 1 hour

So about 5.5 - 6.5 hours of meetings over 2 weeks. If you're really militant, you can probably take it down to 4 hours, but I don't think you can get much lower than that without dispensing with formal Scrum.

It doesn't seem unreasonable to me to have 6.5 hours of meetings over 2 weeks.

Your backlog grooming is a bit to long. You should only be grooming 10-20 tasks.

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 stopped. Period. Non-negotiable.

> 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".

Guess what? Those things are still meetings. They still take up actual time that could be spent on getting shit done.

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.

If you want to say that 2 people resolving an issue is a meeting, sure, go ahead and call it that. But I would suggest that the meeting needed to happen anyway.

Scrum doesn't imply that unneeded meetings need to be created for no purpose.

It is perfectly okay to also say during the standup "I'll follow up with you over email later" or "Let's resolve this over Slack".

So, have you ever said "Anyone going over sixty seconds will be shot" and there's that one guy - or two, or three - who nevertheless always take five minutes? Yeah, turns out you probably can't actually shoot them.

No, but you can cut them off and say "I'm sorry but we need to move on, you have 5 more seconds to finish what you're saying".

You can indeed do that. Sometimes they even stop! Not very often, though. Again, the inconvenient lack of actual bullets.

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.

Let's not forget the daily leadership meetings and weekly all-hands standup. Those are a real hoot...

No, incentivizing small tasks that look good in standups over larger, less-sexy tasks kills productivity.

Only 2--4 hours? I wish.

The problem is your company has no idea of what it's doing. You don't estimate bug fixes or research and development. You time box them, and once you've spent all the time allocated, you report back to your team on your findings. If you can't fix the bug in a sprint, you simply work on it in a later sprint. Second, real feature developments sounds like an epic. Those are stories that will span multiple sprints. There are ways to handle them.

Bug fixes, R&D, and real feature development are the entirety of what we do.

If none of those fit into sprints, what is the point of having them? What is the benefit of describing a feature as an epic sliced into stories spanning sprints, instead of just, y'know, getting it done?

No, they do fit into sprints, quite nicely. Time boxing gives you a deadline and accountability. Using research and development as an example, you go off, spend months researching a new search algorithm, only to come back to hear the customer tell your approach was wrong in restrospect. The sprint mechanism catches that sooner, preferably at the end of a single sprint, then months down the line. It's fail early fail often. Splitting a story into an epic forces the realization the feature is complex, and in many cases, seeing those numbers there quickly turns the feature from a must have into a "nice to have."

A key point to agile is that you are presenting the output of your work to the customers at regular defined intervals so the customers can decided if what you're doing it worthwhile. The daily sprints are a mechanism to detect when something is wrong.

Fail early, fail often is a fundamental component of agile.

> Time boxing gives you a deadline and accountability

An arbitrary deadline, often forcing you to interrupt your flow and then spend extra time next sprint reorienting yourself to pick up the same task again. And artificial accountability. (Did Alice overrun her time-box because she was lazy? Or because the bug was really tricky? Nobody knows! Is Bob a rockstar, or is he just really good at plausibly over-sizing small tasks? Perhaps!)

> you go off, spend months researching a new search algorithm, only to come back to hear the customer tell your approach was wrong in restrospect

That's kind of strawmanny. In no methodology should someone be allowed to wander around for months with zero feedback.

In "traditional" process the PM is in communication with the customer and keeps enough of a handle on where things stand to be able to pull the brakes when necessary. Agile seems to want to offload that work either into some vague diffusion-of-responsibility within the team, or to the customer herself (which seems bizarrely idealistic) or, most commonly AFAICT, to a de facto PM under another name.

> so the customers can decided if what you're doing it worthwhile

I have literally never met a customer who didn't want everything right now. A good traditional PM is able to manage those customer expectations. Few developers I've met have those skills or want to be spending their time doing that.

"An arbitrary deadline, often forcing you to interrupt your flow and then spend extra time next sprint reorienting yourself to pick up the same task again. And artificial accountability. (Did Alice overrun her time-box because she was lazy? Or because the bug was really tricky? Nobody knows! Is Bob a rockstar, or is he just really good at plausibly over-sizing small tasks? Perhaps!)"

You know at least 2 weeks in advance you have to be able to give your customers a report of your findings. If that interrupts your flow or forces you to "reorient" yourself, that sounds like you have poor planning and time management skills. If Alice is consistently missing her deadlines, or if Bob is consistently over-performing, the team needs to analyze the tasks being given to those individuals.

"That's kind of strawmanny. In no methodology should someone be allowed to wander around for months with zero feedback."

There is a difference between "go research this and report back" and "go research this for 25 hours and get back".

"I have literally never met a customer who didn't want everything right now. A good traditional PM is able to manage those customer expectations. Few developers I've met have those skills or want to be spending their time doing that."

Agile and the constant feedback cycle help to manage those expectations. It's another tool in the PM's toolbox.

Of course they all do. Another fundamental part of agile is the constant communication between customers and the team.

"'How long will that bug take to fix?' is like asking 'How long is it going to take to answer 23 across in next Sunday's crossword puzzle?' It might be fifteen seconds, it might take all day; until I have a chance to look at the puzzle I'm just pulling numbers out of my ass." .

I find this attitude to be a little disingenuous. Obviously every bug cannot be estimated perfectly, but the majority of the time there is some initial data to make a reasonable estimate with a margin of error.

For instance to name a few:

- Past experience with the module associated.

- Whether or not it has been reproduced locally.

- Similarity to other bugs that have come up in the past.

Depends on the bug, sure.

It's my job [or used to be :-)] to give estimates of bug fix times to management.

It usually broke down to:

- trivial (about an hour)

- nearly trivial (maybe half a day or a day)

- "I have no earthly idea". The last one of these that I fixed involved about twenty people, deep dives into our hypervisor and interprocessor communication mechanisms, research into some hardware details and three 100+ hour weeks about four weeks before we shipped. And we started out not having any idea where in the system the problem was (that took two of those weeks).

Some or several of the points you raised probably fit more into the "chance to look into the puzzle" phase so that doesn't really stand to reason against his point 100%.

To be sure. And if we were doing routine maintenance on a longstanding codebase things might be a bit more predictable than they are. But we're trying to do new feature development on a new product, and my experience has been that beyond a very general sense of "this is going to be a big one" vs "this shouldn't take too long, unless I run into something unexpected" -- which is the same level of detail you get with or without Agile -- sizing isn't meaningful enough to be worth the time it takes to do.

Your analogy to estimating 23 across is pretty amusing. I like it a bit more than the claim that software estimates are like asking how long it will take to detect dark matter (another one I've heard), because honestly, I really shouldn't try to equate my work with something on that scale. That said, I actually think your analogy is, if anything, a bit too optimistic about estimates. In some ways, I'd stretch it to "you're good at puzzles. how long will it take to solve next week's puzzle". You know that puzzles are usually crosswords, sudokus, word scrambles, or chess problems, and you can usually get them, even the hard ones. There's variance, and sometimes you do get stumped, so it's a bit stressful, but at least you have some kind of prior history as a guide. But surprisingly often, it turns out to be something like encountering a rubik's cube for the first time. How long does it take to solve a rubik's cube? Well, once you know how to solve one, it takes less than 5 minutes. How long does it take to figure out how to solve one when you've never encountered it? Well, for some, never. For others, a month? For a few people, a day?

But the answer is, it will take me anywhere from 30 minutes to a month to tell you how long it will take me to solve this problem (over 1 month, I give up). Then, my answer will be: 5 minutes.

What was your company doing before switching to Agile?

We're a very small team all of whom are skilled senior-level developers, working on a greenfield product. Basically boils down to back end guy, front end code guy, unicorn product designer/ front-end dev, and ops guy.

(Agile proponents have told me "Oh, that's exactly the wrong sort of group for Agile, it works best with larger teams of lower-level devs." Other Agile proponents have told me "oh that's the perfect sort of team for Agile, it doesn't work with big teams of juniors.")

The way it used to work was: Feature request comes from sales or upper mgt or customer or product designer. Designer does mockups or codes up a simple working prototype. Various team members look at it, we talk about how to implement it, everyone works on it as needed, we deploy it when it's done. If something else comes up in the meantime that's more important or more urgent, we set it aside in a different code branch until there's time to focus on it again.

The way it works now is basically exactly the same, except with lots more meetings and jargon and taxonomizing of tasks and arbitrary milestones.

(Agile proponents have told me "Oh, you were doing Agile already, you just didn't know it! Other Agile proponents have told me "oh, you're not even doing Agile now." Even its proponents can't seem to agree on what Agile is, which makes it really easy to tell its detractors that it's not Agile's fault, you're just doing it wrong...)

Why don't you just kick the agile nonsense overboard and switch back to your old way of doing things?

Oh, believe me, I'm trying.

Best of luck to you, it really sucks to have such theatre forced on you.

Getting stuff done, but in the eyes of management not fast enough. Just guessing but this seems to be the rule.

If you really need agile it will not help and if your team already rocks agile won't improve it, likely you'll already be doing something like it but customized to your needs.

I've seen a couple of fairly efficient teams utterly ruined by switching to 'agile' and I've yet to see an inefficient team become more efficient by deploying it.

"No Silver Bullet" was written in 1986. https://en.wikipedia.org/wiki/No_Silver_Bullet One day someone in The Mgt. will read it.

A good policy is to not estimate bug fixes, to not associate any points at all with them. It creates a drag on velocity, but it's honest.

If you need to fix a bug, it means that you are correcting an error from a past (implicit or otherwise) user story that shouldn't have been accepted as complete anyway.

Reply on news.ycombinator.com