5 key ingredients of a successful software delivery
“Software is eating the world” as they say, and that’s not far from reality. It is difficult to imagine a business that doesn’t require software to run. Even traditionally “offline” businesses can’t exist without a number of systems or at least without the “ruler of them all” a.k.a. Microsoft Excel. These businesses already learn a lesson: “If you don’t go digital, your days are counted.” Aside from the established companies, software startups spawn literally every minute, each with another fancy idea for world domination with yet another software product. They are bold, motivated, and in many cases jump “all in” into their endeavors. Unfortunately, the Dunning-Krueger effect is often applied in full… What then?
Projects fail. Sometimes no matter how hard you try, the whole thing is doomed. What makes it even worse is that for all bystanders failure is quite obvious, yet the team is happily steering the ship to the abyss.
There can be hundreds of reasons that might lead to a failure, but I’ll try to share a few key things which can dramatically increase the chances of success (and change the ship’s course to a jolly Caribbean Island).
Make sure you don’t miss these 5 ingredients along with everything else in the project “pot”.
1. Engineers wearing developer hats
When you ask a software developer what they do, you often get: “What do you mean? I am an engineer!”, although people rarely understand what being an engineer truly means. When an engineer designs a machine (or a software product) the thinking should be far beyond using a fancy technology, coding a smart API endpoint, designing some complex class hierarchy, or following design patterns by the book. I’m not saying that it’s bad doing so; nevertheless, importance lies in the real engineering part.
Do the developers ask themselves:
● Do I understand the true purpose of the functionality I’m building?
● How does it connect with the other parts of the system?
● Where does it stay in the whole use case and business process?
● What if this functionality fails at runtime?
(Trust me, at some point it will.)
● If it fails, how do I ensure that the user has an alternative way to get things done? Or if it is mission critical, do I show the right message which tells them what to do next?
● If I were to use the interface I am building, would it be easy or will it make me miserable?
● As an engineer, how can I make the user’s life easier and design a machine (software) that rarely fails, that saves time and effort, and that delivers value?
An “engineer, wearing a developer’s hat” means that they understand that technology is merely a tool. It is great to master your tool, but it is far greater to learn how to deliver a product that generates more value than it causes support burden and headaches. Practically no one cares about your fancy code and design patterns if the result sucks.
2. A technical leader who cares
I wrote about this topic in my CTO as a service article and having a leader who is tech savvy and truly cares is the most important factor. Software engineering is a complex task. Every day there are tens or hundreds of little issues to solve, obstacles to overcome, and decisions to be made. Who is the project’s technical leader? When you ask them about the project, do they think about it as ‘their baby’? Do they care if it suffers, if features are delayed, if the interface is ugly and even useless on some screens, or if developers write lousy code? If there is a production issue, do they wake up at 3 am and go debugging and patching stuff?
If the person leading the project is not like that, the risk of failure is high! Better go find someone else. Someone with passion, ownership, and care. Remember that such leaders are priceless. They are the true leaders; those who lead by example and without the need for fancy titles. Their success speaks for itself.
3. Transparency (not isolation)
In many cases (software) teams are quite detached from the end result of their work. Kept in a silo or completely removed from the actual users and their pain points in another way. Companies also tend to keep the commercial performance of products a secret from the tech team. It’s a common mistake that can have a devastating impact on the team morale and motivation. The progress can be great, but the team might be flooded with complaints, hard push from project managers, product owners or managers who just want to ‘squeeze more’.
An even worse scenario could be when the project gets stuck. Deadlines are not met, users are horrified or worse — indifferent to the monster you’ve created, budget is depleted, and there are tons of bugs in the backlog. Despite that you may tell the team that they’re doing a great job and repeat the ‘we are successful` mantra.
Just be honest. Show that negative feedback to the development team. Brainstorm together on possible improvements. Occasionally put a developer on a 1st line support position so they get true, unfiltered feedback from the users. Tell them that sales are not good (or that they are — depending on your situation). Praise the good results and distribute positive feedback. Appreciate proactivity and good ideas.
4. A walking skeleton
Most people in the software industry are familiar with the concepts of ‘Design Thinking’, ‘Lean’, ‘Agile’ etc. You must be agile! You can’t just use ‘waterfall’; that’s wrong and outdated. Scrum sprints, story points, implement it all… Following the rituals is somehow a guarantee that you will deliver. There is something about agile/lean that is far more important than strict iterations and ‘ticking’ scrum meetings. It is simple and it is about validating (as early as possible) that you are on the right track. Everything else is a detail. Every software project implements a real-life process or multiple processes. Start there. Go through these steps. Take these alternative roads. Achieve a result.
When starting the project make sure you develop, or even better — prototype a bit of every necessary step to cover the end-to-end process as early as possible. It might be ugly; it might lack hundreds of corner cases or details, but it is critical to allow someone to go through the entire process and confirm that it fits the business case.
This is the walking skeleton. You should use this ancient craft to animate it and get it to walk. No flesh, no clothes, no fancy accessories. You’ll add these later. Do not spend the first 5 sprints implementing 5 different login providers for your e-shop instead of developing one type of login, one product listing, basic order, basic payment, and shipping. Get the basics right so I user can have a complete process. Then add bells and whistles, such as clothing and jewelry to your creature.
5. No Overengineering
The last rule is (somehow) related to the walking skeleton but it’s also part of the developer’s psychology. There is even a term for it: YAGNI (stands for You Aren’t Gonna Need It). Every feature must be developed no sooner than when it is needed. Period. For example, why would you spend weeks or months on complex scaling features when you still have zero users, and it is not clear that this product is commercially viable or that anyone would use it? Or why would you develop a micro-services architecture for an internal company tool with 20–30 users max, using a 10-tables database that would never grow bigger than a few hundred megabytes?
The true engineering skill is to do what is needed at the start for an easy separation of concerns at a later stage. For instance, a smart modular monolith is usually a great start in most cases that might end up being split into microservices at a later stage (which also might never happen). The second skill is to make it simple and easy to maintain. Using fancy architecture without the actual need will lead to a steep learning curve for new people in the team. Overengineering in the direction of using complex patterns for a simple case is another thing to keep an eye on.
***
While these five key rules might not be enough to deliver successfully, ensuring they are followed would act as a high-return insurance covering project delivery risk. Maybe I am oversimplifying and missing a critical element? Feel free to comment and share more valuable insights!
