≡ Menu
Pawel Brodzinski on Software Project Management

Agile Bullshit: Agile Is Good, Waterfall Is Wrong

Agile

If I asked you what does agile mean to you I’d get a range of answers from hard-core XP to approaches loosely based on Scrum.

If I asked you what does waterfall mean to you I’d get a range of answers from well-oiled staged processes to environments where formalism kills any productivity.

If I asked all of you who hasn’t heard that agile is better than waterfall because the latter simply delivers worse results in longer time I would hear the perfect silence.

Infamous waterfall is ideal background to sale agile. It’s enough to take one of these over-formalized or chaotic environments call them typical waterfall and show ideal agile case as an alternative. Barely anyone would object.

Does it mean agile is better than waterfall?

Well, depends on which agile and which waterfall you think about. These are such broad terms you can’t really compare them. What you can do is compare two very specific approach with all strings attached. Unfortunately this makes rather poor argument for big cool keynotes or sale pitches.

We should care less about specific methods and more about people in our teams. A team of great engineers following well-known (for them and for their client) waterfall-like process will produce better results than average team using the best agile approach you can think of working for client who doesn’t get and doesn’t want this whole agile thing.

When you consider which methodology you want to follow think which one would be the best for your team and for your client. Don’t believe these fancy presentations telling you how Scrum is great or how Kanban is great. Ask presenters why this or that worked in their case. Ask when they failed and why. Most of the time they won’t tell that unless you ask.

Different approaches work or fail because of people (both your and client’s team), not because of they are universally good or bad. Remember this next time you hear agile versus waterfall discussion.

All posts of The Carnival of Agile Bullshit.

in: project management

11 comments… add one

  • Laurent Parenteau March 19, 2010, 11:01 am

    I couldn’t have said it better. I’ll keep this post bookmarked and point it to people obsessed of any particular “pre-maid” software development process.

  • Allison March 19, 2010, 12:22 pm

    This, to me, goes back to the key promise of Agile – getting developers to communicate (at least when done decently). If Agile helps a team do that, awesome. If it doesn’t, get rid of it. It isn’t the only way, and, i’d argue, bad agile practices can make life even worse! At the end of the day, the teams that communicate best that will do a lot better; and have more fun getting there.

    This all goes back to many of the posts you’ve added lately; and many of my own blog posts (the don’t be a dick, got your back, and a few other posts) all come down to. When people listen, when people know that the person next to them is someone who “shares the same life raft”, you’ll see a lot of magic happen.

    The converse is true too. If you are afraid to do anything at work, or you feel that your company doesn’t care about you, or your team is at odds or the company plans for 60 hour weeks, what you’ll see, no matter what the methodology, is suffering. Silver bullets never work, they just lead to new ways of bleeding.

  • Dave Moran March 20, 2010, 5:06 am

    Pawel,

    Great post! I agree, there is no substitute for great people with a blend of technical and interpersonal skills that can collaborate to produce results. Read any advice about creating successful project teams (regardless of the methodology) and there will always be a line that says something like, “Staff your project with motivated, capable people.”

    We are a Scrum shop at my company, and I am a strong advocate of Scrum. Properly implemented, it is a great framework that allows teams consisting of experts from multiple disciplines to collaborate – with full control of their work. The Scrum framework helps teams get out of the gate faster because teams won’t have to spend time figuring out all of the ground rules on how they will prioritize and coordinate their work. Scrum establishes the core protocols up front and leaves the selection of practices up to the practitioners.

  • Pawel Brodzinski March 21, 2010, 8:15 am

    Allison,

    I’d add communication with clients/users to communication within the team. As you write – if the method enables communication use it, otherwise look for the one which does.

    If a client doesn’t get agile approach, doesn’t want to get engaged and expects you to follow their old-school heavy-weight process it may appear Scrum isn’t the best choice in the situation.

  • Pawel Brodzinski March 21, 2010, 8:24 am

    Dave,

    I used to say that Scrum is pretty formalized approach and I still believe in that. If you want to use Scrum by the book you have several practices you should follow.

    Of course no one forces you to use any method with no exceptions or changes, i.e. Prince-2 tells you to choose practices which suit your project. The difference is in so-called heavy-weight approaches many things are described and you choose among them and in agile few things are described (and prescribed) and you’re free to add more.

    Scrum is a good method – it wouldn’t be so popular otherwise. But as any other approach it isn’t the best one in every case.

  • David Bland March 22, 2010, 12:15 pm

    Waterfall works well with known problem/known solution.

    Agile works well with known problem/unknown solution.

    I don’t necessarily despise waterfall, it’s just that over the last 10 years I’ve yet to experience a need for waterfall in the rapidly evolving web development space.

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

    David,

    I agree that for most web development projects agile suit much better than waterfall. Exactly as you write if solution is unknown you should expect to adjust the scope along the way and then agile shows its potential.

  • Expert Program Management April 16, 2010, 1:48 am

    Great article! Good to see a balanced view presented for a change!

    Total agree that projects pass or fail because of people – in fact, a great team with no process is probably better than a bad team with a great process

    Denis

  • Enzo May 31, 2011, 2:57 pm

    Most of the software development methodologies presume that process & methodology are the key and they are all wrong. The people are the key. A bunch of dumb asses can use any methodology they want and they will still not deliver a quality product. It all depends on who’s working on the project and what the goals are. Do you need a prototype to get in front of investors or potential clients? Do you need to ship the best quality possible or just something good enough? A bunch of bad cooks aren’t going to make 5 star chef quality food even if they follow the same recipe. It will never happen. I’ll take a rock star developer and the waterfall method over your team of bad developers and their agile method any day and I will win every time.

  • Brad November 22, 2011, 9:08 am

    All these methodologies are crap. Just hire the right people in the first place, and stop filling my workplace with bullshit buzzwords.

  • Will September 20, 2012, 2:33 am

    Brad your comment is the best comment I’ve read for a long time, come and work for me.
    I’m also sick of all these bullshit buzzwords and management crap.
    I’ve been a dev for 20 odd years. Here’s how you run a project. Hire good people, write a list of stuff to do and the order your going to do it. Everything else is just management bollocks.

Leave a Comment