The Crusade Against Project Purists
aka I should just stop commenting on LinkedIn
The first mistake of the day that I made was forgetting to take my chewing gum out of my mouth upon entering a crowded, well used men’s room. If you haven’t been in this situation before you may not realize why such a thing is a problem. Let’s just say a process occurs that is similar to osmosis. Only instead of water and trees, we’re dealing with chewing gum and the fury being unleashed by strangers / co-workers. It is a horrible situation to be in, and more often than not, when you realize you’re in it, it is far too late.
As terrible as that experience was for me, it paled in comparison to the second mistake of the day… posting a response to a question on LinkedIn.
In most cases, I never do such a thing. My teenage adventures on internet forums taught me that arguing over the internet brings out more unbridled ignorance, spitefulness, and stupidity than anything else I’ve experienced to date (ex. every site that has a comments section). But in this case it was a topic that I am actually quite fond of, in a group in which I am a member; agile project management.
The question was something in the same vein as “Agile vs. Waterfall: Which is the BEST approach to managing a project”. Now, I am fully aware that skipping links to topics like “Scientists Discover Cure for Dog Cancer”, “Pens: The True Story”, or “All You Have to Do Is Read This Article to Become a Better Person” and settling on a project management related question is sad.
In fact, it is depressing that this subject is what I’m finding myself becoming passionate about as time goes on. That realization alone should put my life on a level only sung about in songs by Jewel. But alas, the truth is, I love this stuff.
The only logical explanation as to why this interests me, is that after drinking the “Agile kool-aid” I have subliminally turned into something like a religious zealot, with a sole purpose to crusade through the internet slaying the “non-believer” savages known as PMPs. But we aren’t here to talk about that, so let’s get back on topic shall we?
The question of a BEST (all caps to indicate seriousness) way to manage a project elicited a tremendous response from the group members. People from various industries, careers, and titles chimed in to state their thoughts, argue with each other, and of course as is mandatory, take the conversation off topic. So much so that I think the discussion veered into a lecture about how God was involved with the planning of Greek aqueducts or something. (Is it scarier that these people have jobs? Or is it scarier that someone actually pays them to not be crazy for 8 hours out of the day only to let them loose into the world?)
Rather than throw my hat into the ring and start talking about how amazing I am at what I do, what car I drive, how hot my fiancé is, or how God was somehow involved in this topic (seriously, I’m bringing this back up, I’m genuinely concerned for my safety that these people are out there), as the others were doing, I decided to address the OP’s question directly. I won’t paste it word for word, but here is the gist of it;
When talking about software development projects, there is no such thing as a “better than” solution. For example, a waterfall approach to running a project isn’t better than agile, and vice versa. This is coming from someone whose career is based around believing in agile, who has a strong bias to hate waterfall, and to praise agile practices. But this is just the reality.
There are people, far more boring than I am, who go out and study failure rates of projects, which at one point in time sat around 75%. Know what has happened to this rate as various agile frameworks have reached maturity and widespread popularity?
Nothing! Hooray!
This, in my opinion, is solely due to a lack of understanding of the agile mindset, what being “agile” means, and how the various frameworks are to be leveraged to get the results you want. All of these things are grossly misinterpreted in some form or fashion the majority of the time. Why? Well, for various reasons, but the biggest of which is project manager ego (which we’ll save for another article or 10). Therefore the best thing to do is to look at both approaches and discover, by doing, what processes and tools from different methodologies or frameworks work best for your team, in your company’s environment, for a particular project.
When I posted this comment I got a stream of people commenting and messaging me about how right or wrong I was, but one in particular caught my attention. It was a statement from a guy whose title was “Visionary and Agile Evangelist”.
Now let me stop here and make an editorial comment. Giving yourself a title like this is close, but doesn’t quite surpass, the type of people who name their houses and post a little sign out front in terms of overall douche-bagginess. I’m sure people who do this are SMEs in their space, but you have gotta be kidding me with the self-aggrandizing bullshit. But I digress…
The grand visionary of project management blessed me with a comment that, in summary, told me this;
If you don’t go one way or the other [agile or waterfall], your projects will end in chaos and confusion. Process tailoring is a fallacy, and you can go screw yourself for thinking it is possible. Plus we all KNOW (again capitals for importance) that Agile is the way to go, it has been proven time and time again.
My mistake manifested itself in a statement that defines what is wrong with the world of agile software development practices from my perspective. This concept of “my way or the highway” or “there is only one right way to do something” has somehow been ingrained in the management styles of PMs, and corporate leadership everywhere.
If people you know consider themselves to be “agile purists”, i.e. this way or the highway, they do not understand agile, plain and simple. In fact, being 100% in favor of agile practices is completely contradictory to the very principles of what it means to leverage the agile methodology in your workplace and on your projects.
It is a trap to fall into thinking you must be 100% agile or 100% waterfall, and there is no organization on Earth today that is capable of accommodating either and still being able to compete in the marketplace. Being agile means being innovative, adapting to change, empirical processes, and iterative improvement through progressive elaboration, and so staying we aren’t ever going to adopt tools, processes, or various development methods simply because of their category stands against those principles.
Tailoring processes to how your team works best, in your company’s culture, and for a particular project is the key to success. There is no one size fits all framework. There is no magic bullet. And so there is absolutely no reason to assume that going “agile” just for shits and giggles is going to solve your problems. It takes special care, training, and a ton of trial and error to find the right fit, and until that time comes you are going to have bumps in the road.
If you take anything away from this I’d say it would be to understand there is no best way to run and work on projects; just the way that works best for your team. I’d also tell you to remember that people, who read an article, take a day’s long class, are not agile professionals. It is your job, to tell them they are full of it if they say it will solve all your problems for you. And the last note, is that if you run into that cynical developer or developers who have had a bad experience with agile (or waterfall) at a previous job must understand that the chances of that same situation happening at a new company, or on a new team, are highly unlikely to be repeated due to the amorphous nature of the frameworks themselves.
Cheers,
-J
lRэ{