The games industry is rushing headlong to Agile development methodologies just now; it’s a great source of excitement for some, with conference sessions and magazine articles left, right and centre, and “evangelists” spreading the word.

I’m sick of it. I can’t wait for the day when everyone realises how much of a fad-diet, religious-cult-inspired, money-making exercise it is for a group of consultants. I can’t wait for people to wake up to the fact that the only good parts of Agile are just basic common sense and don’t need a “manifesto” or evangelists to support them. I’m looking forward to people realising that Agile is aimed at the lousiest of in-house enterprise-IT developers and holds no benefit to consumer product people like us. I’m hoping that people begin to see through the hype and recognise its dangers and failures. I want to stop hearing the phrase Scrum Master. Please, let common sense prevail!

Let’s slow down and start at the beginning.

What is Agile anyway?

To understand the Agile movement properly, you have to go back in time and look at the context of where it came from. The Agile people will say it was a backlash against the heavyweight, bureacratic, manufacturing-analogy-inspired development processes that became fashionable in the 1980s: waterfall, software metrics, and the CMM. And it was, but that’s missing the point somewhat. The key thing is that it was designed by consultants, aimed squarely at the world of in-house enterprise IT: a world where mediocre developers work for large corporations that don’t understand software development, but can afford to buy in expensive consultants to “save” their runaway projects. It was precisely these developers that were worst affected by overly-heavyweight processes (ironically, because those processes were pushed at them by consultants in the first place!) – pure waterfall and CMM never really caught on with companies that make software products (certainly not with game developers!).

At some point in the 90s, a group of consultants began to realise that bureacracy was killing the projects they consulted on, and they turned to some more lightweight, common-sense ways of developing software. Fair enough. But unfortunately, they needed to do more than that. Firstly, they had to codify and formalise their development methods, so their mediocre clients could continue to apply them after they’d moved onto the next job. And secondly, they had to make their methods trendy and fashionable, so that clueless management at big corporations would hire them in. Enter the “Agile manifesto” and “Extreme Programming”.

Put simply, Agile is one big money-making exercise for a group of consultants. That doesn’t sound so much like something you want to run your projects by, does it?

Where did we come in?

I don’t suppose the founders of Agile intended to suck game developers in. After all, we don’t generally pay consultants to “fix” our projects. Unfortunately, viral marketing, fad-diet schemes spread further than intended. At first, it doesn’t look like a good fit: game development has never suffered from bureacracy or heavyweight processes. The very reason for Agile’s existence isn’t a factor for us.

The trouble is, we’re desperate. We’ve had a project-management / development process crisis for a while now. Projects have exploded in size, and the traditional cowboy-coding approach doesn’t scale. Agile appears to be a good match because it promises to handle “changing requirements” (for us, that means designers chasing the elusive fun factor). A lightweight approach sounds good to people who are still cowboy coders at heart. Add on the marketing hype, and it’s not surprising that we’re flocking to it.

What’s wrong with Agile?

Firstly, beware following any kind of methodology. All methodologies imply a prescribed approach, a single-minded, fixed set of processes that removes flexibility and rationality. But in software, they’re fundamentally designed for mediocre developers who can’t think for themselves. They’re designed by consultants who won’t be around for long. It’s a bit like fast food recipes: rigid steps designed for minimum wage workers to apply thoughtlessly and without understanding. And that’s great: it’s the key to success for cheap fast food outlets. But I work on complex problems, and I’d like to aim higher than that. The main Scrum book has the cheek to pretend it’s better than a methodology, saying “Methodologies are like cookbooks: follow their recipes and a successful system will result”. They then explain how a methodology is defined by filling in templates, revealing that what they really mean is that Scrum is better than certain specific methodologies that went before, because it doesn’t have templates to fill in. Fine. But don’t make false pretences: seven pages later, they’re saying “I strongly recommend these practices be strictly adhered to until you understand why and how Scrum works”. Sound familiar?

A specific danger of the Agile processes is doing the easy parts and not the hard parts. I’ve seen a number of teams saying they’re adopting Scrum, but when you look closely they’re doing the trivial parts (such as daily stand-up meetings and calling someone a Scrum Master) and missing out on tricky but important ingredients that could actually help them (for example, making their team cross-functional and reflecting on their practices regularly). Similarly, it would be easy to take the trivial parts of XP (not doing up-front design) and ignore some important elements of the discipline (on-site customer, constant refactoring). There’s a massive danger for game developers here: you’re currently doing cowboy coding, you switch to an Agile methodology and trick yourself (and management) into thinking that everything’s going to be better for it, but you only take on a few cosmetic things, so you’re still just a cowboy.

Agile gives you an excuse for not introducing a little rigour and discipline into your project. Let’s face it, as game developers, we’re nowhere near in danger of using heavyweight development processes. We could quite safely do a little more documentation, design and planning without getting anywhere near a waterfall process or the CMM. Agile can get in the way of that.

Let’s take a look at a couple of specific points from the Agile manifesto:

“Individuals and interactions over processes and tools” I couldn’t agree more with, but strangely, Agile is all about following processes and rarely mentions that having top people is the best thing you can ever do for a project (you could say your hiring process is more important than your development process!).

“Working software over comprehensive documentation” is something I agree with, but I don’t see this changing game development at all, because we never document much anyway. This simply encourages people to consider doing no documentation as valid, which may be dangerous.

“Customer collaboration over contract negotiation” sounds amazing, and really could be beneficial to developers – but this comes under the category of “hard part, will ignore and do the other bits”. Traditional developer/publisher relationships are dominated by up-front milestone schedules and unrealistically rigid contracts that allow publishers to pull the plug at inconvenient times. It would be wonderful to have a different relationship with a publisher, but very few developers achieve this.

“Responding to change over following a plan” is valid strictly in the sense of not following plans to the letter even when they’re out of date, but I can’t say I’ve ever met developers stupid enough to do that. Again, the danger is that it gives validity to the idea of not doing planning at all, which is a common tendency in the first place. This manifesto item really misses the point of planning: the greatest value of planning lies not in the following of the plan, but in the making of the plan. In Eisenhower’s words, “The plan is nothing. Planning is everything.”

The bad science checklist

My checklist from last time (there’s a reason I wrote that post first!!) comes in handy when trying to cut through the hype. Here are some ways that Agile fails:

Not presenting all the evidence. Agile books love to give one or two case studies describing how great it all is. I don’t think I’ve ever seen the Agile proponents talk candidly about failed projects. It’s ridiculous to believe that there aren’t any at all (in fact, there are some huge ones – more on that later).

Personal observation and testimonial is everywhere. Going back to the Scrum book, their opening case study is a team of “eight highly skilled engineers … among the best I’ve worked with … It was said they couldn’t produce anything, that it was a total disaster”. For me this says more about the quality of people they’ve worked with than anything else! From what follows, the team’s management was certainly not highly skilled: they didn’t even have a list of the remaining software features written down. They couldn’t say no to feature creep and changing project direction. After a few pages of the consultants introducing basic common-sense practices, he says “it became apparent that I was fulfilling a management job”. No shit!

Being honest with the evidence. It is, of course, hard to find honesty from a group of people who are trying to sell consultancy.

Emotional attachment is encouraged throughout Agile; a large part of the movement’s success is owed to its fanatical cult-like support. This support isn’t accidental: the creation of a “manifesto”, talk of “values” – all have been carefully designed to attract emotional support, because that leads to free viral marketing and evangelical propaganda. Unfortunately, this emotional attachment can get in the way of honest, rational thinking.

Ad hominem attacks: if you’re not Agile, you get painted as heavyweight (waterfall), or a “cowboy”. Even if you were (and I’m neither), it wouldn’t say anything about Agile itself.

I should also point out the burden of proof. It shouldn’t be necessary to write about the problems of Agile; if Agile is so great, there should be some evidence for it. I struggle to see much when you look beyond the hype. Agile loves to show how it’s better than waterfall, and better than cowboy coding. Maybe – but I’d like to aim higher than that, because my team’s not doing either of those right now. Extreme Programming is one of the most prominent parts of the Agile movement; did you know that its inaugural project was a miserable failure? After that start, it’s a wonder it got any further – but I guess it had too cool a name.

Hyping common sense

