We’re Doing Project Management Wrong

Taking a quick break from my Google Cloud/Firebase posts as I haven’t had much time to work on those, I wanted to post a quick article about something that affects all developers at any company: Project Management.

Poor project management can lead to developers being incredibly unhappy with their work environment, I’ve been there, done that, don’t want to do it again nor would I wish it on my worst enemy. I think most developers who have been at a few companies have experienced poor project management as well as good project management. In my career specifically, Agile has been at the heart of good and bad project management and project managers.

do it one more time muthaf****r

In an article about project management I can’t simply not mention Agile. It’s everywhere these days, but unfortunately I have only ever seen it as more of a disease plaguing developers the world over. I have worked in an Agile environment in a small, but well funded, start up as well as large multi-national enterprises and it is largely the same with some specific differences.

The Startup

NOTE: I’m aware not all startups are like this, but for the sake of argument we’re talking about a well funded and well run startup.

I think any developer who has worked at a small, well funded, startup will know that things usually run pretty smoothly. Access to the tools you need doesn’t take any time at all, everyone is young, vibrant, and hard working. Things usually run pretty smoothly from a developer perspective with very little red tape. Developers have a ton of freedom to create, discuss, and invent things that they need. This differs from company to company, but I think many people will agree.

The Enterprise

NOTE: I’m also aware this is not the situation for all enterprises, but again, for the sake of argument, we’ll go with a pretty typical situation.

Sometimes we take things for granted and when they’re gone we miss them. Coming into an enterprise the first thing you’ll notice is the shocking amount of red tape you have to break through to get ANYTHING done. For example, my first week working for a large enterprise as a senior engineer it took a week to get me access to source control and other developer tools that I need for development. There is also a ton of bureaucratic nonsense going on with the business people, the sales people, the project management, which adds to the red tape when it comes to development. If you want to change anything, no matter how tiny, 10 people will tell you “that’s just not how we do things around here”. Getting anything meaningful done takes FOREVER because of all this red tape and it can get frustrating.

What Now?

You may be saying to yourself “duh! Of course enterprises and start ups are different!”. That leads me into the crux of my argument. Both of these environments use the same Agile project management methodologies. So why would the same methodology work for such different environments? The quick answer is that it absolutely does not work, but merely gives the illusion that it does. It’s understandable that larger companies would have more overhead that process than smaller companies or start ups, but as I’ll demonstrate, Agile brings a lot of overhead to the small company/startup.

So now you may be asking yourself “What’s your problem with agile?”. Before you grab your pitchforks and flaming torches, let me explain.

I do not take issue with the core principles of Agile, I think they’re pretty good. I start to have an issue when Agile is implemented. Let’s breakdown the agile manifesto:

Agile Manifesto

These things sounds great, but doesn’t follow through in practice. The reason behind that is that Agile is actually nothing but process and, in my opinion, over-process. To illustrate my point let’s take a look at an average week in the Agile environment.

Every morning everyone stands around a scrum board and robotically re-iterates what they did yesterday and what they are doing today, or otherwise known as stand up. Then throughout the week there are grooming meetings, tasking out meetings, sprint kick off meetings, retrospective meetings, scrum meetings, and more meetings. In my opinion, I think a developer’s time is better spent writing code, but hey that’s just me.

Even with all these meetings it would be fine if people weren’t so adamant that every single meeting is the most important thing in the world. As if somehow missing a day of stand up was going to bring the project crashing to the ground (spoilers: it won’t).

It hurts

Let’s talk about scrum and scrum masters. On the website scrum.org it says the following:

The Scrum Master is responsible for promoting and supporting Scrum. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.

Sorry for being brash, but this is inherently stupid. According to this website the scrum master’s primary job is to be an aggressive scrum salesperson. Really? If you read on it will outline more reasonable responsibilities for the scrum master like

Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible.

Finding techniques for effective Product Backlog management.

Helping the Scrum Team understand the need for clear and concise Product Backlog items.

Understanding product planning in an empirical environment.

Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value.

Understanding and practicing agility.

Facilitating Scrum events as requested or needed.

If this is starting to sound kind of wrong to you, there is a good reason for it. As we read more about scrum it’s starting to look like the scrum master is really just a middle-person between developers and being able to do work. Individuals and interactions over processes and tools my ass.

This brings me to the main Agile thing: Sprints

What is a sprint, really? It’s a small section of time (usually two weeks, but this sometimes changes) in which a bunch of “stories” (tasks, really) are to be completed. The way it goes is that sprints are used to accomplish milestones, and milestones are used to accomplish the end goal of the project. Altogether this isn’t that bad, really. What makes it bad are the project managers pushing the MVP (Minimum Viable Product), or basically the make it work version of the product. (Working software over comprehensive documentation, working software, I don’t think so.) You have the scrum master and the project manager assigning stories to these sprints during sprint planning meetings which occur every week, sometimes multiple times a week.

In my experience sprints are incredibly rigid boxes of time where if some unknown comes up or someone has a better idea or different way of doing something, the project managers create a new story and put it at the next sprint or just in the backlog, basically a place where innovation and ideas go to die, it’s also the place where all your tech debt demons go to terrorize you later. So responding to change instead of following a plan, I think not.

We’re at the end, and all I have done so far is take a big crap on Agile, so you may be thinking, quite rightfully so, “if Agile is so horrible, what’s your solution smarty pants?” My answer is simple in theory but super difficult in practice. The answer is that there is no answer. There is no over-arching solution that works for all cases. You have to take your project management with a grain of salt and change it to fit your company, rather than changing your company to fit your project management solution. I’ve seen so many people bend over backwards to implement Agile when they should be forcing Agile to bend over backwards for them.

There are so many tools that Agile uses (Jira is the big one, monday.com, trello, etc.) These tools are actually pretty nice to use, but many of them couple you too tightly to Agile (Jira I’m looking at you). I have a word of advice for you, you don’t have to be in an Agile environment to use these tools. You can easily use these tools to implement you’re own methodology.

My last few sentences to you are these. if you’re thinking of starting a company or if you’re working at an existing company big or small please think about the things I’ve discussed here today. When deciding how to manage your projects and teams make the tools you use work for you not the other way around. Make sure you question your existing processes if you don’t think they’re not working, or if you think they could be better. Good day, and good luck to you all.

If you’ve enjoyed this article I’d love for you to join my mailing list where I send out additional tips & tricks!

If you found this article helpful, interesting, or entertaining buy me a coffee to help me continue to put out content!