Thanks for sparking the debate. Allow me a request, a comment and a question in response...
Request: I ask you to distinguish Agile from Scrum. Agile is a set of principles. Scrum is a methodology, or process, based on those principles.
Comment: For my teams, Scrum has worked more effectively than other processes.* The point of my post was not that "Agile works, if only people would do it right". That is a misinterpretation. The point was that over-complication (by way of, for example, a 478 page book) makes having it be an effective process for a team more difficult. Perhaps the reason it's worked for my teams is because I have focused on keeping it simple.
Question: Obviously, you think Agile and Scrum are nonsense. I'm not going to try to convince you otherwise because I can think of lots of scenarios where Agile or Scrum would be counterproductive. But, I would like to learn from you: what approaches/processes/methods of developing software have been most successful for you.
Let me clarify...I'm not asking "what is better than Scrum?"...I'm asking, "what works best <i>for your teams</i>?" (And, since some processes are better for some jobs that others, what type of work is your team doing?)
"The very first thought that comes to mind about a building a development department structure is this: an organizational structure is a just tool for getting a job done, so use the right tool for the job...
...My experience has almost entirely been in building early stage web sites which is a very specific type of job. I am strongly biased toward Agile/Scrum teams for this type of job. If you are building software for banks or airplanes you might need a different tool...er, structure."
My original comment wasn't an attack on your article specifically, but I appreciate it looks like that. However, my comment "it's the same nonsense in fewer words" is targeted squarely at the "if Agile doesn't work, you're not doing it right" mentality. And your article has one foot firmly in that camp.
On one hand, I can appreciate why people take that position because on paper, Agile looks brilliant. But as I mentioned in a previous comment, it doesn't matter that Agile was meant to be some other thing, because Agile has become what it is today, and it's this reality version of Agile that I have a serious problem with.
You can say Agile and Scrum are two different things but it doesn't matter. If you came to where I'm working right now and said that, you would be laughed out of the room. It doesn't matter if you're right. The reality of Agile is that Agile and Scrum are now the exact same thing in the eyes of the many. And the more you look, the more you'll see that, to these people, Agile means strict, regimented adherence to inflexible procedures whose supposed merits are totally baseless. And when you call people out on this shit, they'll just scream "Waterfall! Waterfall! WATERFALL!!" in your face until you shut up. (as an aside, that's pretty much what happened to me when I tried to point out that our approach to this project wasn't working, except they didn't scream it at me.)
You ask what approaches/methods/processes work best for me. I don't know how to answer that. I'm not comfortable with the idea that just because something worked well on one project, it will work well on an another.
Take for example one of the projects I'm most proud of. From the email you sent me earlier I know you've looked at my website so I'll point you towards the Info graphics work I did for that very famous newspaper. The first project we did for them was the "Health of England". The organisation approached The Agency at the 11th hour with a vauge notion about creating something interactive to support some of the articles for their soon to be released iPad app. That project was hellish. The iPad had yet to be released, all we knew was that we could put stuff in a UIWebView. I worked with the designer to cobble together a few prototypes of things that might work and we slowly and clumsily worked our way towards a finished product. There was a ton of waste and dead ends and revisiting things we'd already done. There were no meetings, just shouting at other people over the desks or standing behind someone and arguing the toss over tiny, seemingly inconsequential things. We worked late. The stress levels were through the roof and by the end we were exhausted. But we were all immensely proud of what we'd achieved, and that work went onto win two awards and generated a lot of interest form big clients in a little agency that had been flying under the radar for a long time.
So... should I use that as a template for future projects? Should I say that every project from now on should be completely unstructured? That the best results can only be obtained by working late and burning out the team? That we're not doing our best work if the designer and developer aren't ready to rip each others throats out?
That would be insane. And this is where the Agile people jump in and say "Ahah! But that was Agile, don't you see!!"
No. It wasn't. It's called "building the thing as best you can in the time you have available".
But the Agile people will say "But... but... that's Agile".
No, it isn't. Agile is* scrum to all intents and purposes. Agile is stories and story points on the mind numbingly whimsical fibonacci scale. Agile is not doing what you should be doing because some other idiot forgot about that bit and is covering their tracks by saying it's out of scope. Agile is sprints that dictate the thing be built ass backwards because the person planning the sprints sit's in an ivory tower pretending they know what they're doing. Agile is time boxing something that really has to be in there, but won't be because there's not enough time in the sprint. Agile is reaching the finish line with a third rate version of what you set out to build, and using it as validation that Agile works. Agile is about sacrificing the one thing you should never sacrifice if you want to hold your head up high as a designer or a developer: Quality.
I'm sure that will irk a lot of people, that I'm brazen enough to claim that Agile = Poor Quality. But I have the anecdotes to back me up. And in the Agile world, anecdotes are evidence. My anecdotes are as valid as yours. Live by the sword, die by the sword.
And maybe all the Agile supporters are right. Maybe Agile can be done right and it's brilliant when it is. But in my actual real life experience, all I've seen Agile do is validate low quality people's low quality ideas and bad practices. Agile is held up a shield, protecting the holder from professional criticism. Maybe the Agile community truly wanted to give the world a gift, but all it;'s given us is a disease.
