Agile Ruined My Life

http://www.whattofix.com/blog/archives/2010/09/agile-ruined-my.php

by DanielBMarkham • 16 years ago

203 131 16 years ago

lzw4• 16 years ago

Implementing scrum turned our team from productive and mostly free of overhead to overbearing, involving a lot of long ass meetings (all meetings are long if you have to stand) and produced a lot of additional confusion. The interesting thing is that previously, with our specs and our so-called waterfall approach were were more agile. It happened naturally as we naturally did incremental development and we naturally talked to each other when we needed to, with no annoying scrum meetings and asinine bs from managers. People say managers have no voice at scrums, but what is a scrum master anyway? Everyone who doesn't write code is a manager and their opinion can interfere with progress. And of course the idiot child product manager would constantly lecture people about talking too much, except she would never shut up herself.

Even if a meeting is 15 minutes, if it is irritating, insulting, distracting and undermining, then it negatively impacts productivity for at least an hour after. I took to. Having breakfast afterwards, where I normally wouldn't eat breakfast, just to get centered so I could get some work done for the rest of the day.

I left that company soon after. If I had stayed i would have gone postal, or had to hire a lawyer to sue them under the ADA for torturing me by making me stand and listen to sanctimonious bullshit from idiots.

People say, when a bad experience is described that it wasn't being done right. Well i see no difference between what i experienced and what is being advocated.

Yes, there is a lot of anger towards the agile movement because it was sold as a tool to pointy haired bosses to impose, rather than a grassroots movement among engineers that embraced flexibility.

That said, on my own we've adopted a number of so-called agile methodologies like incremental and iterative development.

But the whole movement I'd oriented around imposing ideology on people. This is wrong.

For instance, whenever unit tests or test driven development comes up the proponents act like anyone not doing things this way is incompetent. I think the reverse is true, but I would never say there is ONE TRUE WAY. Agile proponents often seem to say there is only ONE TRUE WAY.

Also, don't mod me down just because I work differently to you. This is the ideology of the ONE TRUE WAY that is just wrong.

Programmers come in all shapes and sizes. They actually can be productive and work in a different than I do or you do.

DanielBMarkham2• 16 years ago

I (the author) agree with you. I also do not like this whole idea of ONE TRUE WAY. From the closing graphs.

Iterative and incremental development isn't for everybody. Lots of teams do things completely ad-hoc. Lots of teams are happy with waterfall. Lots of folks just don't care to change. These are all good reasons why agile might be a bad idea.

My standard for what agile isn't universal, sure. but I'm very happy teaching best practices for iterative and incremental development. You can call that agile, you can call it Joe. Whatever it is, helping people see things and try things they haven't seen or tried before -- and then letting them decide whether it's working for them or not... Over time there can be an us-versus-them attitude that sets up between any two groups of people. We must always be on guard for this. If you're not a servant to the team, you shouldn't be in the room.

lzw4• 16 years ago

Sure, didn't mean to come off as disagreeing with you, as your article makes many of the same points. Just venting because so much of these ideas have become an ideology....I respect that you are advocating a non-ideological approach.

brown9-2• 16 years ago

whenever unit tests or test driven development comes up the proponents act like anyone not doing things this way is incompetent. I think the reverse is true

Can you elaborate on what you mean by this last part?

kgo• 16 years ago

Someone who insists on a single silver bullet is probably incompetent.

api5• 16 years ago

The biggest determinant of success that I've seen is the skill of the programmers on the team.

No McMethodology can make crappy programmers write good code. Period.

(However, really bad management can make good programmers write crappy code too...)

cageface4• 16 years ago

Exactly!

Factors contributing to the success of a development project, in decreasing order of importance:

1. the skill of the team

2. the determination of the team to succeed

3. appropriate choice of technologies

4. process

In my experience management agendas are much more likely to interfere with 1-4 than to help. There needs to be some kind of hippocratic oath for development managers and process enthusiasts. Everybody pays lip service to Fred Brooks but people somehow seem to keep forgetting his message.

jamesbritt• 16 years ago

"No McMethodology can make crappy programmers write good code. Period."

