Using Common Sense Project Management
I’ve spoken at length about the pitfalls that many teams fall into with Agile. You can read my articles here and here on identifying problems with Agile. Most of the time I will call for some common sense, to get people to think about their project management practices and shape it around their teams. Unfortunately, it’s all too common for teams to shape themselves around their project management practices or allow a scrum master to shape the team around what the SM calls Agile.
This article will cover a few suggestions and questions you can ask yourself and your team in order to help shape your project management practices around the way your team works best. I have tried these things and they have worked out brilliantly so far. Hopefully, this will help those of you who have experienced the problems I’ve spoken about in previous articles.
Meetings
My first big issue with Agile in practice is the number of meetings developer have to go to. In my opinion, a daily stand up meeting is egregious. If your team feels as though they NEED to meet every day, it seems like there may be a lack of effective communication throughout the workday.
Ask yourself how often your team meets, what the meetings are about, and if all of those meetings are absolutely necessary. If you find that certain meetings are unnecessary or could be done in a different way, talk to your team about it.
I’ll give you an example. I try to push back against an enforced daily stand-up meeting when I can. I’ve often found that most of the time team members will communicate with each other asynchronously, using tools like Slack, in order to solve problems without disrupting the entire team. I’ve also found that it is far better to meet on a schedule based off of necessity. For example, sometimes we need to pull everyone aside and get on the same page about certain things or address a problem that may be plaguing the whole team. This doesn’t always happen and therefore we don’t need to meet if there is no reason. This applies not only to the stand-up but all the other enforced scrum meetings as well. Often times, I’ve found the presence of a whole team to be unnecessary.
Obviously, think about this and apply it to your current situation in a way that works for your team/project.
Estimation
This is a part of Scrum and Agile that I really don’t care for. The standard estimation requires that each story (I’ll talk about stories next) be assigned a point value that will determine how long that story is going to take and how valuable it is. One of my biggest problems is that estimation uses a very strange and rigid system. The most commonly taught practice is to use Fibonacci numbers for story points. So you can have a 3 point story but not a 4 point story. Why can’t you have a 4 point story? Because That’s not how Agile is done. Other people have suggested using T-Shirt sizes or other ridiculous things, but they all have the same problem, i.e. why can’t I use that point value, because Agile.
What has worked for me is not estimating the tasks at all. You can sort them by order of importance and take care of them like that. This honestly depends on your project. I have not worked on every software project so I’m sure there are projects and teams where this won’t work so you have to think about it and question the process to get the most value out of it.
Scrum Stories
While I’m not against having tasks, I am against how scrum handles tasks. Any time something is given a special label to make it sounds better than what it is (like a story instead of a task) I am always skeptical. The reason I’m skeptical is that when this sort of thing happens it’s usually used as a coverup for something else that may not be so great.
I want to be clear about what I’m advocating for and against, so I’ll tell you positive things about tasks in general. I think that viewing your work as a whole from the perspective of the end-user is good, we should always keep the end-users in mind when we make things. My criticism comes in more around the handling of the fancy scrum tasks.
However, one problem with the user stories is that they define a rigid framework. The framework will be fine so long as a user sticks within the bounds of the framework. If they go outside the bounds of the framework it will usually break. This occurs when you have some tasks that require some special cases, and there will always be special cases.
Another problem is that Scrum and Agile try to break down stories too much, which kind of causes the first problem. I’ve often found that Scrum tries to break down user stories to the smallest parts just to break it down. This can sometimes add value, but not if you’re just doing it to do it.
The answer to these issues to really to think about the best implementation of stories and make sure that what you’re describing in your tasks isn’t too rigid a framework. This is really subjective and relies on your understanding of the project at hand, so this is a super loose suggestion and really relies on you, the reader, to interpret this and think about how to apply it. I can’t tell you how to apply this because I don’t work on your team and I don’t know your project.
The Sprint
Scrum sprints are far too rigid. There are many places that will say “A sprint must be 40 points, no more and no less and must be completed in 2 weeks.” This is kind of the standard Scrum implementation that most Agile courses preach. This is obviously a bad system and flies in the face of the philosophy of Agile. If I had a dollar for every time I got a critical issue that needed to be fixed and the scrum master said: “We can’t do it this sprint, it will just have to wait until next sprint” I wouldn’t need to work anymore, but here we are.
If you’re curious about what the answer to the problem is, maybe read a few books and take some personal time for self-reflection and personal betterment. I think the answer is obvious, don’t timebox your team so rigidly. There is no reason that you NEED to have 40 points every sprint and you don’t NEED to do it in 2 weeks. You also don’t NEED to cut releases at the end of each sprint cycle (more on this in a bit). If you want to use a sprint, fine, but don’t timebox yourself into a corner. Again I can’t really tell you how to do this because I don’t work with you and I don’t know your project, you’ll just have to think about it for yourself.
Releasing Software
One thing I do really like is the idea that you can release software often. I think this is probably the best thing about Agile, but it can also paint you into a corner as well. There are many teams who use their sprint to define a time frame for releases. So at the end of your 40-point 2-week sprint, you have to release whatever the hell you’ve done to production. That just sounds stressful and unnecessary.
The answer for many different teams has really been to release when it’s ready. Estimating how long a certain piece of work is going to take is NEVER going to be accurate so you can give a general timeframe based on what you’re doing. For example, creating a login page wouldn’t take as long as creating an analytics dashboard. So you’re going to give a shorter timeframe for creating the login page than you would for the dashboard. Don’t try to limit yourself to a rigid timeframe, make sure that the timeframe fits the work.
Management
Managers are an unavoidable fact of life. You’re always going to have managers and some managers are going to be bad. I think Agile courses empower bad management but these are some suggestions to fix that.
Most of the managers in the Agile/Scrum world are non-technical people. These are people who realize that the software industry is incredibly profitable. They realize that they don’t have the aptitude for software but they still want a piece of the pie. The unfortunate thing is that they have succeeded better than us developers! If you look up the average base pay for a scrum master on Glassdoor in the US it is $93,285, while the average base pay for software developers is only $80,018! Most of these people have never touched a piece of code in their lives and they’re getting paid more for what we’re doing?
I think that non-technical managers need to have a much different relationship with developers than they currently do. If you don’t know how to write code then you need to step out of the way. Erik Meijer says that managers should be more like beekeepers. They should make sure that the bees are happy and they are producing the right kind of honey. I like this analogy but I’m going to expound on it a little.
Your job as a manager is in part to make sure your developers are happy. Make sure they have the right computer, their internet isn’t being restricted, they have all the tools they need to write code. You should be the primary intermediary between the business and developers to make sure that the business doesn’t step in the way of your developers. You should never be telling the developers “You have to do this process to write the software” because it isn’t your place. Your developers are the domain experts so they have knowledge that you don’t so you don’t have to tell developers how to write code, they’ll figure it out.
If you’re already doing these things and your developers are happy, good on you, keep going.
Conclusion
I’m not trying to make this a rebuke of the Agile philosophy, this is all about the Agile that we see in practice. That almost always involves scrum and the rigidity that brings.
The main point of this article is to give you some suggestions to think about and some questions to ask yourself as you go throughout your day. The point of those questions and suggestions is to take the rigidity out of your project management and return your flexibility. If you read this and then see something in your workplace that may not be quite right or could be improved engage in the Socratic method with your manager and your team to try to get to the bottom of something. If the base answer ends up being “because that’s not how Agile/Scrum works” then you’ve just located some bullshit and taken a good step to calibrate your bullshit detector.
I want you to remember that I’m not telling you that you HAVE to follow the things that have worked for me (except the managers) but you SHOULD think about it and figure out what is going to work for you and your team and the project you’re working on. Think critically and don’t do things blindly, don’t just do something because the manager told you to.
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!
