Felix Rüssel about “Poor Quality of Software”

We continue to clear up the challenges concerning poor quality of software. And our second expert sharing his experience is Felix Rüssel.

About the author:

Felix Rüssel about Poor Quality of Software Felix Rüssel is an experienced consultant in Project Management, Agile/Lean, Agile Program Management and works as a contractor at large corporations in Germany. Remote teams are involved almost into all the projects and he is responsible for setting up processes and structures that allow these teams to deliver high-quality results. He is Certified Scrum Professional (CSP) and the first German certified as Scaled Agile Framework Program Consultant (SPC). He can be reached via his website (www.agile-rescue.com) or via his blog (www.agilerescue.de)

1) Why customers get poor-quality software while working with remote software development teams?

Felix Rüssel: Very often it happens to hear that reaching a high quality level with a remote team is more difficult than with a local one. In most companies you will find people who can tell some horror stories how projects were screwed up by remote teams – more specifically by teams working offshore or nearshore.

It might be true that it is more difficult to align a remote team of developers than a local one, its basically about team culture and the shared quality understanding. If you are able to establish a common understanding of quality level expectations, than you are on a good track. Add (demand!) state of the art agile engineering practices and hire a few good people as core of the remote team and you will get good results.

2) According to your experience, if you could distinguish three key reasons of poor software quality, what would they be?

Felix Rüssel: Missing common understanding of the goals (why), the requirements (what), the technical constraints (how) and constraints on time/budget (resources). Short: There is no real plan (be it agile or traditional) for the work to be done.

No feedback loops and therefore working too long with assumptions. Using a waterfall like approach where some work is defined (in “details”) in the beginning and the result is only presented after a lot of time has been invested. Very often the results are disappointing but no resources or time is left to change that.

Wishful thinking. Reality can be sometimes hard and therefore difficult decisions must be made quickly and clearly communicated. That is a management task but a lot of “managers” I have met during my life as IT professional are not able to do that. So a lot of waste is build up but nobody wants to talk about it.

3) Could you give customers a practical piece of advice, what they should pay their attention to in order to avoid low software quality?

Felix Rüssel: You need to build up a relationship with your remote teams as you do with your local teams. Instead of a process with long specialized phases I recommend using agile process with short iterations and quick feedback. In the first iterations you should invest into building up a shared, good understanding of the work to do by increasing the quality of the requirements, doing spikes (to check technical assumptions) and setting up the delivery context (build & test infrastructure, deployment rules & processes, testing processes).

Get involved into a discussion with our experts and get to know how to avoid pitfalls in IT business!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>