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

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

#71

Post by nissimk » Mon, Apr 13, 2015, 2:36 PM UTC

michaelt wrote: post #52

UK-AL wrote: post #6

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

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…

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.

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

#72

Post by UK-AL » Mon, Apr 13, 2015, 2:37 PM UTC

jackmaney wrote: post #49

UK-AL wrote: post #34

Earlier quoted context omitted.

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.

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

#73

Post by jackmaney » Mon, Apr 13, 2015, 2:38 PM UTC

lostcolony wrote: post #64

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…

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

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

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

#74

Post by Delmania » Mon, Apr 13, 2015, 2:38 PM UTC

Reading over his points make me think the OP is a PM who doesn't understand Agile nor his role in it. The number of misconceptions he presents reads like someone who has never bothered to research agile, but only knows what consultants have taught him.

I think the number 1 misconception is the sprints. He seems focused on 2 weeks as being the requirement, when it's on the recommendation. Some team have gone as long as 4 weeks. The whole point to a sprint is that dedicated time to a delivery with fast feedback from the customers. It's mainly so you can fail early, ail often. It's much better to spend 2-4 weeks building the wrong product than 6 months.

Second, his claims that product development, research and design, and architecture don't belong in a sprint are also misinformed. The focus on user stories to remind people that they need to focus on users, not gold plating. In any technical project, there are a plethora to improve on the design. People can (and have) sat down and refactored and "rearchitected" for days and days. At the end, they build beautiful systems that don't offer any advantage to the customers, or have implemented a number of features the customer didn't want, or have fixed a series of concerns the customer wasn't concerned with. There is give and take of course, as the engineers needs to give feedback to help the customer understand the benefits of the feature or risks of not fixing the issue, but those need to happen first before people go off and construct digital masterpieces.

Third, micromanagement. If you have endless meetings in agile, you're definitely not doing it right. The 3 big meetings, planning, retrospective, and demo, are ones that take the most time. Standups take no more than 15 minutes. The other tasks, meaning, backlog grooming and prioritization should not involved your sprint team. Those need to be done offline by the product owner. Agile may be about teams, but you still need strong leadership.

The only point of his that has any relevance is the last one, where consultant firms have made big bucks spinning out variations of agile because people just can't understand how simple it is.

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

#75

Post by walterbell » Mon, Apr 13, 2015, 2:39 PM UTC

fsloth wrote: post #57

couchand wrote: post #8

This article cements in my mind the issue: devs tend to take away from agile what they expect to find, rather than taking the time to understand the motivations and whole scope of activities. Historically, most software development methodologies are excessively top-down, so people somehow still expect that from agile. Most devs are the sort that couldn't stand doing group projects in school, so the idea of organizing…

"Here's the secret: software development isn't really about making computers work, it's about organizing knowledge. If your process focuses more on making the computers work than your institutional knowledge you're making a critical mistake." That's a fantastic quote, thanks.

You may like Philip Armour's Five Orders of Ignorance, http://www-plan.cs.colorado.edu/diwan/3308-07/p17-armour.pdf

"0th Order Ignorance: Lack of Ignorance. I have 0OI when I (probably) know something.

1st Order Ignorance: Lack of Knowledge. I have 1OI when I don't know something. With 1OI we have the question in a well-factored form.

2nd Order Ignorance: Lack of Awareness. I have 2OI when I don't know that I don't know something.

3rd Order Ignorance: Lack of Process. I have 3OI when I don't know a suitably efficient way to find out I don't know that I don't know something.

4th Order Ignorance: Meta-ignorance. I have 4OI when I don't know about the Five Orders of Ignorance. "

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

#76

Post by outsidetheparty » Mon, Apr 13, 2015, 2:42 PM UTC

cmdkeen wrote: post #40

outsidetheparty wrote: post #12

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

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

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

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

#77

Post by Delmania » Mon, Apr 13, 2015, 2:43 PM UTC

outsidetheparty wrote: post #12

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

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.

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

#78

Post by nissimk » Mon, Apr 13, 2015, 2:51 PM UTC

nissimk wrote: post #71

michaelt wrote: post #52

Earlier quoted context omitted.

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…

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 "featur…

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.

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

#79

Post by outsidetheparty » Mon, Apr 13, 2015, 2:57 PM UTC

Delmania wrote: post #77

outsidetheparty wrote: post #12

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

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…

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?

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

#80

Post by jacquesm » Mon, Apr 13, 2015, 2:57 PM UTC

outsidetheparty wrote: post #59

mklim wrote: post #24

Earlier quoted context omitted.

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

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