The Benefits of Applying Multidisciplinarity in Software Development

On the teamwork factor

All things are difficult before they are easy. – Thomas Fuller

Each one of us has his/her own way to process things and hence, can respond with a unique way of providing a solution. Imagine bouncing ideas with people just like you, with the same expertise and way of filtering requests. It would be like having a conversation with yourself over and over again. Imagination can only go so far without being challenged. The beauty of being different, with diverse experiences, points of view and of interest is that great ideas and solutions can result by putting people from multiple software disciplines within the same context.

It is not supposed to be easy right from the start or make you feel inspired and enlightened after the first session together. It takes work, of course, just like with any other skill you want to master.

From complete strangers to a group of people with the same goal as delivering a product or just a few functionalities from sprint to sprint, for example, there are a few steps, which I observed and derived from my own experience in working with multi-disciplinary teams, which each member should abide by:

• Be respectful; you all serve a common goal after all. Nothing more to explain here, it’s that simple.
• Accept different points of view, see them as being different from yours, think about the value they might bring, and challenge them in a proactive manner if the situation requires it.
• Expect your own ideas to be challenged, and learn from the entire process. From learning to express yourself better or give better arguments, to have the maturity to accept that your idea might not be the suitable one for now.
• Sometimes an idea, whilst might sound perfect in your mind for the moment, might not be the best one for the entire group. So any idea ego needs to be left out if you’re striving for a productive meeting with the team.
• You might have heard this, yet it is true: there is no “I” within a team. These words really stuck with me, and you should follow this mantra in your process of working with a multi-disciplinary team too.
• Bond with each other. Don’t underestimate the power of a weekly team coffee (or other wonderful beverages). Even in an online setting.

If you are curious about “How to turn a group of strangers into a team”, Amy C Edmondson delivered a very interesting Ted Talk on this specific topic.

Why multidisciplinary

With the multidisciplinarity that characterizes our IT sector comes a lot of specialized competence from different software development areas. Mix in a group of people passionate about product design, about coding in .NET, in Java, PHP, or other languages, as well as about automated testing, DevOps, or Project Management, and you can put together a dream team armed with the best capabilities to handle any stage of a project and taking it to the next levels. My background of different experiences in working with multi-disciplinary teams has led me to the conclusion that multidisciplinarity can bring multiple benefits to the product and to the team:

• The product is covered from every aspect of development. By having a multidisciplinary software development team thinking about what needs to be achieved in the end and preparing all the right setup for the product, observing it, and watching it grow, you make sure the entire process is covered. The product thus grows healthy, strong, and ready to be launched.
• These teams work because they offer the project a real experience on the phases the product would go in the real world: from the user experience, quality, and value of the project, to the features offered and many more. In addition, the team is always responsible for the delivery of the product.
• The bounce of ideas is priceless due to different concerns on the project aspect – so when a developer is invested in building the complex system that users are going to interact with, the designer is concerned about usability and intuitiveness, while the quality engineer might have security in mind. All different aspects, all on the same project, all valid.
• Working in a multi-disciplinary team is paramount for promoting growth and knowledge, as well as expanding the product horizon. People in roles that used to come in at the end now have input from the beginning (and can make informed decisions). Decisions that can improve the product immensely and all team members can now work on the final goal with the full picture in mind
• Every discipline is crucial in delivering products that exceed expectations and lead to happy customers. You need to have every discipline represented throughout the process to develop a robust solution, on time and on budget. It might seem logical to only have design or quality checks invested in the specific moment of the product lifecycle, yet that can lead to building features that need massive changes in the end; this leads to extra-costs and delays in launching the product.

In practice

Let’s take a trip down memory lane – I remember fondly of a collaboration a while ago while working with a group of enthusiastic and visionary people that had a really interesting project idea. There’s certain energy they give away that’s catching very quickly and makes you feel inspired and even more engaged in your own work.

Throughout the process, within my role as a Project Manager, I was in constant discussions with the client to understand and clarify different features to be added. At the same time, I established, together with the talented people in the multi-disciplinary team that I was working with, what was feasible within a certain timeline, what brought performance, and what raised to the expectations of a new and shiny product from a UX point of view. And, of course, what could be done faster and yet still match our QA quality standards. All points of view were taken into account.

And as we worked, sprint after sprint, we became, from a group of people that barely worked with each other, a multi-disciplinary team, learning a lot together and from each other, and becoming a power team delivering a successful product.

It required a lot of commitment from the team, coming up with great ideas and providing arguments to motivate them, as well as a lot of believing in our goal and putting time and effort to achieve the final product. Seeing the client in end content and even more enthusiastic about the future possibilities with the product, and the new opportunities that it opened up, made it all worth it and confirmed that our strategy as a multi-disciplinary team was sound.

Some final thoughts

Of course, the concept to have such a team might be a dream for some. In the ideal world, for all the amazing projects and ideas we need to implement, we have an army of people specialized in all the phases the product must go, securing the moment of delivery as being perfect.

In the real world, that is not always the case. One or two people within the same discipline might face all the challenges on the project. This might sound scary, yet based on the project complexity, that might even be more than enough and very productive based on the context. After all, there are people out there who are trying to develop their own solution and go at it alone, and they need to switch multiple hats depending on the roles to have in mind, as Mark Rendle put it in his presentation during Innovative TechTalks 2020.

That doesn’t mean the dream team knowledge is not there or contributing in any way. You might have experienced it within another project; it might be within your company culture. The key is to always strive for continuous learning and innovation, within your team, for your client, and for the product.