You probably know the saying, “About 70% of the software development projects fail, and about 55% go over budget.” The numbers may change every year, but I’ve been hearing this since my first day as a developer. After 20 years in the industry, I think I can safely state my opinion here: Projects don’t fail or go over budget because building software is difficult; they do because people are.
These statistics are mainly gathered by companies like Gartner and regurgitated countless times by numerous consultants and project managers because they want to sell you something: Their services. They cover the software development with a shroud of mystery and tell you scary stories around the campfire, which looks too much like a meeting room: Half the people who go into software development projects don’t return. The others that came back are never the same.
(I have to say, I’m very proud of this campfire analogy that I came up with.)
But hear me out: Ultimately, the root of your problems isn’t how you execute the project. It’s just how well you’re communicating with. If your team members are incapable of asking for help when they’re about to be mauled by bears, it doesn’t matter if you do Agile or have a PMP-certified PM from Deloitte or McKinsey. You will fail.
And sadly, most of the software developers are terrible at communication. Not because they are bright engineers who think it’s a waste of time. There are plenty of engineers in other industries that build things just fine. I mean, NASA landed on the moon with computers less powerful than my Apple Watch, for fuck’s sake.
Let’s roast each role in a software development project. Why? Because I want to.
Hi, I’m Harun, and Welcome to Jackass
The whole thing happens because software engineers think software development is all about writing code. They think it’s an art, and you just aren’t at their level. Their magnificent minds are on a level that your mere mortal minds can’t comprehend. They are the Illuminated, and all that matters is their work.
And if you’re a PM, BA, or Agile Coach who’s laughing at me roasting the devs above, yeah, bad news. You’re next.
Business Analysts mostly think the developers are idiots and just don’t understand what needs to be done. In their minds, because they talk to the users, they know best. Their brilliant minds see the intricacies of the cogs that make the business work. Hell, most of the time, they know it better than the business units themselves! They explain it all to you in an endless stream of documents. Still, instead of reading and appreciating their masterpieces, you ask dumb questions!
Project Managers are the most blameless and underappreciated of them all—at least, they think of themselves that way. In their minds, the team always fails to deliver despite the PMs’ unrelenting effort to turn them towards the Path of Light, which is another name for the long-ass Gantt chart they prepared in Excel or Microsoft Project. If everyone else would do the tasks by the deadline for each of them!
Testers are the most gullible of them all. They have no idea what the actual fuck is going on and how everything works. In their mind, they are tasked with one thing: Pretend they understand the box of black magic the developers left for them and pray that nothing blows up when they give it to the customers. If it does, it’s the developers’ fault. If it doesn’t, it’s the developers’ fault.
And finally, for our grand finale, the Agile Coaches. They can recite every one of the principles of the Agile religion and all the lines of the manifesto that their 12 monks left for them by memory; they would also preach to you about your sins and try to guide them towards the light. You have to pray in small but not too detailed prayers, do it every two weeks, plan your prayers with your church on the first day of your two-weekly period, estimate how much time each of them will take, and make sure you pray them all before you go back to church and kneel before the gods. Then do it again. Then again. Then again. The gods might change their expectations and ask for your firstborn, and you should do it because it’s written in their manifesto!
Good Grief
Why did we do that? Because it was fun. And also to make a point: The problem is not the software you’re building; it’s your people.
Put 10 people in the same room, and in half an hour, they would find 10 things they would despise about each other. But you’re paying them to get along, so they won’t say anything. They would nod and play nice. But it wouldn’t work well. They still despise each other. They would form groups, probably based on their roles, and they gossip about the other groups. Developers would talk shit about PMs, BAs about devs, PMs about QAs, and QAs about everyone else.
Ultimately, it doesn’t matter if you choose the best methodology on the market for your team. Because the team members won’t communicate well with each other, it won’t work well.
I’m not saying it won’t work at all. It will. I mean, people used to deliver big projects using waterfalls. It just won’t work well.
You don’t need the perfect project management system. You need people to talk to each other.