It’s 6pm on a Friday and we’re just about to release the Coronavirus vaccine to the general public. Mike has project managed the whole thing, even though he has no experience in medicine but he does like playing with lego. We’re a bunch of construction workers, artists and poets but that hasn’t stopped us having a go at building the vaccine either. Actually, we’ve already pivoted 17 times, the MVP was a bottle with a note in it and we ran out of time to do proper testing. But hey, we smashed something together in 4 weeks, that person who died has been marked down as a known issue, and Brian said it was okay so let’s get it out there.
This hopefully doesn’t happen in big pharma but nobody really knows why it’s okay to run software projects like this. So how do we fix broken software projects? It’s not solved by big upfront planning where the end goal is hidden behind a (completely different) waterfall and it’s not solved by slicing the problem into tiny incomprehensible tickets where the end goal becomes story points instead of product. Unfortunately, these are the two most common ways of running software projects today!
I want to move away from a world where developers do “techie stuff” and everybody else does “business stuff”. If your business develops software then you already are a software company, so you must take your software seriously. Developers, your world should not end at python mastery or stack overflow - these are tools to solve problems and you are employed to solve problems and not swish tools around. If you are running a software project, immediately reframe this as a business project. Make sure everyone knows what you’re building, why and how from the get go, and remind each other constantly.
Despite all this, we’re more likely to see resistance to the uptake of a real vaccine than the use of some banking software that’s held together by chewing gum and prayer, but that’s another issue.