As a young software developper, what really bores me with Agile, is the name, the shiny box you put things into, where it should just be named "Good practices for software developement". It's the mentality of selling things as products, with some kind of prebuilt ideology and aesthetic built along with the core, that really makes me run far far away.
I don't want to be sold a product. The fact that it led people to try new ways of developping software, be it TDD or pair programming or whatever, is good, but heck, just give me the core idea, remove the gift wrap, and go away. I don't want nor need some kind of new age manager coach.
Anyway, the article seems to be making this very point in some way, but then, why the name agile ? Well for marketing of course. So, while i sort of agree with the article, well i'll just be far away looking, thanks.
The reason for the name Agile is that it was defined in opposition to what came before it- heavyweight, big design up front, fixed requirements, documentation heavy, non-incremental, non-iterative processes. These methods had names- CMM, RUP, V Model, MDA, MIL-STD-498, and we needed a name for the anti-method to go against them and not be labeled a cowboy coder with no process at all, and sidelined from all important decisions.
These were attempts to take the risk and uncertainty out of the process. Agile is an attempt to provide practices and approaches for dealing with the uncertainty- "embrace change" is very much the opposite of the "change is too expensive" mindset that it was trying to reset.
This adjective "agile" is important, if only to be used as a defense against 300 page requirement documents set in stone by a contract, 500 diagram architectures created before a line of code was written, developers who never got to talk to a user.
If we didn't have agile coaches and advocates, people who sat down to come up with a way to run their project might come up with the naive algorithm and head straight over the waterfall.
I can see how the name doesn't seem to make much sense now that it is bandied about in very prescriptive step by step methods that probably seem not very agile to a person who had not lived through the horrors that came before. However, that is how it should be understood.
Eric S. Raymond accurately characterized Agile when he described it as repackaging the things hackers do anyway, in a way that can be sold to non-hackers.
Maybe you don't want to be sold a product. You're not the target audience for Agile Methodology(tm). The MBA and Tim Robbins crowd are.
So, this is what appealed to me about the XP/Agile/Whatever movement. It crystallized some of the things I already saw working into a framework that had some chance of making sense to the nontechnical people who would (IME) tend to freak out at some of the ways hackers work.
As with most religions, what might start out as a good idea (love one another, take your vitamins) can turn into a dogmatic religion once the zealots take over.
It's funny that you mention Tim Robbins because after listening to somebody talk for 30 minutes about the "values" of the agile process I felt like I'd just sat through a Robbins seminar. The harder somebody tries to convince me that they deeply, truly, personally care about their customer the more convinced I am that they're trying to sell me something.
It's also an arguably necessary way to change processes in (largish) organizations who do not have good practices. Sometimes it's necessary to be a highly paid consultant to be taken seriously.
Not "you" in particular, but "you" as in enough of a client base that it matters. This is basically the issue with methodologies, regardless of what the contents of a methodology are!
Being agile is applying those best practices as you suggest. This comes from years of experience on your team - either learned directly or through mentor-ship/apprenticeship, and will vary depending on the problem constraints and environment.
Employing Agile Methodology is applying a pre-defined "solution" to a "problem" that exists, usually because the best practices are not applied at best, but most likely because they are completely foreign to the problem scope.
It's the hammer/nail problem. There is a whole market of people looking for solutions to their half finished projects. There are many people selling hammers, screwdrivers, chisels, drills etc. etc. They all run into the same fundamental issue: not working with a complete toolbox.
The solution to the problem seekers is to hire competent, experienced and most often expensive programming teams and allow them to properly define the problem scope and solution. This is complicated by the fact that often "you" cannot judge the competency or the experience of the people you need to hire.
No amount of ignoring that very hard problem will make it go away. Not whatever process IBM was flaunting 20 years ago, not agile, and not whatever people come up with next.
Hackers are painters after all, and you need to have good painters on your team if you are looking for a good painting. It's very similar to hiring a trades-person to renovate your house. In the end, you find one with a good track record and you essentially get what you pay for.
Most of these approaches are far older than 8 years. But, large companies often have an “education budget” and there is an industry that repackages old ideas, gives them a shiny name, and sells them for a respectable profit.
EX: Pair programming is very natural in a collage or contest setting. You often see people just default to that mode when under time constraints.
Warren Buffet is an unlikely person to quote in a discussion about agile, but .....
"First come the innovators, who see opportunities that others don’t. Then come the imitators, who copy what the innovators have done. And then come the idiots, whose avarice undoes the very innovations they are trying to use to get rich."
But you can't call it "Good practices for software developement". Over the years, that term has shifted. 30 years ago it meant the Waterfall method of analysis, 20 years ago it meant OOP, and 10 years ago it started to mean Agile.
Hopefully, we actually are getting better at developing software. But don't think for a minute that what you call "Good practices for software developement" is something trivial, that was known all along, and that you'd have to be an idiot not to do anyway.
The name probably makes more sense for people who wrote software before it came about. Even "non-agile" development processes have evolved in response in the last 8 or so years.
The marketing speak is often useful when one needs to sell ideas to management who might otherwise default to waterfall. I can tell not many here have been in that situation or there would be more appreciation for the utility of branded ideas.
Of course. Most software was developed using that model. I think most software is still developed that way, actually, but most people on HN are more likely to be using new techniques.
I also think this is the model that is still taught in most Universities.
Scrum consultants stay way past their usefulness, turning into self-aggrandizing organizational vampires.
I think there's something to be said for Scrum, and I think the shock therapy of a period of wholesale dogmatic adoption is the best way to start, with gradual backoff from Scrum dogma only after you appreciate the Scrum way, but goddammit you need to KICK THE CONSULTANTS OUT a few months after adoption and not let them set up camp inside your organization, playing politics to extend their gig as long as possible. The Scrum consultants in my company have been here almost a year. We know Scrum now. They still don't understand much about our business or our systems. Why are they here? Why do I keep hearing "<vampire redacted> says I can't do that," when <vampire redacted> is just a freaking process consultant who reports to a peer of your boss's boss? Why do we let them have that kind of power, when they only exercise it to pretend they still have something to teach us so we will keep paying them?
Also, the ScrumMaster role attracts the wrong kind of people. It attracts people who want power and want to be important. The desire for power conflicts VERY BADLY with being a good ScrumMaster, much worse than being a developer or manager or any other job I can think of. ScrumMaster is a simple role requiring only a little more process expertise than the chicken or pig roles. A ScrumMaster is a meeting facilitator. A ScrumMaster has no authority and no ninja skills. Being a ScrumMaster is like being the guy who can fix the printer. Having good ScrumMasters is very, very important, but they are not Important People. Does that make sense? They are not managers. People outside a Scrum team should not treat the ScrumMaster as a decision-maker or the proper conduit of information into the team. Bad ScrumMasters exploit those habits to aggrandize themselves and try to boss around their teams. Then they have power without responsibility.
Do you really believe an organization could function with no management? Can you really not see the wholes that would create?
The programmer attitude of "All management is bad. I'm better than everybody else in the company. I'm the only invaluable person in this organization." gets really old.
EDIT: OK, as pointed out below, I'm an idiot (much nicer than my grouchy post...). I do feel strongly about the anti-management stance, but that was necessarily not what this reply was talking about. My apologies.
If you do the substitution, you get "management consultants," not "management." I think it's a valid statement. Business always needs management, but management consultants are only good for helping a business solve a particular problem or get through a particular change. Then they should get out of the way. Instead, they work their way up somebody's butt and sit there pulling checks, wielding unaccountable power that is inappropriate for their place in the reporting structure.
It goes like this:
1. People do what the consultants say because hey, you're supposed to be learning from them. It makes sense.
2. Some recalcitrant people refuse to go along with any changes, and upper management puts out the word: "We're paying good money for these consultants. On my authority, do what they say." This still makes sense.
3. The consultants start meddling in things outside their original brief, just because they think they're smart and want to prove it. People have to live with it, so the consultants are gradually accepted as a generic part of the power landscape. This is the beginning of the pathology.
4. The consultants continue wielding power in a disruptive way as long as they can, because if the organization doesn't need their constant correction, somebody might realize it's time to get rid of them. This is the full-blown pathology: consultants actively disrupting productive work because it's the best way for them to stay employed.
Ahh, you are absolutely correct. I jumped to my pre-existing stereotypes. Bad me.
I actually have a negative opinion of most consultants (generally defined as people who tell you what you should do). I feel much better about contractors (defined as people who do what you tell them to do), but only in cases where it isn't your primary business competency being contracted.
Most management is bad, because most managers treat the function of 'management' as a separate domain/skill. Really, management is a combination of good people skills and a strong understanding of your product development & market.
I'm not really anti-Agile, but I like seeing people question the crazy hype around it.
Agile is really just a collection of mostly decent project management and coding advice. It is absolutely not a silver bullet, and it's also not best suited for every project.
There is no substitute for actual coding skill, and there is no substitute for thinking about the specific demands of your specific project when deciding how to manage it, how to prioritize things, etc. Every project is different.
To put it even more simply: you cannot substitute a "McMethodology" for actually thinking.
The idea that "being agile" is a fixed process that you can write down and teach to people seems to me to be a contradiction in terms. If you have to train people how to do it, and have meetings about it, and read books about it, how can you possibly be agile?
Actual agility is the ability to quickly adapt to changing circumstances. To do that as a team you need trust, and great communication. No process can give you either of those things if you've not got them, but a bad process can certainly take them away.
It's exactly this. Management loves to impose scrum (I've yet to hear being implemented from a bottom-up rather than a top-down initiative) as it's an excuse to micromanage: daily status reports, extra meetings, fixed working hours. That said, this may be a benefit for people who aren't passionate or interested in their work and want to clock out at five. That's fine, but that's not for me: my work is tied very closely to my personal identity, I put in many night and weekend hacking sessions and (voluntarily) work more than the usual 45-50 hours a week. At home, when not working, I frequently hack on personal projects and read technical books (indirectly benefiting my employer as well).
I chose to work for a place that judges me by what I produce, not by when I come in to the office. The beauty of being a software engineer in Silicon Valley (and I imagine this is the same in other technology hubs such as Seattle, Rte-128 and Austin) is that I get this choice. Here's a prediction: companies that micromanage in this fashion simply won't attract the required engineering talent. All else equal, engineers will choose a place that gives them more flexibility. The market seems to confirm this. Here's an interesting thread on hours engineers work at Facebook on Quora:
Note: I'm not opposed and frequently make use of "lower-case-A agile" i.e., unit testing, re-factoring, iterative development but they are just common-sense tools; much like editors, IDEs and programming languages they are frequently treated as objects of religious devotion, overlooking the fact they may be right for some (in some organizations, even most) projects, but inappropriate for others.
Yes. There used to be a manager who would schedule a meeting at 10am everyday with me to force me to come in. I was like fuck this, if I have to work until 11pm/midnight the previous night, I should have a little leeway in coming a bit late the next morning. I don't want someone to babysit my time.
I once worked at amazon. They hire managers who can barely operate computers and can't code. They like to keep engineers on call.
So for instance, on more than one occasion I was forced to wake up and fix a chronic problem caused by another team at 3-4am,and would show up at 10:15 and miss he scrum.
Got chewed out for being 15 minutes late on only 5 hours sleep.
Trying to communicate with a mix of people who are A) standing too far from the conference phone or B) driving to work and thus drowned out by road noise, not to mention paying attention to either you or the road but not both -- is a waste of time. Plus, people who are not dialed in can't read body language and so they end up talking too long because they can't see how bored everyone else is but nobody wants to be the one to tell them to shut up.
Some of your advertising is running a little haywire on you.
> My cousin called me up and was telling me about all the weight he's lost on this strange new diet. He was really excited. So I dug around and found the link to share:
Dr. Siegal's Cookie Diet - More than 500,000 people have used his cookies to lose weight. Now it's your turn! This page contains a single entry by DanielBMarkham published on September 7, 2010 9:42 AM.
You might want to block that ad manually or change providers. Don't know how much cash that's bringing in, but would you be eligible for something classier like TheDeck ads? Seems you've got the right market.
You know, I'm really beginning to regard the "Agile is led by consultants who don't know what they're doing" and "TDD is a crutch for beginners" crowds as being like the Rush Limbaughs of programming. There's a grain of truth to their points of view, but that's it: just a grain. They get their strength just from being loud enough to make people notice.
To be fair though, I think of the Bob Martins out there as being like the Keith Olbermanns of programming. Again, just a grain of truth but loud.
Die hard Haskell programmers get the distinction of being the Ron Pauls: hip, opinionated, and doomed to an existence of never being taken seriously.
Can't we all just accept that different people work different ways rather than being constantly at each others' throats?
(For the record, I'm not in any of these camps. In fact, I try to avoid joining any camps.)
"Can't we all just accept that different people work different ways rather than being constantly at each others' throats?"
We could if we all worked on one-man projects where you are the only one that reads the code that you write. The reality of the situation is, one day someone else will need to understand and modify your code. If you're inconsiderate about your coding style, then I would say, "No, I can't accept that you work in a different way".
Furthermore, given the choice and all things being equal, I'd rather work on the project that has a huge test suite than the one without it. From my perspective, I'd say the programmer who wrote that test suite is the more considerate programmer.
"We could if we all worked on one-man projects where you are the only one that reads the code that you write. The reality of the situation is, one day someone else will need to understand and modify your code."
Please don't patronize me. I'm fully aware of the fact that I'm working on a team of developers. They even work in the same room as I do.
Secondly, my argument is about 5 miles away from the argument you are arguing against. I'm arguing about organizational issues. I'm not saying that any developer needs to be able to be "incosiderate" all he wants (whatever that means). Guess what? Some shops do well by being agile. Some shops do well by not being agile. Some shops (if you can find them) do well by using Haskell. And there are a ton of shops out there that don't. What I'm getting at is that just because something didn't work for you in your particular situation doesn't mean it's bad.
> Die hard Haskell programmers get the distinction of being the Ron Pauls: hip, opinionated, and doomed to an existence of never being taken seriously.
Don't you know, Haskell's motto is: "Avoid success at all costs."
