The perfect project management framework doesn’t exist

If you work with them, you undoubtedly heard a software engineer complain about project management methodology. “This isn’t Scrum; it’s water-scrum-fall,” they’ll say. Although I agree that we should improve the process continuously, and there’s always room for improvement, I’m afraid many of us are wrong about what it ought to be and how we’re getting there.

We’ve all been in that situation. That big project where the customer’s requirements are set in stone to the implementation level. Nonetheless, you’re told “we do Scrum”; the Scrum ceremonies are all there. Or that project without Product Owner, is not involved, lack the mandate to make decisions about the product, or has absolutely no knowledge about the requirements.

In situations like these, a team member will take the Agile Manifesto or collect some Medium posts about Scrum, say how bad our project management is and plea for change. Being conscious about it and seeing room for improvement is actually wonderful. However, we have to be equally aware of which changes are improvements.

When discussing project management systems, we often grab our favourite approach and compare them to the status quo. When the actual workflow deviates from that framework, it’s typically perceived as bad. Or in other words: the framework is the goal. This shouldn’t always be the case. Ironically, it’s perceived as the ideal solution in an industry where “it depends” is the comic (but correct) reply to most problems in tech. Similarly, one may advocate for a flexible and adaptive approach and yet be reluctant to let their workflow adapt to their continuously evolving situation.

There’s no miracle solution for every team in every organization, as each one is vastly different. I mostly worked for agencies that tried to do Scrum. Tried, because most clients aren’t agile and need to know what they’ll get to get their budget approved by the finance department. This inherently affects how agile we can be and lo and behold, we ended up with water-scrum-fall. There are two issues with this telltale example that propagate into a myriad of symptoms.

First, we lie about our methodology. Sometimes it just isn’t Scrum, no matter how much we want it to be. Instead of becoming comfortable with the idea that we can adapt towards an optimum, a strong pull towards the framework we claim to use remains. A framework that might not even be the best fit, I might add. If the team comes to terms with the fact that a given framework will never work, the members can widen their views and either look at other frameworks or optimize individual problems, even if it’s opposite to what their favourite framework dictates. Note that we shouldn’t lie down without a fight; sometimes, through great perseverance, a client might come through.

The second issue is that a blend of frameworks (Scrum and Waterfall) might be counterproductive. When the specifications and features are fixed, and we’re working towards a big bang release, odds are the project doesn’t need the iterative cycle of Scrum, and we’re crunching features instead. So pretending to build that metaphorical bicycle — when in fact we’re already building the race car the client wants — isn’t helping. It’s just noise. Watch out for practices that void others.

So, what should you do?

Be honest with yourself and your team. Development teams, management teams, and external factors like stakeholders are far too diverse and complex to think a framework will always work for everyone. It won’t. I still think Agile Scrum and Kanban are great tools and what I’ll strive for until something better comes along. However, if people aren’t malleable enough to jump the Agile train, we’ll have to find a compromise because being on different trains isn’t an option.

Perhaps you can experiment with a system optimization goal. It’s something I intend to give a go soon. Instead of implicitly assuming that the de facto standard framework is the optimum, a system optimization goal helps teams tweak their process towards an undefined optimum by making the right choices along the way.

Alternatively, consider small (uncontrolled) experiments to iterate on the way you work in which anyone can propose an idea, and you put it to the test, evaluate and either keep the idea or ditch it. They’re reversible, after all.

Do whatever to make it better! Because there’s no use in doing something that doesn’t work.