Can't a McMethodology help crappy programmers become less crappy (and eventually write better code)?

Are there any methodologies that can help with this?

Ideally, poor developers get replaced by better developers, but realistically this (for all sorts of reasons) doesn't always happen. So, if you're a project or team leader, what can you do to elevated the level of code from sub-optimum developers?

Anything? Or maybe it's better to give them "fake" code to write so they stay busy and out of the way.

haze• 16 years ago

Being Agile has become a fad off late. This has led to team adopting agile blindly doing things without understanding the reason or need behind it. This could lead to frustration mentioned by you involving a lot of long ass meetings standing.

I believe as mentioned in the article that Agile is a set of best practices followed by a ever adaptive team. I completely agree there is in no ONE TRUE WAY.

moondowner• 16 years ago

True, It can disorganize the team and make it counterproductive if it isn't in the 'agile' mindset (or hasn't adapted to it in a reasonable period of time).

weego• 16 years ago

We implemented it because one of the teams we work with implemented it. The big difference no one cared to notice was that they work in terms of iterative builds of a huge application that they determine the timescales of, and we work on learning products that have prescribed deadlines, sometimes down to "this needs to be done this afternoon for tomorrow morning".

We were still forced to estimate the effort of something that we knew had to be done the same day, and it was to be done by the person who had free time, no the person who it would be the least effort for.

No surprise it was a completely hollow experience.

njharman• 16 years ago

Did you even read the article?

snorkel• 16 years ago

The gaping vulnerability in the traditional ad-hoc waterfall approach is management is constantly interrupting work in progress and changing the priorities, then wondering aloud why nothing ever seems to get done.

Agile is certainly worth the bureaucratic hassles it adds because agile protects developers from the tyranny of ever-changing priorities. At the start of each iteration (every 4 weeks or so) the management team must agree that these issues, and only these issues, will be the entirety of what the team works on for that iteration, no exceptions, no additions, no interruptions. A good management team will respect that agreement and protect the team from interruptions.

PotatoEngineer• 16 years ago

This can be solved simply by explaining to your management that Change == Things Will Be Late. If your management can't understand this, then it's unlikely that they'll be able to commit to Agile, anyway.

huherto• 16 years ago

yes, and the worst part is when the pointy haired bosses become Agile experts and start to look down on software developers. They couldn't write an application even to save their lives but now they feel they are the experts and try to manage the developers.

gaius3• 16 years ago

Exactly. IMHO the role of the Scrum Master only really exists during the daily standup. The rest of the time that guy should be coding with everyone else.

rickmb• 16 years ago

You know what one of the core values of Agile is? People over process.

For fuck sake, the reason the Agile Manifesto came into being in the first place because the people writing it, the people who created various methodologies now known as "Agile", agreed that there was no ONE TRUE WAY, just a set a values they shared. Each and every one of them would agree with you.

This willful misunderstanding of agile is just pathetic. It's like listing to teabaggers going on about death panels.

lzw4• 16 years ago

Back when that is what agile was, I was all for it. But it had become a dogma, just like the dogma that causes you to lie about the tea party and obamacare- you don't carewhat reality is.

gsharm• 16 years ago

Thank you, my experience has been same, and I could have not said this better.

I'd like to add that anyone in this position should do exactly what you and I did, and quit. Time is valuable. Leave them to find out the error of their ways by themselves if they're unwilling to listen. They'll think you're wrong. You'll think they're wrong. Fine. Let the free market work it out.

I now work as a contracter elsewhere, solving more worthy and interesting problems, and with wonderful coworkers. Our methodology adapts as required to the problems we are trying to solve. We're incredibly productive and love our jobs, because we think about the product we're trying to create and not about following arbitrary rules in lockstep.

The way to overcome incompetence isn't to fight it but leapfrog it entirely.

WorkerBee2• 16 years ago

there is a lot of anger towards the agile movement because it was sold as a tool to pointy haired bosses to impose, rather than a grassroots movement among engineers that embraced flexibility.

the interesting thing is that the agile movement started as exactly the reverse of what you said: as a grassroots movement among engineers that embraced flexibility, not a tool to pointy haired bosses to impose.

