Solving our project management woes

Solving our project management woes

I wrote an article recently about project management, tldr: Agile in practice breaks all the promises of Agile in theory (the Agile manifesto) and in many cases slows down development by implementing too much .

I didn’t end the article with any real solid solutions, just something vague that could be interpreted as something I didn’t mean it to be. In this article I want to detail some things I have thought about to help us manage our projects.

First thing I want to do is talk about some highly generalized things that almost all projects have in common, even non-technical projects.

1. There is a goal to be accomplished
2. The end goal of the project (should be) clearly defined
3. A series of tasks will define a map to guide the team to the completion of the project
4. Multiple team members will work asynchronously on these tasks
5. While working asynchronously, team member may have overlapping pieces of work and must coordinate with each other

There are a lot of other factors that go into generalizing a project, but I think these ones will be the focus of figuring out how best to go about managing the construction of a project.

Now that we have a definition for some things most projects require, let’s talk about how Agile solves them and why these methods don’t work in practice, or could be improved.

Let’s talk about the first 3 points. Agile in practice proposes Milestones and Sprints for defining a project’s goal and map out the road to complete that goal. These things on their own are actually a fine way to define a project as well as clearly defining the path to accomplish the goal.

However, when you practice Agile there are processes surrounding sprints that will slow us down along the way in an unnecessary way. The main factor to that is the amount of meetings being held. There are grooming meetings, sprint planning meetings, retrospective meetings, scrum meetings, sprint review meetings, and there are probably a few others that I can’t think of so I’ll just say etc. These meetings will be help every week or so, resulting in hours per week wasted in meetings when that time should be spent writing code or being more productive. I’ll get to some solutions later but I have 2 more points to talk about.

Points 4 and 5 are around completing tasks and syncing with your team. Agile does this by having a stand up meeting EVERY morning. If that sounds tedious, then you’re right, it is. While it is important that a team is on the same page, a meeting EVERY SINGLE morning to say what you did the day previously and what you’re up to on that day is a waste of everyone’s time. This is especially true if you are working on things that simply don’t concern the work of your other team members or it won’t overlap with someone else doing something.

Ok, now that we know what Agile proposes to solve the 5 issues I pointed out, and why they’re bad let’s try to improve them.

Let’s start with those first 3 points again, and we’ll use an example this time to help illustrate the point. Let’s say we have an idea for an app. That idea serves as the end goal of your project and what the application is suppose to do and what it’s supposed to be. Once you have the idea you’re probably like “Well now what?”. Now the 1st point comes into play. We need to record it. Write it down, put it on your computer, Google Drive, whatever, but you need to record it in a place where you can add to it. This is where step 2 comes into play, we need to clearly define it. Generally when we have an idea it is a little vague and not really well thought out. Once that rough idea is recorded it’s time to refine it. Take an hour or so, get your team mates together and write down as many features as possible.

Before we get into point 3 I want to emphasize something. This is a process that you will do once at the start of your project and probably not do again, and it should only take an hour or so after your initial idea. Ok so step 3, a series of tasks mapping the project. I don’t believe that it is important to write out EVERY SINGLE task that needs to be done from the beginning to the end (or at least to the MVP) at the very start. This would take WAY too long and the ones nearer to the end you’d end up changes them as you go along anyway.

At this point you have an idea with some features and some team mates ready to get to work. Before we continue I do want to talk quickly about tools. There are plenty of project management tools available: Jira, Asana, Trello just to name a few. I’ll tell you it doesn’t really matter which one you use, but in my opinion I don’t think your project management tool should be very opinionated, so I would take Jira out of the running. You basically need a tool that allows you to create tasks and assign them so that there is visibility of who is doing what. You really don’t need much more than that.

Ok, so getting back on track, we need to talk about getting our tasks into our chosen tool. I really like Trello, as it’s simple and gives us the ability to make it unique to us (Asana is great too, but I’ll refer to our tool as Trello from here on out). This is a key area of project management, that I think needs to be in the hands of developers, not project managers.

If you’re a non-technical person reading this, my idea may sound a little scary and I want to talk to you directly for a second. It’s your idea and you want it executed your way, I get it. But you’re not a developer, you don’t know best practices and you won’t design tasks that are beneficial for your development teams. The reality is, you are nothing without your developers and you won’t have an app without them. If you don’t trust them, then you need new people. My suggestion would be to hire a developer you trust to tell you if there are developers that are doing a bad job, but don’t try to tell your devs how to do their jobs.

WHERE’S THE COMMUNICATION YOU DONKEY

Developers should decide what tasks to complete and in what order. This should not be determined in specific meetings or have any time taken away from writing code. Instead this should operate like a chef’s brigade. If you’ve ever watched Hell’s Kitchen you’ll know what I’m talking about. Order tickets come the chef yells out the order and the cooks cook. From that point the meat station has to communicate to the garnish station, the people on appetizers have to communicate with each other than everything is done asynchronously and everyone knows what everyone else is doing. This is how development should work. We have incredible communication platforms like Slack and we don’t use as effectively as we should. Much like a meal being prepared in a chef’s kitchen developers should get the order that we need one application and then they talk and communicate and work together to make it so. No project managers, no scrum meetings, no stand up, just constant communication and developers being in control of creating and assigning tasks.

This communication can come in multiple ways. Via Slack, PRs, Issues, via Trello, phone calls, video chats, or just shouting across the room (if you’re all in the same room). This doesn’t have to be super official, it doesn’t have to take a long time, it can be assigning a task to someone, it could be a message in a Slack channel asking a question, just small quick communication. This really encourages rapid development and scraps all the BS meetings project managers think you need. That solves the 5th and final point.

So what’s the message here? The message is quite simple, developers need to own the development of a software project. They need to be responsible for creating tasks asynchronously and working and coordinating together with minimal direction. Give your developers an end goal, give them the features it needs, and get out of the way.

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!