The hype really annoys me! There are decent parts to Agile, but they’re just common sense. They don’t need a movement or a manifesto behind them, and they don’t need stupid terminology. I don’t see why I should have to call a colleague a “Scrum Master” and keep a straight face.

I don’t see why I should have to estimate a task in “Story Points” when, the last time I checked, units of time were perfectly good measures of the length of a task. Planning poker is great, but did you know that it’s just Wideband Delphi, which dates back to the 1940s? Admittedly, those Agile guys put a far catchier name on it.

I’m sick of the slavish following of methodologies. I’m sick of debating precisely how the role of a Scrum Master is defined. I’m sick of people referring to the Scrum textbook for guidance as though it were a religious text. I’m sick of discussing how to define velocity. I’m sick of debating what the best length for a sprint is, and whether different teams should sychronise their sprints or not. I’ve even heard a debate about the “correct” length of a sprint review. Grrrr!!!!

Scrum

Scrum’s probably the most prominent part of Agile in games just now. Where it works, it’s like a sticking plaster over a gaping wound: a set of processes that attempt to cover up the worst symptoms of dysfunctional software teams run by incompetent managers. If you’re a decently-run software team, it’s not going to help you. Let’s take a look at the Scrum practices in detail:

Having daily stand-up meetings is ludicrous; it exists simply to protect against the dysfunction of team members that never talk to one another. The Scrum literature goes on about how great it is that people can’t be blocked by anything for more than a day because of these meetings. In anything resembling a normal, common-sense team, people will surely raise blockages with their manager as soon as they occur and not need to wait for a daily meeting!

The <barf>Scrum Master</barf>, according to the book, is “a new management role introduced by Scrum … responsible for ensuring that Scrum values, practices, and rules are enacted and enforced”. Could you think of anything more pointlessly circular? A whole new management role, just to ensure that the methodology is followed. This is where you begin to see how Scrum is aimed at badly managed teams. I’m not a great fan of methodologies, but if you are going to use one, surely your existing manager should be capable of ensuring the team follows it?

The “sprint”, or in plain English, one iteration of software development, is nothing new. You’d have to be pretty feeble to benefit from moving to these. If you’re a smoothly running team, you’ll probably lose out as you switch to a fixed-duration iteration rather than doing the common sense thing of picking a natural time period to fit your circumstances. The various process bureacracy elements that come with sprints (sprint planning, sprint review, sprint retrospective) are also things that any half-decent team do anyway, just without silly names and not necessarily on such a regimented timetable. The concept of rigidly refusing to change what you’re doing within a sprint is clearly there to protect against feeble managers who can’t say no to their employers even when it’s in their best interests.

The product backlog is just an estimated, prioritised list of everything you have left to do. I find it hard to imagine a working software team that doesn’t have this already, whether in a bug database, spreadsheet or whatever. Again, this could only be of benefit to a pretty lousy team.

Having an assigned person (the “product owner”) to control the backlog exists purely to combat a crazy situation where multiple people tell developers what to do. Here’s where Scrum’s in-house enterprise IT background shows through clearly. You can just picture a corporation where the developers are second-class citizens, with a lousy manager, and anyone can tell them what to do, with no vision or direction for their work. I guess following Scrum helps these poor souls to stand up to the rest of their corporation. For the rest of us, it’s irrelevant. If you’re a software product company that ships commercial software, you’ll already have sorted out who makes decisions on features and product vision. And wherever you work, if your manager can’t spot this problem arising and fix it themselves, they’re incompetent and you have bigger problems.

The Scrum team itself! The team is, allegedly, “accorded full authority to do whatever it decides is necessary to achieve the goal”. This whole empowered-team concept is pure BS. Of course they’re not accorded full authority – nowhere near. This is simply about downtrodden, second-class-citizen, in-house-IT developers clawing back a tiny bit more authority than they previously had – authority that every other software team in the world takes for granted. Scrum also bangs on about the cross-functional team, as though this is some kind of revelation. There shouldn’t be any need for game developers to get excited over that. We’ve had designers, artists and programmers working together since the earliest of times.

The “Scrum room” – where all Scrum meetings take place – is apparently worth a mention in the process. All this says to me is that the whole process is aimed at developers who don’t even have a meeting room with whiteboards. By bringing in a Scrum consultant, perhaps they’ll get one. But you have to ask yourself: if your employer won’t give you a meeting room with whiteboards unless a consultant tells them to, don’t you have bigger problems?

There is literally nothing here of any interest to me. It’s a bunch of common sense (sometimes bordering on banal) stuff, with some very arbitrary decisions made for you on things like meeting frequencies, and some really stupid terminology. I don’t see how it benefits anyone but the worst of teams, and they have bigger problems. It’d be like trying to improve a crap professional sports team by copying all the trivialities of the best teams: when to eat, when to train, when to go to sleep, what to call the coach. I’m sure it would improve them and take some of the worst problems away, but it’s not going to make them great. Sorry for the bad sports analogy, but it seemed somehow appropriate :)

I would like to think we can all aim higher than this. And a number of people are starting to wake up to this too.

87 Responses to The Agile Disease

I won’t touch on the rest of your points, because although we try to use the good bits of agile methodologies, I’ve never much liked the way in which it’s been pushed by it’s backers, and I agree with many of the bad things said about Agile here.

That said: “I don’t see why I should have to estimate a task in “Story Points” when, the last time I checked, units of time were perfectly good measures of the length of a task.”

This one has caught me before when working with a client who did subscribe to the full on “Agile” thing. You estimate in Story Points because otherwise both the customers and the team can get confused between the difficulty of the task and the time it took/will take to complete it.

Specifically, customers see a set of stories estimated in days and don’t like the fact that that ‘days’ number bears a poor relation to the actual number of days it will take to complete.

Similarly, engineers see the ‘days’ estimate on a story and treat it as a time limit on how long the story should take, as opposed to actually looking at the task.

The numbers assigned to each story are only useful for two things; 1) measuring velocity, and 2) gauging cost of stories _relative to other stories_.

By calling them days (or ideal days, or whatever), you create the impression that you know exactly how long a task will take, when the whole point of the velocity/sprint/estimate tracking system is to accept that other things prevent you from knowing exactly how long a story will take, and the only true/useful measure is to look at how long a similar chunk of work took in the past.

Story points make it unambiguous – that you can’t use story points for anything other than velocity or relative difficulty assessments (e.g. a 10 point story is twice as hard and will take twice as long as a 5 point story).

You’re right-but-incomplete about the IT focus. It’s definitely there, but an important part of the history is missing. A lot of Agile grew out of the Smalltalk community, which included some very high-powered programmers. Smalltalk fizzled in the broader world but survived in, weirdly enough, places like insurance companies (mostly, I understand, because it let people quickly make changes). Some of the high-powered programmers followed their favorite language to those unfamiliar places and the collision between two cultures had a lot to do with the codification of Agile.

Or at least it seems to me – I was only acquainted with those people, not one of them. My center of gravity was product companies.

What’s more important is that “Agile” is a mixture – of ideas, people, motivations – so it should be hard to make claims as sweeping as you do. For example, my recollection of the workshop that wrote the Manifesto is that:

– the word “Agile” was coined with pretty much of a marketing intent, a name that sounded better than “lightweight”. (“He’s agile” sounds a bit better than “He’s a lightweight”…)

– the use of “values” was not done with marketing intent. There was a real struggle trying to figure out what people in the group had in common, the meeting looked like it was going to fail, and a couple of people went off by themselves and found the noun – “values” – and the format that let people come to agreement. So all that was a sincere attempt to explain something people knew was true but hadn’t been able to pin down.

– I think that I was the person to suggest “manifesto”. As far as I remember, that was my only contribution. I made it, I guess, was because I sort of have a problem with authority. More than that, though, was that I thought – think – that generally programmers and other team members get pushed around a lot by management or the business. That happens in both IT and product companies – remember I come from the product world, though not the game world which I suppose might not have death march projects that leave everyone feeling disgusted with what finally ships. So I wanted “manifesto” to jazz it up and get team members behind it, pushing back, instead of waiting for someone else to save them.

So, rather than being this thing crafted to inspire zealots, the Manifesto was a typical product of people – something muddled through to, with a heaping helping of pure dumb luck in the mixture.