If your experience is the opposite, you've been had by someone, and you're blaming agile.

whenever unit tests or test driven development comes up the proponents act like anyone not doing things this way is incompetent. I think the reverse is true

The reverse would be "anyone doing unit tests in incompetent", which is not a defendable statement. What are you trying to say?

loewenskind3• 16 years ago

Wow, it's pretty surprising to see such a rant get so many upvotes. Your rant is about a bad company (good on you for quitting) but it has nothing to do with Scrum.

You're right that there is for sure no "one true way". For me, I like (the parts I use of) Scrum because (a) it puts a low limit on how long a project can veer off track without anyone noticing (i.e. you can only lose SCRUM_LENGTH time at once, not years) and (b) it puts up a wall that stops business from just coming over interrupting me everything some bright idea pops in their head (they can do this if they wish but it means canceling the current scrum. Usually this is enough to make sure they don't do this for trivial stuff).

Maybe one reason I like it is because I'm the kind of person who always sees "rules" as guidelines, not things to be followed rigorously in all cases.

jasona• 16 years ago

Amen.

The greatest success I've had is using a hybrid approach of agile and waterfall. But, let's face it, Agile is anything but agile when it comes to the process. The Agilists out there will be the first to beat you over the head when you don't follow the process by the book.

btilly2• 16 years ago

Agile is anything but agile when it comes to the process. The Agilists out there will be the first to beat you over the head when you don't follow the process by the book.

There is a delicious irony here. The first bullet point of the Agile Manifesto is that individuals and interactions matter more than processes and tools. (See http://agilemanifesto.org/ if don't know what I'm talking about.)

The heart of the Agile movement at the start was that no one process fit all situations. So they tried to come up with whole families of methodologies exactly so that teams could choose the one that best fit their situation. Some of those methodologies proved popular. (eg Scrum.) Some people made a living out of pushing those. And voila! The message became, "Here is a magic methodology that is right for all situations, which we'll be glad to teach you about in our next expensive seminar!"

And so it happens. It seems that all revolutions are destined to become what they were revolting against.

chromatic8• 16 years ago

* The message became, "Here is a magic methodology that is right for all situations, which we'll be glad to teach you about in our next expensive seminar!" *

Would you hire someone to manage your software development process who's only qualification is sitting through an expensive three-day seminar?

Would you trust an organization which does so?

If not, why the surprise that such projects struggle?

ams6110• 16 years ago

Meet the new boss, same as the old boss

mattm• 16 years ago

Software development can never truly be waterfall or agile. The best development always lies somewhere in between.

If the process were only waterfall, the project would never even be started because all the specs would take forever to write out.

If the process were only agile, there would be chaos because there is no long-term thinking involved.

rbranson• 16 years ago

All of the "heavy" agiles like Scrum have confused me: isn't agile about fundamentally less process and more flexibility? One can't serve two masters. Teams have to pick a point along the completely structured - completely flexible line. As far as I'm concerned, these flavors of agile are just wolves in sheep's clothing that allow existing waterfall autocrats to continue their reign under the guise of adopting "agile."

tieTYT2• 16 years ago

It's all relative. For example, the reason you have daily 15 minute meetings is because lots of companies had daily 1+ hour meetings. I believe scrum originated from trying to fix companies that were doing things unbelievably bad. From that perspective, it's a lot less process than before.

mikeryan• 16 years ago

Here's how "Agile" has worked for me.

Start with a big list of features you wan to implement. Product Owner/Manager keeps list in proper order of importance.

Every 2 weeks team gets in a room for 1 hour and marks off what they have done and picks off what needs to be done for the next iteration - generally you try to pick off less work then you think you can do. We'd let you pull in additional work as the "iteration" went on - any extra work completed was a bonus for the PM. Unlike traditional agile - we found that having QA and bugfixes trailing dev by an iteration worked best.

repeat.

Now with this, and it really depends what you're working on, you can still do "releases" every iteration if you want - but you don't have to (but to release a feature it would take generally 2 iterations one for dev, one for test/bugfixes). Generally we would only do daily standups if we're 1. Relying heavily on an outside team. 2. Getting close to a release. Standups always had to occur before 11am (usually at 10) as close to the start of the day as possible.

I found this method worked great. It left the managers with the ability to do some scheduling - w/o those effing "points" or "cupcakes" level of work meetings - which created metrics that no one used. You still get transparency and can release quickly as features get implemented.

bmelton• 16 years ago

My experience is similar, but based more on Sprints and more frequent, shorter meetings. We also utilized "Post-It Driven Development", meaning that all our tasks were written on post-its, with an estimated time-to-completion (rough, like 2 hours, 8 hours, 2 days, etc.)

We would meet for 10 minutes or less each morning, and each person would move their post-its as necessary -- we had 4 columns, not started, started, finished or roadblocked. Each day the post-its got moved over to where they needed to go, and anybody who looked at the board could see exactly who was working on what, how much work was remaining, how much work was completed, and who was or wasn't doing a good job of time estimations.

New feature requests would be queued by the product manager until all of the previous sprint's features were implemented (or delayed, or resolved in some other way), and then we'd start over.

squidsoup• 16 years ago

I've been doing "post-it driven development" on my own, using my monitor bezel. It seems to work until the stickiness wears off and the task becomes lost forever. Oh well.

seldo• 16 years ago

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.

maxawaytoolong• 16 years ago

I'm convinced the main point of scrum is simply so that everyone has to be in the office at 9 or 10 everyday.

Tichy• 16 years ago

That's also probably what annoys me about it the most :-/

aphexairlines• 16 years ago

What about dialing in?

ww5204• 16 years ago

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.

tjpick2• 16 years ago

> have to work until 11pm/midnight the previous night

Just don't do that then. In at 9, out at 5. No problem, life goes on.

hello_moto3• 16 years ago

Point out that in most agile books, people should not work overtime. :)

