Agile Ruined My Life
whattofix.com
whattofix.com
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.
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.
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.
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.
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.
"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."
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.
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.
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.
I also think this is the model that is still taught in most Universities.
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:
Geesh.
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.
s/Scrum/Management
FTFY.
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.
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.
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.
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.
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.
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.
?
Just don't do that then. In at 9, out at 5. No problem, life goes on.
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.
Worst company ever.
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.)
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.
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.
Don't you know, Haskell's motto is: "Avoid success at all costs."
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.
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.
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.
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.
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
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.
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.
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?
That said, I've used a variety of agile methods for years, but I'm quite sure in ways that would make many of the presenters of those seminars object very strongly to my calling it agile.
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.
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.
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..."
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.
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.
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.
"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.
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.
To me, making the product owner think about backlogs and stories from an end user perspective is the real benefit of Scrum.
my money's on the latter. agile, like any process, can be abused by those who don't understand or are too process-oriented.
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.
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.
Is it also also easy to correct the flaw? I don't mean to blame Agile practices. It could be the case that Agile is a bad fit to some "corporate cultures" or certain project type and the result of someone pushing hard its adoption is to have some practices really used and other only in appearance. This could be what people hates.
OK. that would not be "True Agile", but what difference makes for the poor guy that's forced to play a part?
Edit: I've had Scrum in mind all the time when writting "Agile". Sorry.
Not at all. If everyone involved in the project (everyone with a stake in the success of the project) agrees to give an agile process an honest chance, great. If not, you'll have trouble. A similar rule applies for coding standards, for test coverage, for security and logging, for transactional safety, for dieting, and for getting out of debt.
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).
The question I was responding to was if all the problems were caused by Agile or by deficiencies in its implementation.
If all you've seen is succesful projects, you can only guess why failed ones fail.
True. The project I have been a part of do have problems though. Sometimes the problems get resolved quickly and sometimes it takes a while or never happens.
Failure comes in many forms. I'm not pretending to have encyclopedic knowledge over the various ways projects fail. I do know that issues arise on the team and good communication often helps resolve these issues.
Also, having a good attitude is important. It's easy to be negative to your teammates (I have this problem), but it's also harmful and inappropriate at times.
In my experience, the biggest issues (or the largest cause of my stress) were often issues within the team.
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.
No McMethodology can make crappy programmers write good code. Period.
(However, really bad management can make good programmers write crappy code too...)
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.
Businessmen want (for reasons that are somewhat rational) to commoditize everything, including labor. Programming labor has been stubbornly difficult to commoditize. Programmers differ in skill in very deep and complex ways, and can't just be swapped out like assembly line workers.
This is immensely frustrating to the bean counters. Anything that comes along and promises to allow programmers to become commodities is going to catch on like wildfire. The desire is too strong from a management perspective. It doesn't matter how many times such efforts have failed in the past. What's old will become new again.
The point of Agile (and Scrum) is to give responsibility back to the clients/managers: pick one -> time or money, you can't have both; we'll show you why from our user-stories, cards, task-boards, poker-game, scrum planning, etc.
Agile theory does make some nods to not commodifying the programmers labor and giving programmers autonomy. But when it's sold the bean counters, they filter for the parts that get them what they want.
I agree. That's why I use a development process that encourages quick feedback. I don't consider that market research because I'm not out looking for customers to give me money in exchange for a DVD full of software. I'm sitting down with the person who hired me and demonstrating what I've done in the past week or two.
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.
I do think that poor developers can be taught to be better in a work environment, but it's a painful, slow process, and has to be started with an a keen devotion to the process on the part of the trainee, which if it were going to happen at all, would probably have already happened during college.
What exactly do these high-ceremony agile projects practice?
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.
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.
What I tell people is: what do you want? Do you want to never be told no, but never get what you were promised? Then use waterfall. Do you want to usually get what was promised, but be told you can't have what ever you want? Then use Scrum.
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.
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.
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?
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.
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.
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.
Can you elaborate on what you mean by this last part?
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.
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.