Luke,
You are correct on most points. It is not for you or for me. The fact that it helps some people is both good, and saddening.
The only thing that really works is the Personal Software Process by Watts Humphrey. It is difficult to implement and hard to stick with. I would compare it to staying on a diet and fitness routine. If you have the discipline it is more than worth the effort.
Reality is that you can only change yourself. No management sponsored, silver bullet solution, methodology or tool will ever be as effective. That also means there are times in life when you have to accept the fact that others are not trying all that hard to be better. Sorry, I can not fix other people.

Chris – the story points info is useful and has certainly given me plenty to think about.

Brian – a nice surprise to hear from you, and thanks for looking past the ranting nature of the post! It’s very interesting to hear about what was and wasn’t intended originally – obviously something I could only guess at.

Agile processes may help, they may not. And you nailed it on the head with this: “All methodologies imply a prescribed approach, a single-minded, fixed set of processes that removes flexibility and rationality.”

I feel the same about this statement: “I’m sick of the slavish following of methodologies.” which leads me to wonder if we’re seeing a process bubble with Agilism: http://www.kohl.ca/blog/archives/000201.html where we have fewer people really doing practices and a lot of people cheering and jumping on the bandwagon.

I’d much prefer trying a process or tool, measuring it against our goals, seeing if it is helping us provide value and then adjusting. Right now we have a lot of “Agile-washing” or prefixing whatever we are doing with the “Agile” adjective and creating a lot of hype. Unless there is a good deal of value under that hype, I fear people may throw the baby out with the bathwater and return to overly bureaucratic methods because they are familiar and feel safer.

More inane drivel from someone who wasn’t there and hasn’t done his homework.

The bottom line is that the people who wrote the Agile Manifesto had no idea there would be a significant commercial aspect to it. We gathered at Snowbird because we cared about our industry, and wanted to effect a change.

Do some of us make money from the effort? Of course. I imagine even the author of this screed makes some money from his screeding (whether directly or indirectly). So what? Making money is an honorable activity.

As for Agile being “Common Sense”, gosh _we_ thought so too! It turns out, however, that there are a lot of folks out there who have been taught and trained otherwise, and who need their common sense perception refactored.

As for FAD diet. The Agile Manifesto was written in 2002. Six years is a long time for a fad, especially when the curve is still growing.

Sorry if I sound harsh, but I’m not feeling particularly charitable at the moment. I think people ought to be willing to perform due diligence before impugning the reputations of others. But that’s just me.

“Sorry if I sound harsh, but I’m not feeling particularly charitable at the moment. I think people ought to be willing to perform due diligence before impugning the reputations of others. But that’s just me.”

I agree with this statement for sure – attack the ideas, not the people.

Sure, this was a rant, a venting of frustration. That certainly led to some careless sweeping generalisations, but that’s half the fun of a good old rant :) By their very generality they don’t really “attack people” or “impugn reputations”. Much of this is about how the ideas are marketed to developers. And some of it is about the ideas themselves. Much is about bad developers and managers who try to adopt Agile and do it poorly.

The point about consultants is not a criticism of them per se. I repeatedly point out the money-spinning side of Agile because it’s important to take some material with a pinch of salt when (a) the author makes a living off people applying those ideas, and (b) their ideas may in some cases be aimed at the very projects that hire consultants, which I conjecture may not always have the same characteristics as your project. It doesn’t make them bad, and it doesn’t make their ideas bad: if you read the post, I mostly call their ideas common sense.

I just urge you to apply some critical thinking, not get sucked in by hype and make up your own mind about ideas.

Nearly all fads in management have some nuggets of value in them; over time, the fads die away and people just use the good parts without participating in the fad itself. Capital-A Agile will be no different: it’s just a question of when.

If you’re on an effective team, adopting Scrum (or any other “methodology”) is the last thing you should do. You’re already agile (I find hardly anyone can be effective in the long run without being flexible and thoughtful about their practices, and that’s my definition of agile). Just do what you’re doing already.

And I can relate to the frustration of having people mindlessly try to push “Agile” on you. (Hey, that’s annoying no matter what they’re mindlessly pushing.)

But… well, quite frankly, I’d say 80%+ of software teams *can* benefit from Scrum or some other “codified” set of practices, at least as a starting point, to either drag them out of their bureaucratic hell, or give them enough structure to move away from a completely chaotic process. Yes, many teams will fail to really “get it”, and will apply the practices cosmetically. But some teams will get it, and make the mental shift towards a reflective, thoughtful, flexible way of working. So “There is literally nothing here of any interest to me” is all fine and dandy; but that’s not to say Agile doesn’t hold a lot of value for a lot of people.

And believe it or not, there are those of us who use Agile terminology, and think more or less the same way you do. We only really care about helping fellow developers work effectively. We happen to find the Agile terminology useful. Yes, it’s all common sense, but to spread common sense you need to talk about it. To do that, labels help. Unfortunately, lots of people who just see Agile as a sales angle, or who have no real understanding and just apply it superficially, have co-opted that terminology. I’m not happy about that either, but I’m not going to surrender my favored terminology just yet.

Take this with a grain of salt by all means; I write a blog about Agile, I sometimes work as an Agile mentor of sorts, and I like to get paid.

I think my main criticism of this article is that while yes, all of agile/scrum is really just common sense, and shouldn’t be necessary, there are just too many people one has to deal with that lack common sense.

In those situations, it makes (a limited amount of) sense to apply some rules. Sure, it’d still be better to have a team that runs smoothly on it’s own, but in my experience that happens fairly rarely – unfortunately.

So that begs the question what sort of rules to apply. Personally I’ve found scrum to work well in those situations – probably because the whole thing provides more flexibility to react to unforseen events than most processes. At the same time it imposes a minimal structure that keeps everyone headed in roughly the same direction.

Of all the bad choices, it seems the least bad.

Then again, I’ve seen scrum misapplied and go horribly, horribly wrong… because there wasn’t enough common sense to even apply it properly, I guess :)

So while I agree with the gist of the article, I think it assumes that it’s easy enough to assemble teams that work smoothly, and use common sense. And I think that’s not even half as easy as this article makes it sound…

Thanks… I think “the good parts of agile are just common sense” sums it up.

The worst part of Agile/Scrum/fad-of-the-week is the micromanagement and “enforced mediocrity” that often results from it. Every time I’ve worked on a “scrum team,” etc., I’ve always felt as though I was being kept from doing the right thing and forced to emit what I regarded as inferior products. Agile builds into itself an aversion to what it sees as risk, which in some instances can be a good thing but most of the time seems to result in products that smack of being slapped together. There’s no room for individual initiative, pride in one’s work, polish, or taking the extra time to do what you know is the right thing.

Another bad thing I’ve seen is subordination of people to process. Good people make good software. Process is about finding a management strategy to make your good people work to their full potential, not putting them in a box to do what the evangelical consultant at your Scrum revival told you is the right way to do it.

If there is one industry where these sorts of approaches will fail, it’s the games industry. Game programming involves hard and deep problem solving, and games must have a lot of polish. Performance is also very important in games, and performance comes from coders taking the time and individual initiative to do it right rather than following a micromanaged agenda that forbids it.

You also have to consider what agile is competing against. In many cases, software dev management in the past was basically non-management. A bunch of engineers would be hired, told what to do, and then marched until they did it with very little communication or management of scope, etc. Doing the hokey-pokey and turning yourself around would be an improvement over this. Agile seems to be a miracle in some organizations (those with absentee management like this) because it’s competing against a null opponent, not because there’s anything all that great about it.

It’s a fad, folks. Nothing more. Take the good bits like the communication and scope control and ditch the evangelical consultant bullcrap.

I dunno. If this stuff is common sense, why are so few people doing any of it? Maybe it ain’t so common after all?

The author has some good points in his article, but blurs them with a lot of petty complaints. So what if Planning Poker is actually Wideband Delphi? I’d be willing to wager large amounts that the author had never used Wideband Delphi prior to his introduction to Scrum. How about if we just discuss whether or not it actually helps produce better estimates?

I’m not sure what to make of the comment that methodologies are straight-jackets aimed at inferior developers. Is that an argument not to have any process? I don’t get it. The scientific method is a methodology and it’s most decidedly NOT aimed at dummies.

If you don’t want to use agile, hey, no problem. But if you’re actually serious about getting things done, you probably have a bunch of “work agreements”. Hey, guess what, that’s a process/methodology. Is your process aimed at stupid people? I thought not.