strlen• 16 years ago

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:

http://www.quora.com/Does-Facebook-have-fixed-working-hours

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.

gizmomagico• 16 years ago

And that everyone needs to have something to say about what they've done. In other words, they have to have done something.

Raphael_Amiard• 16 years ago

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.

cageface4• 16 years ago

Exactly. It reeks of buzzwords and consultant speak. Every brush I've had with an agile evangelist felt like a scene from "The Office".

Retric• 16 years ago

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.

neiljohnson• 16 years ago

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

rue• 16 years ago

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.

joe_the_user5• 16 years ago

The name makes sense but that doesn't mean it's not marketing speak.

run4yourlives• 16 years ago

I don't want to be sold a product.

Except that in many, many, cases, you do. :-)

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.

bitwize• 16 years ago

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.

joe_the_user5• 16 years ago

The problem is it is packaging some of the things hackers do anyway.

When it's just something you do, it's fairly easy to see when it is or isn't appropriate to do.

When it's a package, it's invitation/excuse or requirement to always do it that way. And as the gp says, that's a problem.

cageface4• 16 years ago

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.

jsyedidia• 16 years ago

I think you must mean Tony Robbins.

kemiller• 16 years ago

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.

binspace3• 16 years ago

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.

mattmcknight• 16 years ago

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.

edanm2• 16 years ago

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.

dkarl2• 16 years ago

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.

api5• 16 years ago

"Scrum consultants stay way past their usefulness, turning into self-aggrandizing organizational vampires."

s/Scrum/Management

FTFY.

SoftwareMaven2• 16 years ago

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.

api5• 16 years ago

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.

lionhearted• 16 years ago

Hey Daniel,

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.

Took a screenshot for you, can be seen here:

http://awesomescreenshot.com/09113hrc2

DanielBMarkham2• 16 years ago

Thanks. I'll fix that.

Geesh.

EdiX• 16 years ago

I think that ad was ironically topical

c00p3r• 16 years ago

When people start selling Agile methods and trying to replace ideas with routines, meetings and paperwork - it is became a scam, of course.

But the ideas, on which Agile was built upon - like interviewing experts of the problem domain, extracting and preserving slang and vocabulary from the stories and keeping that terminology through data, code and even a markup by naming the same thing the same name everywhere. Design for changes, code for reuse, start early and iterate, adapt and evolve - all those ideas are working ones.

