≡ Menu
Pawel Brodzinski on Software Project Management

Agile Bullshit: Agile Presentations Are So Naive


I saw recently one of Mike Cohn’s presentations on Scrum. Actually Szymon organized a series of meetings in our company where we watch some of agile though-leaders and have discussions. Mike’s presentation was a good one and a good discussion followed, but one thing struck me at the meeting.

Most of presentations about agile approaches are completely naive.

I sure am biased with my skeptical approach but definitely I’m not an agile-hater. Quite the opposite. I use Kanban (yes, some of you will tell that’s lean, not agile). I will be speaking at Agile Central Europe next month. You can’t say I’m against agile.

Yet still, I often feel offended how agile is sold to me on different occasions. “Agile raises your productivity.” “Agile makes your product better.” “Agile is going to make your product suit better customer’s needs.” “Agile is just better.” Oh, really? And agile makes the best coffee around, doesn’t it? Throwing arguments like that with no knowledge about background is brain-dead. With agile you can achieve all these and even more. But at the same time agile doesn’t guarantee you anything.

What more, with any other consistent and reasonable methodology you can achieve such good results. Yes, with waterfall too. Unless you know more about specifics of organization you can’t really tell whether this or that approach would be better.

And then I hear someone telling that 20 years ago someone else said some methodology (likely waterfall-like) was ineffective and the conclusion is: if it was ineffective 20 years ago it is even more ineffective now, that’s why we should switch to (new, cool) agile. I may even respect both guys (at least to the point where I’m not going to give their names) but that doesn’t make their statements any less stupid. Or less naive. Or less insulting. Or all three at the same time.

So please, please, please, don’t tell how silver the agile bullet is. When stating how it improves work add few sentences why it helped. How exceptional was client’s engagement. What top management did to enable and increase agile adoption rate. How hard these few people worked to convince developers that agile is fine. What were specifics of projects run agile way. What did you do with tasks which don’t suit well to most agile approaches (like maintenance).

Don’t mix your well-grounded arguments with purely marketing messages generalizing everything to the point where it has no value whatsoever and is completely meaningless.

You’ll sound less naive. Well, maybe people would see these as obstacles and treat them as excuse not to try agile. If they do so they wouldn’t have succeeded with agile anyway. For the rest your voice will be more reasonable and more convincing.

All posts of The Carnival of Agile Bullshit.

in: project management

8 comments… add one

  • Marek Kirejczyk March 22, 2010, 3:50 pm

    Oh, come on Pawel, give up on agile criticism! Face it: Agile is a buzzword and there will always be people selling it this or another way. The truth is well implemented agile (not hey-I’m-doing-stand-up-meetings-and-I’m-so-agile agile) will increase your productivity. Because, agile (XP, scrum, kanban, lean, or whatever) is in fact nothing more then just set of practices put together, pratices that work, that were tested by many people.

    I still belive that 3 most important pratices are CR, TDD, CI not sprinting or limitingWIP. You can use them in agile, you can use them with waterfall.

    Still those and some others will be by the most people perceived as agile practices. And therfore agile will increase your productivity. If you think about common meaning of “agile”. You just have to use it wise, choice right practices etc.

    Btw, since kanban is not a process (@agilemanager), but what you do to a process, why can’y you do a waterfall-kaban?

  • Szymon Pobiega March 22, 2010, 11:54 pm

    @Marek Kirejczyk
    I personally can’t imagine TDD without acknowledging that design is part of implementation which excludes any waterfall methodologies from discussion. TDD is an agile-only practice. If you think you do TDD in a waterfall project, you actually do agile-under-the-hood:), probably to save the project from failure.

    I am personally a big fan of Domain-Driven Design which is not a PM methodology, but prescribes some some of common agile practices, although not all of them. For example, it encourages PM to carefully assign work items to team members with concern to their skill level and even job type (permanent, contract) which is contrary to self-organization.

    Yeah, agile is not a silver bullet and by itself won’t help in anything. It can, however (and doesn’t matter if it is scrum or kanban or whatever), expose and amplify the problems you currently have so that they can be seen and solved. Examples? Installing new version on the internal test environment takes 3 man-days. Release often and you’ll feel the pain very quickly.

  • Pawel Brodzinski March 23, 2010, 2:04 am


    First, my criticism isn’t addressed at agile, but at people selling agile, coaching agile and evangelizing agile. Note, I include people who invited/brought agile in the first place. No sacred cows here.

    And I just don’t believe in definite statements like “The truth is well implemented agile will increase your productivity.” I don’t buy it.

    I happened to work with clients who were waterfall to the last bit and enforced much of their approach on their vendors. I know, no one forced us to work for them but I know very few companies which can freely choose their clients and we definitely weren’t in this position.

    When we come to specific practices it becomes a matter of personal preferences. As you may know we don’t use TDD or code review and definitely neither is the most important software development practice for me. In this specific team we found specific set of practices which yield good results. Your specific set of practices implemented by your specific team is (of course) different which is no surprise for me.

    Since every situation is different there isn’t one universal answer to every problem.

  • Pawel Brodzinski March 23, 2010, 2:30 am


    I don’t agree with your approach to TDD. I’ve never worked on a project where design was completely separated from implementation and I’ve worked on many waterfall-like projects. TDD alone doesn’t make you agile the same as stand-ups don’t.

    TDD is just a practice. And agile is just a label. I see no point in trying to add them more meaning then they have.

    There is much value in different practices out there but they weren’t invited along with agile. Different “new” methods just mix a few well-suiting practices into one box which helps in their adoption.

  • Przemek Wiśniewski May 5, 2010, 5:19 am

    TTD — Test Driven Development. Why not Business Requirements And Rules Driven Development?

  • Pawel Brodzinski May 5, 2010, 5:54 am


    Why do you think you can’t have both? TDD is engineering practice. It tells nothing about your approach to business requirements. You can perfectly focus on requirements business-wise and on specific approach to unit testing engineering-wise at the same time.

    Actually TDD was just an example to present how different agile practices are treated and what’s people attitude on them.

  • Amarendra Godbole March 28, 2011, 4:02 am

    Very interesting article, well written. I agree with you – agile is becoming more of a marketing term, than a set of engineering principles. Unfortunately, this makes it even more difficult for organizations to adopt it – there are too many “agile-practicing-quacks”, which results in failure.

    Smart engineers and teams have been using agile since the day the first line of code has been written, or even before the term “agile” was coined. The way agile is marketed today, is, unfortunately, an insult to those who know and understand agile well.

  • Craig August 10, 2013, 11:43 am

    Yet more meaningless crap used by consultants to sound like they have a clue. Methodologies are *NOT* difficult and are not something people should spend endless hours pontificating about.

    Any given team can come up with a suitable methodology, best suited to their own condition. If they can’t, they almost certainly can’t do the prescriptive consultant-money-making-scam oriented development either.

    Being “agile” can be boiled down to keeping clueless, non-technical managers the fuck out of the process.

Leave a Comment