Earlier quoted context omitted.
Agile is a management tool. It helps manage developer time, feature bloat, organizational blocks, communication overheads and user expectations. It also helps you measure performance and identify bottlenecks in your own process. Like other comment said, it helps getting a couple things done instead of having a huge pile of stuff half done.
Look at what Agile is promising to fix. The development process not the management process. Semantics aside, I like everything you said, except to say that either the line manager is doing those things, or 'it' (scrum) is doing those things.
Agile is a Sham
111–120 of 189 posts
Re: Agile is a Sham
#112Earlier quoted context omitted.
Agile is a management tool. It helps manage developer time, feature bloat, organizational blocks, communication overheads and user expectations. It also helps you measure performance and identify bottlenecks in your own process. Like other comment said, it helps getting a couple things done instead of having a huge pile of stuff half done.
Look at what Agile is promising to fix. The development process not the management process. Semantics aside, I like everything you said, except to say that either the line manager is doing those things, or 'it' (scrum) is doing those things.
Re: Agile is a Sham
#113Earlier quoted context omitted.
Agile is a management tool. It helps manage developer time, feature bloat, organizational blocks, communication overheads and user expectations. It also helps you measure performance and identify bottlenecks in your own process. Like other comment said, it helps getting a couple things done instead of having a huge pile of stuff half done.
Look at what Agile is promising to fix. The development process not the management process. Semantics aside, I like everything you said, except to say that either the line manager is doing those things, or 'it' (scrum) is doing those things.
Re: Agile is a Sham
#114Earlier quoted context omitted.
Agile is a management tool. It helps manage developer time, feature bloat, organizational blocks, communication overheads and user expectations. It also helps you measure performance and identify bottlenecks in your own process. Like other comment said, it helps getting a couple things done instead of having a huge pile of stuff half done.
Look at what Agile is promising to fix. The development process not the management process. Semantics aside, I like everything you said, except to say that either the line manager is doing those things, or 'it' (scrum) is doing those things.
Re: Agile is a Sham
#115Earlier quoted context omitted.
The cost/benefit tradeoff is very different for those companies. Usually, no one almost dies when your social app goes belly-up.
Sure, I was just trying to prove a point - more process doesn't necessarily mean worse software.
That's not what Agile consultants are selling.
Re: Agile is a Sham
#116Earlier quoted context omitted.
I don't collaborate well with people who don't know a fucking thing about programming who try to put process on top of the process of programming. Fair enough. But what about someone who does know a lot about programming, who runs his team using agile methods. Could you collaborate well with that person?
HN's algorighm thinks I'm a spammer and wouldn't let me reply, but really, itsnotme. I could collaborate well with that person. If I like the product and the people enough I'll work on a team that uses "Agile". But I do it knowing that process is not communication, and that standups are a fucking joke.
Re: Agile is a Sham
#117Earlier quoted context omitted.
Spoken like a true cowboy programmer who can't collaborate his way out of a wet paper bag and blames process when a team he's part of fails because of that...
I hate that term cowboy programmer. Very effective rhetoric, though. Let's take the archetypical example of people who get stuff done without our process, and call them cowboys! Now, anytime someone points out a dumbass process-driven decision that could have been avoided by using our brains, we can just disparage them as a cowboy. Note, we're using small-a agile at my shop and it's working well, but that's because o…
Cowboy programmers are those who extrapolate from that and believe that teams efforts can work the same way, and who think that process causes only inefficiencies rather than preventing much larger ones.
But for a team to work effectively, you need structure, you need process. Even if the team members are very good, they can get completely lost without process. If they are not completely antisocial, they will come up with some sort of process themselves, but it's not automatically going to be a very effective one (and that has nothing to do with their programming skills). The point of agile is to try and minimize process while still enabling teams to work effectively. And it has absolutely nothing to do with "eschewing individual thought". Quite exactly the opposite, really. But of course there's no concept that can can't be perverted into its opposite by a sufficiently point-haired idiot.
Re: Agile is a Sham
#118[Obligatory plug and disclaimer: Agile professional who wrote an earlier rant "Agile Ruined my Life" http://www.whattofix.com/blog/archives/2010/09/agile-ruined-... Also I am writing some practical how-to Agile e-books trying to undo some of the damage: http://tiny-giant-books.com/scrummaster.htm ] Just differentiate between what Agile is and how people are pushing Agile on you. Different things entirely. Agile is be…
Exactly. And this shit makes me furious. I got involved with this stuff before the term "Agile" existed. At the beginning, it was a bunch of professionals (mostly developers) sincerely trying to find better ways of working. Extreme Programming, for example, came to be because the developers were really interested to experiment with how their team got stuff done. It breaks my heart that in the ensuing decade it has tu…
Re: Agile is a Sham
#119[Obligatory plug and disclaimer: Agile professional who wrote an earlier rant "Agile Ruined my Life" http://www.whattofix.com/blog/archives/2010/09/agile-ruined-... Also I am writing some practical how-to Agile e-books trying to undo some of the damage: http://tiny-giant-books.com/scrummaster.htm ] Just differentiate between what Agile is and how people are pushing Agile on you. Different things entirely. Agile is be…
Don't you think that agile proponents are frequently using a No True Scotsman here? That is, Statement: No Agile Team would do X. Response: An Agile Team did do X. Statement: Well, no True Agile Team would do X. ( http://en.wikipedia.org/wiki/No_true_Scotsman )
For instance "No true Scotsman is born in Tuscany to Romanian parents and has never ventured west of Florence" isn't an instance of the fallacy because it truly does violate what it means to be a Scotsman.
Similarly, no true agile team would, say, agree to a single 6-month "sprint" at the end of which they will deliver the end product to a customer who has never seen it before, based only on a set of specs drawn up by an analyst.
And yet corporate shops that do similar absurd, not-within-the-common-idea-of-agile things will routinely label themselves as agile shops.
Re: Agile is a Sham
#120I personally think Agile is mostly a scam built around some very small nuggets of common sense wisdom, which has then been propagandized by legions of clueless methodology consultants to mediocre teams and management, and spun into mediocre books and conferenceware. Just my personal opinion, ymmv etc. That said, this is a badly written article which doesn't convey much useful information or convincing argument. I am…
True, the article is basically a rant, but I tend to agree. I've felt like the agile train left my station long ago and it wasn't for trying. After being invited to attend a free 'workshop' from one of the holiest purveyors of agile out there, I left with the feeling that it definitely was all for those who did not know how to actually 'do the work'. The trends I've been seeing and trying to do are as follows: * full…
I am not a programmer. I have been involved in user training and in documentation for end users. How does your project handle the situation where there is a non-trivial change in the user interface?