So, the problem is just with pre-packaged methods and forced techniques. Each group, each project should realize usefulness of some of those ideas by changing their habits and by practicing, not because some "guru" told you that something is such and such. It is the only way.

It is a common situation when some ideas replaced by routines and propaganda and authority of "teachers". Buddhism is the best example. The essence of Buddha's teaching is several simple ideas and conclusions from them. But in many places people have transformed them into sets of rituals, rules and endless empty talks.

joe_the_user5• 16 years ago

Indeed, it seems rather tragic to see initially good ideas worked into a dogma.

jbooth• 16 years ago

Whole article is worth reading just for the phrase "Cargo Cult Agile".

BrandonM• 16 years ago

I disagree. I've been seeing "Cargo Cult X" comments all over Hacker News recently, usually with several upvotes, and it just annoys me.

aneth• 16 years ago

Interesting to see the present backlash against agile and TDD. As an independent developer, I can pick and choose what works.

I can say honestly they are both really useful concepts filled with great tools, but I am not an expert on either. TDD has saved my life a number of times. I have seen lots of tragedies averted and productive discussions because of "scrums."

When process takes over function in any environment, innovation and motivation will be squashed.

InclinedPlane• 16 years ago

I still stand by my comments here: http://stackoverflow.com/questions/343162/is-scrum-evil/3433...

gojomo• 16 years ago

My sense is that the 'agile' label is not for a specific process or place-in-the-solution-space but for a direction.

It's a direction that's the opposite of many big company dynamics that can impede software productivity. It's also a direction that's opposite some proclivities of otherwise strong and well-meaning programmers, who nonetheless try to achieve certainty too soon in an ongoing, exploratory project.

icfantv• 16 years ago

i read the comments here and wonder if the problems people are expressing here about agile are actually caused by agile, or rather, the people implementing agile?

my money's on the latter. agile, like any process, can be abused by those who don't understand or are too process-oriented.

chromatic8• 16 years ago

Perhaps Scrum (and Scrum alone) is dangerous, in the sense that it's difficult to adopt without careful, disciplined technical practices already in place and the whole team's understanding that scrum scheduling and management is very different from the so-called traditional approaches.

narag3• 16 years ago

...if the problems people are expressing here about agile are actually caused by agile, or rather, the people implementing agile

If there is no way to tell, does it matter?

I mean, if Agile requires a perfect implementation, support from everybody, very smart people and luck, is it any good? If I have all that, I can do whatever with any methodology.

chromatic8• 16 years ago

If there is no way to tell, does it matter?

It's easy to see the flaw in many failed implementations: they don't manage their schedules, they don't have successful iterations, they don't manage their technical investments, and the only thing they don't do that agile suggests isn't usually worth doing is writing lots of specifications and documentation beforehand.

binspace3• 16 years ago

Agile does not require perfect implementation.