I think you are largely correct, however I believe it is incorrect to reduce the whole Agile idea down to greedy consultants.

Smalltalk paved the way:
– Everything is an object
– Everything is a message (even more fundamental than the above)
– Things may be agile and flexible which is not bad.

This movement is more against the strict-static handcuff mindset that has dominated Java, and we all know that Java in the past dominated the economy completely (and still has a huge foothold, but I think as a language it is not really evolving a lot anymore).

Lets jump a few years to the future after smalltalk.

Enter The Ruby.

The concept that as long as it walks like a duck and talk like a duck it can be treated like a duck – or in other words, it does not matter if it IS a duck, it should just DO things – is a concept I think is very close to the core idea behind prototype based object oriented thinking.

I am NOT talking about the old prototype concepts, I am talking about new ideas. The focus on agility IS not bad.

The central aspect is reuse of CODE PATTERNS followed by BEHAVIOUR PATTERNS.

Now Ruby is a success – it has grown a lot – but ruby in the game industry is no success at all.

The biggest reason I believe is the speed reason. Everything else can be solved. But people who want speed would use C++ engines tied with i.e. Lua.

So agile in game programming wont really become a huge success in general, really. Lua is not as good as python or ruby. And everyone will use C or C++ either for Games.

But the concept behind staying agile, modular, flexible, is much better than the TOTAL strictness behind many other languages.

The secret isn’t necessarily “agile”. It’s people. When a project succeeds it’s because the team were talented and worked well together. When it fails it’s usually because the team, or people on the team, failed to deliver. The process is secondary – good people take responsibility and get the job done. Agile methods can provide developers with a good environment to display their talents. But it’s still about the quality of the people.

…you nailed it on the head with this: “All methodologies imply a prescribed approach, a single-minded, fixed set of
processes that removes flexibility and rationality.”

There is no one agile method, and Scrum, which seems to be the most widely-used ‘process’ specifically says it is not prescriptive, but rather a framework. The principles lead to certain good starting practices, but one of the key principles is to reflect and refine the process to fit your particular situation. As several other folks have said, yes, a lot of this is common sense, but common sense is very uncommon, and needs to be learned. Look at Ken Schwaber’s site – http://www.controlchaos.com/. The tagline is “Its about common sense”.

That’s the problem from my experience. This “framework” is very strongly worded as what to do. I mean read the lists on what stand-up meetings are about, or the role of the Scrum Master.

Scrum is a process, whether they call it one or not! Adapting Scrum principles to what might work best for the team as we go along has always been met with arguments that Scrum doesn’t prescribe that, or the book says it should be done this way. Having arguments with my team about whether or not we should extend a sprint by one day (due to commerical realities) is not what I want!

You’re right that Scrum has many common sense points; and I actually think that’s the point, strange as it may be.

The founders of Scrum, consultants thought they may be, didn’t create Scrum thinking they were being original. Everything in Scrum came from existing, pragmatic, techniques that other people were employing, particularly Toyota (which definitely wasn’t doing LEAN for software dev purposes). So, to your general complaining about it being common sense; that’s a good thing, it means that finally, someone, somewhere has taken the basics, written them down, and we all look at it and say, gee, that actually makes some damn sense.

Second, Scrum is an interpretation of Agile. You could just hand someone the points from the Agile manifesto and nothing else and say, “here ya go, now go make software.” Scrum just gives a little extra structure to the 10 points.

So, to your final point about aiming higher, sure, I agree. Thing is, there are a lot of teams that are lousy, that can use some common sense and could benefit by rescuing themselves through the use of simple, tested, agile techniques (if they actually try out and follow them).

What I hear you saying is that your personal team is already high-performing. I don’t remember where it was said but I have heard Scrum evangelists say, quite clearly, that already high-performing, getting-along-well teams would benefit only marginally, if any, from employing Scrum. So, since you’re claiming your team is already high-performing, then you’re saying you either don’t need Scrum or are already implicitly doing many of the common sense things it suggests. If that’s the case, why complain? Just don’t worry about it and let Scrum benefit those that it can. Or, maybe you are just sick of the hype from other people. I can understand getting sick of hype. For example, much as I genuinely like a lot of Apple products or Ruby on Rails, I can say it gets pretty old to hear people constantly tout the fan-boy love for each. And so it goes…

Gee, where to start. Very sad. Much of your (mis)information is couched in typical misunderstandings, myths, ignorance, and innuendo. You obviously are ignorant of agile for a multitude of reasons that are evident in your because they certainly don’t qualify as “methodologies” – there is such little structure around them that using the term would be insulting to methodologies.

“A specific danger of the Agile processes is doing the easy parts and not the hard parts.” Duh. That is danger in any way work is approached.

“Agile gives you an excuse for not introducing a little rigour and discipline into your project.” Please…that excuse can be applied anytime, anywhere.

Well, I could go on and get fully sucked into this nonsense, but what would be the purpose? Agile is working for 1000s of companies and people, and certainly a much needed improvement over the old ways. Your rant is just noise. It reminds me of the BFI Rush Limbaugh – all philippic and no reason or logic.

These “methodologies”, “doctrines”, “paradigms” — they’re the exercise fads of IT. Every five to ten years there’s a new one that gets all sorts of people excited.

The seed that starts them is almost always some half-baked science, a few success stories, and a successful proselytizer. Some are silly like “HeartWaves” and Taebo, some more general like aerobics, spinning, and pilates. Oceans of books published, DVDs sold, TV infomercials watched. (What they have in common? Exercise frequently, better results!)

And here’s IT’s microcosm. Again, they start with the seed of some sketchy logical jumps and a few success stories, and then commence the full-on proselytizing. Yet when excellent managers find they have success with XP or Agile or whatever, their success is more because the managers are capable and the workers competent. Think of the best developer you know — would she produce better work in one or another methodology?..or is the reason she’s the best developer you know because she can micromanage herself best?

(And what do these methodologies have in common? Work carefully, better results!)

There will always be a market for this kind of thing because it’s a kind of blame-shifting. People can’t revitalize their workers or themselves, so they go out and buy a book in a gesture of self-improvement. How much easier it is to buy the South Beach Diet for $24.95 then to actually -go on a diet-.

Meanwhile the books, the blogs, the convention speakers will continue to rake in the cash. Plus ca change…

Your article if full of ad hominem attacks in your article – a lot of your problems with the agile and scrum seem to be the bad preachers and practitioners of scrum. Of course whenever there is a trend or an idea there’ll be cranks who write bad books about it, sell it as a silver bullet and people who implement it badly – implementing the easy points without understanding what agile or scrum is getting at. Yes, that’s because there are some pisspoor people around and indeed I’m sure there are pisspoor people working in your sector, too.

None of that invalidates scrum or the core principles behind it. What scrum does do is provide a set of guiding principles that will make development easier. I’ll pick a few:

* The product backlog – have a central (to the team) and easily accessible place where everything that the team needs to do is written down. This is much better than having it in a project manager’s head or a having a wierd combination of disparate bug and feature lists and somehow expecting everyone in the team magically know and agree on what needs to be done when.

* Have a product owner, a single point of contact to talk to. If your business (or team) is only working on one product, then you’ll automatically have that, and that’s great. But most companies, even the ones that aren’t second class enterprisey entities, have many clients or competing priorities, and managers will often go to the developers directly, distracting them, which makes everyone unhappy.

* Have fixed length development cycles and review the priorities at the end of each cycle. It’s much easier to coordinate and development of new features if you know that you are free to reassign developers at the start of each cycle. And if a feature isn’t working out or is becoming too hard to develop you can abandon it at the end of the cycle. You do have a decent source control system which lets you revert changes, don’t you?

Now if you’ve done them before and they work for you, then they might seem exceedingly obvious, but in a lot of pre-agile teams I’ve worked in have suffered from some of these problems. If a developer gets promoted into management without being made aware of these pitfalls, they’ll run into a lot of problems agile addresses, and that’ll be the case, no matter how shit-hot they may have been as a developer.

Of course saying “hire good people” is obvious advice and central to an organisation’s success, and of course and everyone has their own idea about how hire the best people with the budget they’ve got. And it will help, but that’s outside the scope of scrum. A scrummaster might say “we’ll assume you’ve done all you can hire the best people you can, this will help you manage them as best you can”.

