The Best Software Development Method

This article was first published on DZone in 2018.

From drafting the original idea to implementing development solutions, the answer to the best holistic software method is rarely one-size-fits-all.

Knowing that I have been working with project management for almost two decades and that as a consultant I have the opportunity of getting in touch with companies using all kinds of approaches to develop their products, people often ask me what is, in my opinion, the best software development method. Here’s a quick version of my usual answer.

Silver Bullets Don’t Exist

The very first thing you need to be aware is that there’s no such thing as a silver bullet approach that fits all possible projects. Think: each project is a complex problem to be solved, and any different variable in that problem might require a different approach in order to achieve the expected result — even when you comparing very similar problems. For example, we could have two rival companies independently trying to build the exact same product, but since these companies have different characteristics (e.g. different values, different budgets, different metrics, different IT infrastructures, different team sizes, different seniority levels and allocation models in these teams etc), each company might need a different approach to better fit its own reality, even if both are aiming to achieve the same output.

That said, bear in mind that often a single company, and sometimes even a single team, should be using more than a single approach if they are dealing with multiple projects containing different variables. I know that requires extra orchestration efforts, but, well, great orchestration is one of the crucial things you must have anyway if you want to work with the best software development method (more on that soon).

Recently, I got in touch with a company developing a big blockchain related product. The company has 3 dev teams: 1 in Asia, 1 in Europe, and 1 in the USA. Each team is working on a different part of the same product, but each one of them has devs with way different backgrounds. Besides, each team has different priorities: one needs to release often, the second one needs way longer testing and validation phases for each change and the third one is at the moment focusing on R&D. For a while, they struggled trying to find a single process that would support the three teams, until they realised that each team would be way more productive and happy having its own approach — even if they are working on the same product, with the same IT infrastructure, and even the same Project Manager orchestrating all the activities.

Shelf Methods/Approaches

The second thing you must realize is that ‘shelf solutions’ (Scrum, XP, DevOps etc) rarely are, by themselves, optimal solutions. In other words, it’s not only that you have to examine the variables of each problem (each project) and then pick an answer from a set of predefined options (the shelf solutions). In order to get to the best software development method, you must, instead, examine the characteristics of your project and then design your very own approach.

Not to say, of course, that you should ignore any existent models and references. On the contrary, to design the best approach for a specific project, you should have a solid understanding of as many existent processes, frameworks, and practices as possible. Ideally, you should also know and understand well the history and the principles behind all those approaches, rather than only understanding how they are supposed to work, as their principles are way more important than their practices, especially now that you’re designing a new approach. Then you can use these existent models as a baseline for the creation of your method, mixing elements as needed, picking those that make sense in your reality, and rejecting those that don’t.

Orchestration and Continuous Improvement

As you would do when designing a new product, don’t lose too much time on trying to design a perfect development method, either. Design a simple one, as simple as possible. Then start using it to gather actual feedback. Have someone in charge of orchestrating anything related to your brand new method, as in most cases no method will work by itself. You must have someone continuously coordinating the processes and activities, doesn’t matter how you will call this person: project manager, process manager, or Dorothy.

Among all other regular project management activities, this person must take care of continuous improvement as well, which is the most critical factor in order to keep your method healthy and valuable in the long run — although it is as well, sadly too often, the first one teams will leave behind as soon as they reach a good-enough state. Businesses, priorities, technologies, scope etc are constantly changing, thus also your method must always be improved to keep up with all existent variables.

Summing Up