I have yet to see an "unsuccessful" project using agile, as in the customer and team was not happy with the conclusion (I've been involved with > 10). Usually things change before that point is reached.

If the team cannot change when things start sucking, then things will continue to suck, regardless of methodology or lack of. Most teams can adjust (at least the ones I want to be a part of).

efsavage• 16 years ago

Agile/Scrum/whatever consultant engagements should be measured in hours, not days or weeks. Do a workshop on TDD or optimizing your standups, but if a team is being so badly mismanaged that full-time babysitting is neeeded, they need to replace their management, not add to it.

j_baker2• 16 years ago

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

tieTYT2• 16 years ago

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

j_baker2• 16 years ago

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

eru3• 16 years ago

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

autarch• 16 years ago

I think there's a few key points to take away from Agile ...

1. Involve end users (aka customers) in the process as much as possible, since if they don't like the end result your work was wasted.

2. Do work in small chunks. Releasing every 1-3 weeks gets changes out in front of real users quickly. The shorter your cycle the less likely you are to spend lots of time on something useless.

3. Write tests!

The specific details of any agile methodology are, IMO, less important. If pair programming or TDD or stand-up meetings help you with those three points, great. If not, don't do them.

credo• 16 years ago

Here is another good post on agile http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile...

madhancr• 16 years ago

I think Scrum helps product management more than developers. Good programmers always get stuff done quickly and iteratively. Thats how they become 'good programmers' and thats how most of them naturally work.

To me, making the product owner think about backlogs and stories from an end user perspective is the real benefit of Scrum.

joe_the_user5• 16 years ago

"An agile coach should be able to code, perform analysis, manage the project, test -- anything that needs doing on a project."

This kind of statement seems to typify guru-ism. I suppose there are geniuses what can do everything, write your whole project for you in weekend and be done. But eventually these methodology camps will wind-up turning a bunch of fairly average people into consultants, these methodologies need to have these consultants focus on some particular things they are good at and leave the rest to the others.

The best managers I've had didn't try to be programmers. A large project requires coordination and the manager should be there to do that - see what's on and off track, etc.

I don't know if these consultants are supposed to be managers or architects or what. But whatever they are, they're "goodness" needs to be in doing that well, NOT pretending to be so smart they can tell everyone else exactly how to do their job... And, of course, when a given consultant fails, the head guru can excuse the basic by saying "see, he didn't everything about everything so of course things didn't work..."

VladRussian• 16 years ago

Scrum is a child play compare to what happens when organization gets Six Sigma like stuff introduced through. Scrum Master as scamster !? Big deal! How about whole management tree getting additional clones - green, brown, black belts - who put their extremely empowered, yet clumsy and arrogant, hands and noses into and messing with everything? After having lived through such thing, a mild degree scrum feels just like a fly spec, a minimally necessary sacrifice to blood thirsty Gods of Office Space.

erikstarck• 16 years ago

In the 90s CMM and Cleanroom Engineering were popular.

Believe me. That wasn't better.

Then came this thing called RAD (Rapid Application Development) driven by a new set of tools such as Visual Basic.

That wasn't better either.

Extreme Programming was a breath of fresh air but Fred Brooks was right. There's no silver bullet.

motters• 16 years ago

In general I think it's wise to beware of gurus peddling software development methodologies. This doesn't mean that there aren't good practices which can improve the process, but all too often the gurus are not applying a proper quantitative analysis to their methodology to judge its relative efficacy, and instead rely very unscientifically on feelgood anecdotes and difficult to falsify assertions.

hello_moto3• 16 years ago

I'm getting confused by most of you guys. Some of you said that there are Agile consultants that would blame a failure because "you don't follow it by the book".

First, follow what by the book?

Second, what book?

Third, don't confuse Process with Principles.

Organization failed implementing Agile because the people behind it are still stubborn and still clinging to the old ways of doing things. Yes... this is the reality in our field. We often say things like "IT, Computer, Internet change the way we do things", please allow me to finish that sentence: "... but just don't tell us to change how we build software".

Agile never talks about making software faster. They talk about delivering business value and high-quality software. Even then, quality is defined by the Client, not by the developers/engineers. Some clients were okay with small UI glitches.

Scrum is a Project Management technique that uses a set of Agile techniques behind it. In Scrum, after each Sprint, you should have a potential shippable product. How can you have such situation without a good test-automation? Manual test would work fine early on when the list of features are minimum, but it doesn't scale. Remember, a Sprint is usually either a week or two. How can you re-test the whole product every 2 weeks? Hire more QAs?

Developers these days pay lip-service when it comes to writing test-automation. They'll dodge any tasks related to test. This happens because of our university/education doesn't teach us that test is important. Testing is usually a footnote in "Software Development" courses.

The reason why TDD is important is simple: people lie all the time. People are lazy. That's a matter of fact. They would say "sure, my code is testable, we don't have to write unit-tests now". By the time someone tried to write a unit-test, you'll hear tons of excuses. Can't do.

Now, let's get to everybody's favorite part: Superstar Developer. Yes, they do exist. No, they're not perfect, they'll make mistakes, they'll get sloppy, their estimate went south, etc. Superstar developers write unit-tests. I don't care if they do TDD or not, but at the end of the day, their code should be testable from all angles.

Please understand that we are trying to get better in this industry. Developer testing their own stuff is something quite relatively new. There are _plenty_ developers out there that allergic to testing.

BenoitEssiambre• 16 years ago

When I was an early teenager, I took violin playing lessons. Whenever I asked my teacher about violin playing technique, he would always give me a quote which he attributed to famous violin teacher D.C. Dounis:

"There is no technique, only a bunch of tricks that help you play better."

He didn't want me to get stuck in the 'technique' mindset. I think he was trying to tell me that applying a predefined technique instead of experimenting with different things meant you were not adapting to the current song, style, your, body or cognitive abilities. Different 'tricks-from-the-masters' worked differently with different people in different situations and a smart player would try different things until they found the combination that made playing easier and better sounding in his current context.

I always thought that quote applied very well to programming.

aminuit• 16 years ago

Just wanted to apologize again for sniping at you yesterday. It was uncalled for. Glad to see you've been able to incorporate it into a proper discussion.

extension• 16 years ago

The lifecycle of software development fads:

phase 1: a few brilliant people come up with a brilliant idea and use it to do brilliant work

phase 2: idea propogates as dogma, commercialized and exploited by hucksters, causes mass cargo culting and holy wars

phase 3: everyone gets fed up, idea is nomitavely stigmatized while its most useful aspects are quietly assimilated into the status quo

As it was with AI and OOP, so it shall be with Agile

dan00• 16 years ago

The idea of Scrum terrifies me, especially the Daily Scrum, because I've a very cycling productivity. In averaging the days, I get enough done. But if I would have to justify my less productive days, it would be very stressful for me, and it would be quite hard to explain why I couldn't get done more today.

loewenskind3• 16 years ago

Simple: on your productive days you must have done more than was expected so just don't report it all. Save it for less productive days.

ehendrickson• 16 years ago

The daily scrum is supposed to be about coordination, not reporting status to management or evaluating progress of individuals. It's just an opportunity to say "I'm working on XYZ" so someone else can say "Oh, I need to touch that area later today. We should chat offline."

That doesn't mean every team handles the daily scrum well or that the purpose is never hijacked. But it does mean that if the scrum starts to feel like a tribunal, it's probably a process smell that should be raised in the sprint retrospective.

d5ve• 16 years ago

One thing I've noticed with Agile projects at $work is that the processes better suit a "contractor" mindset, than a "fulltime employee" one. NOTE: I'm a fulltime employee, so view things from that mindset.

As a contractor (in theory), you're bought in to do a specific job, and then you leave - get done, get paid, get gone. This works well with Agile, where you can devote your entire attention to the project, and not get caught up in other things.

However, fulltime developers will find it more difficult to devote all their time to a project, as they're likely to still be maintaining some of their previous projects as well. In smaller organisations, you often end up being the go-to person for part of the system, and the rest of the business may struggle with these people being out of reach for weeks or months.

Another factor is that contractors have less reason to care about existing code and its design principles when designing and implementing a new project, and well as less reason to care about the maintainability of it. This leads to the software platform having a melange of different styles, further complicating the lives of those who have to support it later on.

To me, Agile just seems like contractor culture converted to religion.

itsalive• 16 years ago

Daniel, join the club. http://news.ycombinator.org/item?id=1616000

lazyant• 16 years ago

"Real life doesn't have a theme. Or if it does, it would be amazingly incredible and preposterously improbable if your book matched up with what was going on with my organization." - what a gem.

Regardless of the Agile theme (that I know little of to comment) this sentence applies to almost all the business books (specially the biography type).

I've read a lot of them and they are basically a collection of feel-good stories with some themes. Selection bias. A typical book will have a chapter like "Never give up" describing some story where the author insisted upon something far-fetched and finally got it (never mind the time he spent on other objectives he didn't get and never mentioned). Same with a lot of other typical themes.

A more objective book like "Founders at work" shows that all of them (from what I remember) got lucky not once but at least twice to have their break. Of course insert here the usual disclaimers that you cannot rely on luck only, you have to work hard etc to be ready when opportunity strikes.

Agile Ruined My Life

Related Stories