But you seem to have this wierd worldview that there are two categories of IT, the smart sector, and the rest. The smart sector, which happens to be the sector you work in, is mecca: Only the best can apply, it’s full of smart people and everyone is working brilliantly together and turning out reams of beautiful code. The other sector is populated by huge enterprisey IT-shops where only sub-humans work, begrudgingly churning out third rate code, everyone hates their job and it’s complete mayhem.

But that’s not true, is it? You said yourself you have a big project management crisis, and if you’re desparate, as you say you are, then there must be something dysfunctional happening somewhere along the line. If everyone was as shit-hot as you keep bragging about, then it’s unlikely you would have found yourself in that mess. Maybe it would be time to take a look at what it has to say, see if it addresses any of the problems in your company, and examine its ideas with an open mind, not an open mouth.

At the heart of your paper I think you actually agree with agile philosophies than you disagree. Your observation that most people doing Scrum don’t do the hard parts then wonder why they fail. Is it really a mystery? How much of this rant is really about a distaste over the theory put forth by methodologies vs. the poor implementations people do. At some level, I think it’s the later in your case.

You seem to just have a general disliking for terminology, or a lack of real meaning what Agile people mean when they say things like “Don’t follow a plan.” I actually think it’s a little of both in your case. We’re all beginners at some point, and there’s nothing wrong with that. As for terminology I think hearing the advertising language like “Don’t follow a plan” over and over gets painful if that’s all you hear. And, it loses all meaning after a while. But, phrases like that don’t really encapsulate the true meaning of what Agile is trying to say. At some point you have to go deeper and then eventually that phrase will have real meaning to you as well. And you’ll annoy other people by talking about it all the time.

For example, when Agile people say “Don’t follow a plan.” they are really talking about the same thing Eisenhower meant when he said “The plan is nothing. Planning is everything.” Eisenhower, too, is saying the product of planning is not that important because things change. That’s exactly what Agile is saying too. Creating a plan is important, but following that plan is not. The difference in Eisenhower and Agile is how often they plan. Agile doesn’t plan all at once. It’s spread out over your entire project.

Agile people plan, but they do it in very small chunks. They don’t create one massive plan and try to follow it to the end. They plan at every start of a sprint by choosing what’s going to be in the sprint. Long term plans are sent to the backlog, but those are less important than the immediate plan. It’s important to remember them though. That’s far better than most non-Agile practices because those thoughts rarely get written down. At least Agile practices write it down in a common place so everyone can see and prioritize. In planning for the sprint you have say this is more important than that, or this must be done before that. This is a must that’s not. That’s planning.

I think what confuses some newbies is that planning means creating a vision for your product. And that’s not it at all. Really Agile just says Vision comes from somewhere (users, product managers, customers, other developers, qa, etc) and here’s a way to execute on that vision. I think what’s the trick is getting your Visioner to Vision throughout the project in small chunks and not all up front. And, not get attached to one vision when a better one might emerge.

As for your general distrust of commercial endeavors well your own your own, but sometimes things that cost money are trying to help you.

I love the quote “60% of software projects failed before agile and we’re seeing 60% of agile projects fail. What this tells me is that 60% of people are just incompetent.”

I won’t go into detail about your post, but it seems like you’ve been seeing agile through the eyes of the people who just use the structure (backlogs, meetings) and not the underlying concepts that make it work.

SCRUM, run by a zen SCRUM master, nearly has no rules and no bullshit. It’s all about being lean and getting results, ensuring that you have a capable team (it only works w/ senior people) and keeping the goal in mind.

Just to give you context on one of the many points of misunderstanding you have, the daily standup. You said a team wouldn’t wait until the daily standup to say they were blocked… and of course not, thinking that this is what it is for is only something that B or C team players would think, “oh great, I dont need to do anything today and I have an excuse that I’m blocked so i’ll just read reddit.com until tomorrow”. That is failure of selecting the wrong team members. The real purpose of the stand-up is (for one thing) to report to the Product Owner the progress and status of everything in a quick way that covers the entire team. It’s also an bullshit checking device for your team so you can weed out the B and C players because those are the ones that will not be making real progress daily.

Oh thanks you, thank you so much.
So p****d off to have to day after day discuss the finer points of semantical nonsense with consultants while my team is fighting to keep the boat afloat.
So totally cheesed off to see people actually believe in this creed.
As you state, Agile is just repackaging of common sense with stupid terminology and doesn’t actually address any of current software industry problem.
Hello? Quality? anyone, I’m trying to get my engineers to wite good specs, you know like RFCs for instance, so my customers actually know what they get and my test team can actually test the thing and what I get is Stories and Epics! Hello, WTF, can someone explain to me how civil engineers would build a bridgeg with “Stories” or how aeronautical engineers build planes with “Epics”.
Last story I got was ” yeah the socket dude, talk to the web server dude and download 1 page” How much more stupid will it gets?
At times just substitute the agile manif with Mein Kempf and it makes you understand how millions can be convinced to happily run to slaughter.
When the last consultant will have been hung with the tripes of the last Scrum Master, the software industry will be a better place.

despite being an agile consultant (one of those you seem to hate : ) ), I agree with most of what you said.

Agile is common sense? It probably is, as good management (outside sw) should be also common sense, but I cannot be more surprised with all the against-common-sense practices I keep seeing all around, in all industries.

“A specific danger of the Agile processes is doing the easy parts and not the hard parts. ”

The whole issue is schizo. I remember when OO design modeling held so much promise. We awaited the unification of the three great minds (UML) and amazingly, it fizzled. UML 2.0 added more rigor and the ability to create models that could be directly compiled into functioning software, which amazingly signaled the death of OO design modeling.
My theory is that OO design modeling worked best when it was underspecified and fuzzy. It simply was a tool that allowed developers to capture and express their ideas in a loose, free-wheeling medium.
Now, big up front design is scorned as it implies a phase in which developers follow the dictates of a modeling language to create artifacts, not necessarily to create a quality software product.
That said, any OO project would benefit greatly from the services of an experienced designer/modeling who could effective factor functionality across modifiable, testable classes.
The hallmark of a good OO model is that it captures and communicates. It should be able to be created and modified quickly. If it captures and communicates then it is complete.
I read Alistair Cockburn’s Agile Software Development years ago and it changed my professional life – he says that software development is primarily an excercise in communication and he is right. Alistair also says that he has never seen a successful project that used OO modeling and in this case he is wrong. Like I said, this stuff is schizo.
My recommendation is to be ‘dictionary’ agile, not ‘co-opted’ agile. Use practices that be best fit your domain, tools, experiences and most importantly your people.

Consider these too statements, written within a paragraph of each other…

“The trouble is, we’re desperate. We’ve had a project-management / development process crisis for a while now. Projects have exploded in size, and the traditional cowboy-coding approach doesn’t scale. …

Firstly, beware following any kind of methodology. All methodologies imply a prescribed approach, a single-minded, fixed set of processes that removes flexibility and rationality. ”

This article reads to me as a big whine:

“Really good coders don’t need a methodology, pah! Methodologies are just for drones who don’t know how to get things done. Real coders fly by the seat of their pants.

… Oh dear, seat of the pants doesn’t seem to work for big, complex projects. Well it should, you just need good coders…

This is quite simply the most elevated and aptly written article I have ever seen on the subject of SCRUM and the so-called Agile methodology.

It remains a complete mystery to me how programmers, whose daily work involves the application of logic, can blatantly believe that mindless adoption of a cookbook approach will lead their particular team, project and company to success.

The so-called agile (agility through rigidity is something Orwell would have liked) development is to software engineering what scientology is to religion.

After carefully & patiently reading this article, i have to say that looking beyond the ranting, the thread that runs through this post is that agile is hard, and that is my friend, very true.

I do agree that there is a number of “consultants” out there that try to sell agile as the “silver bullet”, but as you learn and experience you get to understand that practicing agile is difficult, it requires discipline, commitment and skill, and if you don’t have those, you will be mediocre with any methodology or practice you choose.

A point worth mentioning is that agile methodologies and Scrum specifically is built in a way that it will surface those problems pretty quickly, this provides you with more data to support good decision making.

