Stacia Viscardi about “Poor Quality of Software”

This post will tell you about Stacia Viscardi’s, author of “The Professional ScrumMaster’s Handbook”, opinion regarding “poor quality of software”.

About the author:

Stacia Viscardi about “Poor Quality of Software” Stacia Viscardi is an Agile coach, Certified Scrum Trainer and organizational transformation expert, devoted to creating energized and excited teams that delight their customers and inspire others. In 2003 she became the 62nd Certified ScrumMaster (there are now over 200,000!), and founded AgileEvolution in 2006. She has helped companies like Cisco Systems, Martha Stewart Living, Primavera, DoubleClick, Google, Razorfish, MyPublisher, Washington Post and many others find their way to agility.

A self-proclaimed process nerd, she loves helping teams and organizations discover the Scrum/XP/Lean mash-ups that enables focused, flexible and fast delivery of products. She created the blog HelloScrum (coming soon!) to share knowledge, tips, and tricks with Scrum practitioners, and co-founded KnowAgile, an agile testing website.

1) Why customers get poor-quality software while working with remote software development teams?
2) According to your experience, if you could distinguish three key reasons of poor software quality, what would they be?
3) Could you give customers a practical piece of advice, what they should pay their attention to in order to avoid low software quality?

Stacia Viscardi: Any team – remote or not – is capable of producing poor quality software. I find that poor quality is a surety in fixed scope/time/budget projects. Customers should realize that a software development team does not have a crystal ball in which it can exactly predict the outcome; rather, the best outcomes are shaped by a team working in a close relationship with its customer. A customer should know that it will require quite a bit of work on his or her behalf to get the product that he/she really wants; the more effort and communication with the team, the better the result. Remote teams face a bigger challenge because the customer they need to negotiate with is never really there. Customers should set up weekly calls or attend sprint reviews (if the vendor is agile), as well as reach out frequently to see if the team has any questions or concerns. Customers should realize that software development teams want to please them, and when pressured to work harder and faster they will do so; however, the consequence to a faster pace often means a lower quality output. That fact is not always made clear. The customer should define the overall expected quality outcomes by talking with the team and documenting it if you have to. While it’s tempting to push a team to work harder and longer – weekends and late nights – keep in mind that a team that works a sustainable pace will usually create a higher quality product. Unhappy teams = cranky systems.

Another bit of advice: keep an eye on quality before the project begins, during the procurement process. Look for vendors that run agile process and whose teams can tell you their “Definition of Done” for a requirement, an iteration, and a release. And don’t be fooled by a Scrummerfall team! In other words, when a vendor says they’re ‘agile’, ask how they might approach your needs by showing you a release plan. You should see functionality chunks as milestones in the release plan, not “percent phase complete” or “code complete” milestones, for example. Ask about the testing process; seek vendors who build in quality as they go, and who can give you a sandbox to play in as product is built iteratively. If a vendor engagement manager does not let you have direct access to the team at logical points in time, my advice is to run, not walk, to the next vendor who does.

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>