Patrick Merg about “Poor Quality of Software”

Being and experienced Agile Coach, Project Manager and Product Manager Patrick Merg brings us into his world of understanding and seeing poor quality of software development product. Get acquainted!

About the author:

Patrick Merg about “Poor Quality of Software” Patrick Merg is a results-driven project champion adept at managing all aspects of complex projects from initial concept to final product release. He is passionate about building high performing cross-functional Agile teams that deliver sustainable value and speed time to market. Patrick has a strong background in Agile project management, program management, leading software engineering teams and innovative product development.

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

Patrick Merg: Being successful with remote teams requires a level of maturity that many organizations lack. Often there are no documented standards, no processes, no vision, and so on… This leads to delays, quality issues and general frustration with the remote team. Generally the problem is not the remote team, it’s the customer.

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

Patrick Merg:

  • Product requirements that are unclear and/or poorly documented.
  • A weak product owner or a product owner that will not work off hours to remain in contact with the remote team.
  • Not taking into account cultural differences, both location and company cultures can have a big impact on team dynamics.

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

Patrick Merg: Always check for understanding when reviewing the product backlog. Since your product owner can’t be there with the team you have to fill the void with documentation, mockups, and conference calls. Spend the extra time to prepare these artifacts one sprint ahead of development and review them with the remote team leads. Get your stories clear ahead of the sprint and a lot of trouble goes away. Insist on frequent demonstrations and good software process. Be very sure the team is on the same page.

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>