Over the years, I continue to learn how to do better software development starting from Waterfall (wasn’t the industry’s favorite punching-bag Waterfall a 10X improvement over the pre-Waterfall days – for if it was not, no one would have adopted it notwithstanding its ‘obvious’ follies), Sushimi, Spiral, RAD, RUP, IID, Agile, Scrum, Lean, Kan-ban,…I think it is the strength of our industry that we continue to re-invent ‘common sense’ because nothing is more time-, age- and place-specific as ‘common sense’. From my viewpoint, Agile brings a lot of circa 2001 ‘common sense’ that is so very relevant even today.

However, like every good thing in life, Agile is not perfect. There are some limitations, like complete absence of explicit result-orientation (which of the twelve Principles behind Agile Manifesto talk about what is customer’s reaction to whatever we are trying to do ?), a visible lack of willingness to attibute project failures to Agile practices (so, when Waterfall projects failed, we blamed the process, now when Agile process fail, we blame people for not following through the Agile practices ???), lack of willingness to accept that a man’s creation is also subject to genetic evolution (by the way, all of god’s living creations are entitled to genetic evolution) and hence it is about time we all moved to Agile 2.0, and so on. Despite these limitations, Agile is the best evolution that we have today, and must continue to evolve lest it be considered out of touch with reality.

For me transition to Agile means actually a change. It is very much a “religious kind of convertation” in a big company and I’m sure it has the same origin in human mind that religions build on too.

The good thing is the change, not the methodologies like Scrum or XP. Change can be used as a good tool for throwing out some fixed viewpoints and for introducing some “common sense” instead.

I’m also sick of hearing all kinds of “religious cult talk”. It’s scary as it shows how human my professional colleagues are too. Many of them could easily be converted to some true religious cult too! (Hmm, perhaps some of them are already?) But I don’t let that bother me too much, because I wan’t to use this change as best as I can.

That means I have to act along sometimes and pretend that I’m into “Agile” while I’m really just trying to improve the efficiency of our teams whatever way it’s best. Agile transition is a good way to get support from the upper management that has power to invest money and make decisions about the fremaworks how to proceed. Just insert some hype words here and there and put in some citations from “guru’s” and voilâ, another passage is open… :)

> Nearly all fads in management have some nuggets of
> value in them; over time, the fads die away and people
> just use the good parts without participating in the
> fad itself. Capital-A Agile will be no different: it’s just
> a question of when.

Not soon enough. I’m one of those evil consultants who happen to make money off of working with those great unwashed IT masses you so disdain. I too will be thankful when the word “agile” goes away and we just emphasize “the good parts.” I’ll still make money off of helping teams improve their ability to deliver software.

We don’t hear that much about XP anymore but we do hear a lot about things like continuous integration and TDD, two of several ideas it helped entrench as solid practices. Unfortunately we do still hear a lot about Scrum, for all of its fairly obvious ideas.

> I would like to think we can all aim higher than this.

I read “Development Without a Name,” a much more useful post. But where’s the aiming higher? As far as I see, your description in that post represents what a good process should be–iterative in nature, balancing both ends of the spectrum (i.e. using ideas from both adaptive and plan-driven methods), and customized to suit your team’s needs. Sounds like “agile done well” to me. Where are the new, great ideas? Or do you mean by “aiming higher” that we stop talking about process and assume everyone is smart enough to have done similar things on their own?

What exactly does “aim higher” mean? From this post alone (not considering Development W/O a Name), all I gather that it means is “stop talking about Scrum and go use common sense.” I wish it was that easy, but it’s not; for example, common sense would indicate that TDD and test-after development (POUT) can produce the same results, but common sense is just wrong here.

You’re sick of debate over velocity, iteration length, etc. Yet I’m not hearing how teams should derive their own best practices. Telling people to pick and choose practices from the 12-year-old Rapid Development isn’t aiming higher, it’s ignoring 12 years of widespread learning and experience out there. There are plenty of agile failures *and* successes to learn from.

Not all teams are as great as yours or others from the game industry. In fact, the great majority are in need of structure, discipline, education, ideas, and morale boosting. And while I agree that it all starts with hiring, I’m not so cynical (or arrogant) to assume that those “clueless” enterprise IT developers can’t learn how to deliver solid software. They can, and there’s money in it for them (and for us evil consultants who help them improve).

I think we need to make a distinction here between critique of Agile itself and the adoption of Agile as a methodology. Or rather, the adoption of *any* methodology.

I’ve seen methodologies that were cumbersome beyond belief and ones that were just this side of genuine chaos. In most cases, the development teams and their management adopted the methodology in question as a state religion: If we follow this methodology, we will all reach heaven (where “heaven” the satisfaction or exceeding of the requirements). Often, there was no room for dissent from the canonical faith, regardless of the state of the project.

It may just be that Agile, like common sense, requires one to be mindful, even though many of us choose methodologies as a substitute for mindfulness.

(Having said that, I do agree that we should be wary of anyone trying to sell silver bullets.)

I find all the whining noise here terribly disheartening. To read this thread one would think that very few people understand the value of Agile and it’s associated domains of Lean, Scrum and XP.

I have tried to cut through the posturing of the various brands and their detractors with some simple definitions at the bottom of the home page of AgileBazaar.org. There I try to be specific about unspecific ‘Agile’ is. See what you think.

On ‘Common Sense’ – I take that as ‘It’s obvious to me’. I tell my client teams to treat references to common sense as giving them permission and encouraging their use of their sense. By that I mean, their independent thinking. I’m formally anti-dogma. ‘If you don’t understand the value of a practice, don’t do it!’ On the other hand, if you think it makes sense ‘sort of’, but need to experience it to be sure – just do it and evaluate the experience. Again, take the responsibility for independent thinking. Group think is abdicating your responsibility as a professional.

On ‘methodologies’ – I point out that an ‘…ology’ is a ‘science of…’, when used properly. How many people do you know who use it for the discipline of comparing and contrasting methods and their appropriate context of use? In most cases, the term is used by people who want to pompously misrepresent their method as bigger than it is. In contrast, I think the Poppendiecks are an example of methodoligists.

On ‘Scrum’, I see it simply as a discipline for open, honest, focused communication between members of a creative team and between that team and those paying them for their creativity. It helps manage the attention of the team to focus on productivity and building trust.

When Scrum is seen as down-to-earth, useful thinking tools, it just makes sense. When it’s seen as dogma to be obeyed, there is little hope for success. Thinking is required!

Why do we need consultants and coaches? Because we are asking people to change habits and that can’t be done by reading a book or taking a class and being told to ‘do as you’re told’. Habit change needs a support system. That’s the job of the Agile coach to the team and management.

Calling the role ‘ScrumMaster’ is just useful theater. I like the bizarre Scrum jargon because it avoids the baggage that comes with traditional jargon. It encourages thinking again – something that is hard for most of us to do. People’s sense of self-worth is typically tied to their habituated behavior. Breaking through that is the biggest challenge I see as an Agile transformation agent.

I have never had a team I trained and coached fail. And the teams finds it a joy to be so open and honest.

I think a lot of Luke’s points can be countered with the manifesto statement: individuals and interaction over processes and tools.

If one were to give a bunch of monkeys any process, however brilliant, the monkeys will fail to come up with anything decent.

I do not see that the widespread failure of teams to make the most out of, say, Scrum, is any criticism of Scrum itself. It’s a tool to be used, and will only ever be as good as the persons applying it.

And surely, this is the reason why the lead thinkers in agile methods exhort us to apply the methods rigorously: because it we only nibble around the edges we are not going to realise the benefits and will simply fail in new ways.

And can it be that the almost-religious fervour that surrounds agile methods exists because so many have actually found them to be advantageous and deliver real benefit? At least, that’s my personal experience. I strive to apply Scrum to the best of my ability, but it’s so light, it actually frees me up to focus on the things that really count.

And I think Luke’s talking from a very one-sided viewpoint. It’s not about the developers. The benefits of agile are only realised when all persons in the chain are working together. Agile is about being able to stay in touch with customer (business) demand. It’s about nothing else, so let’s not tar it with the wrong brush.

For agile to work, agile must be understood. The problem is (it seems) that so few understand what it’s about thinking that going through the motions is enough. Hey, you want to define what a Scrum Master’s job is? The largest challenges in any way of working exist between people’s ears, so why not have someone dedicated to helping unblocking those plugs? If you ask me, a good Scrum Master is worth every penny!

Finally, yes, one can claim agile is just common sense, but common sense is paradoxical: if it was so common, we wouldn’t have to speak of it.

I would like to oppose the opinions presented here: I think agile is something truly new.

What is coding is not “try and err” process: you code something, compile & test and fix and then you try again.
Agile (and scrum) brings that iterative nature up to team level (and potentially further) – the metaphor for scrum is a “control loop”. There is as great difference between preplanned waterfall projects and all the time feedback/correction seeking agile projects with rolling planning as there is with planned economies and free market economy.

What is it you control with your control loop? The changes that come from the reality of the implementation, the better understanding of the problem we are trying to solve (we are in the business of creating well-definined solution to ill-defined problems as Paul G. Basset has put it) and the change in the business environment.

In small projects the communication is easy and it is easy to change the course when reasons occur but as the need for software increases and the sizes of the projects increase the communication needs grow exponentially in releation to the people involved (as Brooks has explained in Mythical Man-Month) —> agile backlog management, control loops at all levels (nested control loops) are the only way to build this “continuous adjustment to the current existing conditions” into your project.

For me this agile is a paradigm change: we finally get to understand software in its own terms and stop borrowing from other diciplines (like manufacturing) that are bounded by different laws of nature; physical constraints.

My team lead (former consultant) is a huge agile and SCRUM guy. He has had success with it in a corporate setting, but we are in the business of getting stuff done quick. Our iterations can be hours, days, weeks or months. I think that SCRUM can help a team that is working on a large project, but only if everyone buys into the “stand-around” meetings.

Ultimately, having a status meeting equates to the same thing as a SCRUM meeting – just not necessarily on a daily basis. If the shoe fits, I guess…

We have been told that Agile will help our team and projects. Most of the developers around me use agile to turn away work and not work on support. It has truly enabled the laziest of developers to jump on an opportunity to get a pay check for doing the absolute minimum or nothing at all.

Our CHUM master is living proof! It’s like he throws the CHUM out, but that’s it.

Any development methodology used is not very effective unless leads/mentors understand how to customize and use it for given team. We have used scrum effectively for many years now and we have found it beneficial.

From a developments point of view lightweight, practical methodologies are best if requirements are subject to change; team needs to deliver working releases in short term durations.

So every one in team needs to follow methodologies honestly to get real benefit out of them; else its one more fancy word added to list of technologies used.

I’ve been an agile “believer” for a couple of years, and can safely say the only product I’ve ever delivered and been proud of was done with Agile and Scrum. I almost never work with idiots, or merely mediocre people. I have ALWAYS worked with dysfunctional teams (except the one I mentioned). Scrum is about making dysfunctionality (is that a word?) visible, so management can get out of the way, if they so choose.

And marketing is everything. Look at Microsoft to see that it doesn’t take good software to succeed.

Great article, but I’m hoping you’re not confusing masters and followers…

Suppose you were to write a coding bible for the unfortunate ones, you’ll have to communicate your “common sense” in one way or another. How can you best achieve that? There’s always the risk of that gospel to be taken literally by idiots, or simply used politically by sad apprentices to justify some wisdom towards an usually clueless authority. Following that, “common sense” tends to get lost. This is nothing new. I think Lao Tzu used to point that sort of things out.

Mediocrity is often a result of apathy mixed with bad and non-existent mentoring, of beginners going through the motions of what they’ve been taught, of programmers who’ve accepted to adapt to insensible constraints. We all do it, in one way or another. Myself more than others. And because we want to grow up straight, we look for guidelines : we read books and join little cults, we even pass around copies of the verses that spoke to us. We want to be saved.

I think the parallel with religion isn’t all that bad, even if it’s a bit sickening, if not downright sick. You can come through inspiring believers who can help you to grow into a sensible person, just as you can meet terrible preachers who will disgust you about anything related to their fetish. The common workplace, for instance, being at the same time cheap and plug’n play elistist, tends not to favour the growth of programming talent.

If there’s a single lesson to be learned from all this, it would be: thou shall not be afraid to run away from a dead end job in order to find an inspiring crowd. After the deception of a failed professional life, I can only pass this small tip around.

I have to say that I’ve been reading for the last week or so on whether Agile is really a methodology or not, or is it just Project Management done with a twist.

Your article is one of the funniest I’ve ever read, the Scrum Master thing was hilarious.

I do agree that it seems that some people are following Agile religiously, but I think the main reason is that a lot have grown into Agile (as it dates back to the last millennium), meaning they immediately worked in an Agile environment (whether as developers or as Project Managers), and they probably think that there’s pain, hard work, and never ending projects outside the Agile world. I’ve seen companies implementing Agile when normal Project Management was working for them, and if it’s something to blame for and if there’s anyone to blame, it’s management (particularly IT Management), trying to make some activity to impress upper management (eg. let’s use XML because it’s cool). The most important thing for IT Management is to look busy, introduce new things, and to spend all its yearly budget.

What’s probably making people so attached to Agile (other than they’re used to it) is the strength of opposition they’re getting from outsiders (eg. people following waterfall, or people who just don’t care about any methodology).

There are, on the other hand, some people using (not following) Agile (I have just published an article by one of them listing the weaknesses of Agile). What these people really care about is getting the project done, regardless of the methodology used, which is probably the whole point of Project Management.

This original post is a silly rant. When you start putting systems on planes, on cars, on cell phones, on medical devices, or on space craft, then tell me you don’t need Agile. When you live 1 month with heavy-weight processes, then tell me you don’t need agile. Game development is a particular space, and all that seems to have happened to you is that your a little bitter that someone is treading on your party to get the value that 1000s of others have gotten.

I will say, in your defense, that whomever is changing your company towards scrum isn’t doing a perfect job, because they should have your buy-in (assuming that’s possible). The process should map to your environment and then bring you along with it. In a way your a victim of bad change management.

But give them a break…they’re trying to put some structure in a very expensive and complex environment, and they are with you.

It’s a bit ironic that someone who doesn’t work in a corporate IT environment “knows” so much about it. Foot-in-mouth is also a “disease.” ;-)

It’s also a bit ironic (in view of your comments) that most people in the agile community today strongly dislike the fact agile methods are being embraced by “mediocre” corporate types, since they see themselves mainly as software craftsmen, and “agile” as an approach that absolutely requires craftsmanship and strong software engineering skills. It’s quite the opposite of a methodology designed to enable mediocre programmers to succeed in spite of themselves. There’s even talk about jumping back across the “chasm,” since many practitioners don’t like the lay of the land on the far side and would rather scale back to working with a handful of highly skilled associates/friends to build small applications they personally care about. Ah, sweet temptation!

When you rail against following a prescribed methodology mindlessly, you’re actually singing with the agile choir and not against it. There is no “agile methodology,” there’s just a short list of values and a slightly less-short list of guiding principles. Unfortunately, some companies are selling agile-in-a-box that doesn’t work quite so well, and giving the whole idea a bad name. Maybe it’s time for a new name.

I hope you’ll allow people to try and make a living doing what they know how to do and what they enjoy doing. Some of us actually get more satisfaction from helping others succeed than just from writing code. From your negative comments about consultants, I suppose that means you don’t relate to that form of professional satisfaction yourself. That’s okay. Different strokes.

I agree with what you say about common sense. I just wish it were a little more common.

BTW, if agile doesn’t work for game development, what’s happening at High Moon Studios these days? Have they crashed and burned?

This is in place of an opinion of my own because i think all has been said here already.

I only want to sum up my opinion on Agile and Scrum and that is: it’s not common sense as has been pointed out, it’s not just for the mediocre teams and i don’t care wether some people advertise it blatantly. And yes, the main point is to implement agile methods, evaluate and reflect on them, change and improve. Rinse and repeat.

Actually, there’s much worse blatant advertising and purely commercial motivation in the world around us, so i think the Agile, Lean & Scrum facilitators are actually pretty moderate and reflective in their talks. Just check out some of the talks i have on my homepage: http://www.gaminghorror.net/scrum-resources

I really don’t see the commercial aspects being in the foreground, if anything they’re making a sales pitch and i, as the potential costumer, have gained a good understanding of what i would be getting myself into if i’d hired one of the Scrum “evangalists”.

And charismatic “evangelists” can be a good thing, you know. Evangelists are only as bad as the people who’re following blindly, without them applying critical thinking. On the other hand if all you have are critical people, you don’t go anywhere without someone being an “evangelist” – solid as a rock but still open, honest and listening to rants like yours. ;)

“it’s not just for the mediocre teams” – this should be documented as a non-starter for Scrum, upfront and in big bold lettering.

I’ve witnessed the horror of a “self-managing” team of talented but inexperienced programmers take 6 weeks to do what should’ve been done in 2 weeks. Beneath a “story” is a whole swath of what could be done by programmers to have it implemented. Teams need leadership to direct their efforts. I don’t know of a single discipline where that isn’t the case, whether military squads, sports teams, rock bands… This team, under the guise of “agile” didn’t have the leadership but informed a very patient product owner that they were doing the best they can. Every attempt to refine their approach was met with “but this is how it should be done [according to Scrum]”. And it was – for a seeming non-process that Scrum is, it sure has a lot of rules…

Finally management lost patience and got some good old-fashioned project management into the team to replace their “self-management” and the project was salvaged.

“Agile works/is successful/makes for happy teams vs. other methods” is the implicit, sometimes explicit, message of the agile proponents and I’ve seen its emotional appeal cause idealism to override pragmatism in many projects.

Thanks for the refreshing honesty. I get so sick of cultists saying there is freedom in the rigidity and then desperately look for any mistake in a projects implementation of Agile to blame the team not the process.

Scrum and XP put process over people. There is no one size fits all approach to SE. That is what these brain dead cultists ignore, or maybe they don’t understand it.

You are correct in saying that using these methodologies are a sign the team is third rate. Instead of hiring a parrot, I mean consultant, the company would do better hiring a competent team that works well together.

“Instead of hiring a parrot, I mean consultant, the company would do better hiring a competent team that works well together.”

Guess what’s easier. ;)

I’m not saying that to downplay the role of consultants. I imagine they can do great things but they or anyone can only do so much with a reluctant or dysfunctional team. Definetely not in a one or two day session, what i would expect from a consultant – but i don’t know if that’s normal or not – is to stick with a team and consult for months if not years.

The problem with agile is not “consultants” per se but “consultants” who have no credibility building and delivering great software.

For Games, when John Carmack or Tim Sweeney advocate agile for game studios, I’ll listen.

When its someone who has no product we can judge, advocates a methodology that failed in its very first project, where it originated (spare me the redefinitions of “failure” If the client kicked teh team out that is “failure” enough for me) that is a different kettle of fish entirely.

Next time an “agile consultant”pitches for your money, ask him to show you code he has written that made a substantial change in your domain.

“I wrote/ led the team that created Doom/Unreal/World of Warcraft” is acceptable.

“oh yeah I created this uber cool enterprise system which you can’t look at and I don’t have any open source code, but I know how to write clean code and to “lead” teams, cross my heart” isn’t.

Except Uncle Bob (who has some decent – not briiliiant, decent – code in Fitnesse) no other agile “guru” maintains any largely codebase.

The problem with agile “consulting” is people who don’t know how to code telling people who code how to develop.

Why would any serious game company hire one these pseudo “consultants” who has never written a game in his life?

Agile leverages a design approach. Game creation is closer to art than design, since the “client” is typically the recipient of the product rather than a participant in its creation. However, with all the game patches these days, I’m wondering if the iterative process begins after the release of a game. I think about WoW…how many times did they tweak the character classes to get better game balance? 5? 6? I would say that in that place Blizzard was in more in need of agile. Which of the 78,000 bugs/requests do we work on?

Can agile help gaming? I’m betting it can, and will increasingly, as customers become more part of the process.

Re you’re point on planning. You may not be aware of it, but that particular quote from Eisenhower is widely used by agile developers to make exactly your point: that planning is more valuable than following a plan.

You appear to in violent agreement with agile developers.

This confuses me. No one who has actively participated in an agile project would make a mistake like that. Have you actually ever worked on an agile software development project? Does that affect your ability to accurately judge the effectiveness of agile methods?

Thanks for this post. Whether it be in film, music, any kind of art, software development, graphic design, home construction, or even baking desserts, I’ve always been turned off by energy directed at the “how” vs. the “what”. Buzzwords and cult-think are the luxury of people who work without a connection between effort and reward. Academics like that make me want to become a plumber because then I’m at least solving real problems instead of creating them.

“SCRUM, run by a zen SCRUM master, nearly has no rules and no bullshit. It’s all about being lean and getting results, ensuring that you have a capable team (it only works w/ senior people) and keeping the goal in mind.”

Except that you have to have a stand-up meeting every single day.

And that your people all need to be co-located (nobody can work from home; can’t have reasonably flexible work hours).

And that we need to communicate most stuff with index cards instead of using the wide range of tools that we used before (IM, email, bug tracking, documents, etc).

FINALLY, someone says it like it is! For the past three years or so, almost every company I’ve worked at has tried to force this crap down my throat, and I’ve never been able to swallow the koolaide, without throwing it up. I really used to actually enjoy coding before this “Agile” nonsense came along.

Excellent post. I’d LOVE to email this to the CTO and CEO at the previous company I worked for. They used to be a great place to work, they have a great product, but they completely went to hell and lost their best developers when they joined the Agile/Scrum cult.

Wow, it must be nice to have always been in workplaces where people direct themselves, are all best in class engineers and have no dysfunctional culture whatsoever.

Bottom line is that you have to manage any significant development effort one way or another, and everything pretty much sucks. The best thing you can do is hire a good project manager, regardless of the actual process.

So what are you going to do? I could apply most of the arguments in this article to any methodology – scrum and agile in general suit some business very well.

I think that in the games industry, “big design up front” is a good fit.
“Here’s the game we’re making, go build it”.
For games, it seems to make sense, unless you’re on the Duke Nukem forever team.

Agile works fantastically when the software being developed has no particular end in sight. By this, I mean that many companies develop a product, sell it to a few people, and then charge for a support period – after that you bill for modifications & feature additions. Meanwhile you’re adding to the product, improving, developing, etc. There is no launch date, you sell it as many times as you can and you keep building on it.

Thanks so much for ranting against the insane, fanatical Agile religion, with its priests in robes, oracles, artifacts, mindless rituals, propaganda and indoctrination. You might find my rant equally interesting (see the link accompanying this post). It’s called “Methodology Madness”.

It’s embarrassing that this is cited on the Agile wikipedia page. Being a professional Engineer (and a consultant), having taken and taught a number of Software Engineering courses and having actively studied this material in an academic sense AND having personally spoken with Craig Larman (you didn’t mention him, but he’s an incredibly relevant signatory of the manifesto), Kent Beck and Alisdair Cockburn, 2/3 after a good many drinks, and having done my Masters thesis of a dissection of Martin Fowler’s Patterns of Enterprise Application Architecture, I am comfortable saying: You make every error you criticize the Agile movement of making. Except you’re wrong about them in a good many cases. There are tons of academic papers talking about Agile, Agile papers in game development and their failures and caveats (and there are a lot of bad papers in any subject). One of the most dogmatically repeated phrases is “This is not a silver bullet”. I’m sure others feel the same way, but Kent Beck in particular would say that you can’t piecemeal take pieces of XP and say that you’re doing XP.

Your problem is that you’re part of the “these people are a cult” cult. You probably haven’t spent more time reading up on Agile than you spent writing this post.

How about you take a couple weeks and read up on the Rational Unified Process and consider whether you really understand what waterfall or agile. What do you really know about CMM or CMMI? But who am I kidding, fan boys, of whichever side, have never been known to change the koolaid they were drinking because of logic or sense.

agile evangelists are playing to appeal to the executives (who potentially is the decision maker to purchase consulting), giving them a seemingly legitimate tool to manage software engineers as though they were unskilled assembly line workers.

With Agile the IT moves back to the pre-waterfall period. With Agile we show how bad we are in problem solving, how we prefer to do what we like to do rather and how little we do understand of software engineering. We don’t need lesser analysis, lesser planning, lesser processes, lesser documentation, lesser requirements.. (unles for small and simple projects) SE needs better analysis, better planning, better documentation, .. Corporate IT needs to professionalise itself and take the position of an expert, not that of a servant. Thanks for your post.