In one e-book “Poor Quality Challenge of Software Development with Dedicated Teams” you will be able to learn the most common cases, why companies get a software product of low quality at the output working with dedicated teams. Ainstainer has put together various opinions of experienced specialists on this issue. For more information: http://www.ainstainer.com

1. Contacts:
www.ainstainer.com
info@ainstainer.com
UK: +44 208 819-62-52
US: +1 917 259-10-03

2. Introduction .......................................................................................................................................... 3
About the experts ................................................................................................................................. 4
Question #1: Why do customers get poor software quality while working with remote software
development teams? ............................................................................................................................ 7
Question #2: In your experience, if you could name three key reasons for poor quality of software
product, what would they be? ............................................................................................................... 8
About poor quality challenge in common.............................................................................................. 9
Practical advice from the experts ....................................................................................................... 11
About Ainstainer Software Development Teams ............................................................................... 14

3. When working with dedicated software development teams customers often get a poor quality
product as the output. All in all, such software turns out to be unfit for both parties: it is difficult to use
for end-users and to maintain for software developers. Customers’ profits suffer great losses due to
the poor quality of software.
This issue is important for a number of reasons, including the fact that most of the potential users will
be deeply dissatisfied with having to use an unwieldy software product, especially the one containing
bugs. Examples of such software may be an application, in which it is difficult to perform simple
tasks, or a software system, whose behavior is at times rather odd or whose responsiveness leaves
much to be desired. As a result, dissatisfied end-users may prefer a competing solution, thus causing
a significant drop in customers’ revenue.
An additional drawback of a poorly-written code is that it makes a future development and
implementation of new features more complicated and, as a consequence, several times costlier.
Due to its unsatisfactory quality, developers may have to spend significantly more time on analyzing
existent code and adding new features and capabilities into it while trying to preserve a workable
state of the current release.

4. We have interviewed 8 experts in either software development/project management or Agile/Scrum
development to determine the commonest causes of poor quality of software products developed by
remote teams.
Michael Boyle
Managing Director at Procurro Solutions
Michael Boyle is an internationally recognized expert in the Project
Management, Business Analysis, Solution Architecture, Portfolio
Management and Business Process Modeling domains. After 12 years of
working in virtual teams and managing them, he established his own
company – Procurro Solutions. The company strives to enable its
customers to transform their business through deployment of unique
project management-, business analysis-, software development- and
testing personnel.
Maarten Pors
Project Management Consultant
Maarten Pors is an independent Project Manager with vast experience in
managing remote development teams in Eastern Europe (nearshoring).
Stacia Viscardi
President & Consultant at AgileEvolution, Inc.
Stacia Viscardi is an Agile Coach, a certified Scrum Trainer and an
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, the Washington Post and many others find their
way to agility.

5. Elizabeth Harrin
Program Manager and Writer at Otobos Group
Elizabeth Harrin is Director of The Otobos Group, a project
communications consultancy, and the author of 3 books on project
management. She authors the popular blog, A Girl’s Guide to Project
Management.
Felix Rüssel
Agile Consulting (CSP) & SAFe Program Consultant (SPC) at Felix
Rüssel Consulting
Felix Rüssel is an experienced consultant in Project Management,
Agile/Lean, Agile Program Management and works as a contractor with
large corporations in Germany. Remote teams are involved almost in all
projects and he is responsible for setting up processes and structures,
that allow these teams to deliver high-quality results. He is a Certified
Scrum Professional (CSP) and the first German certified as a Scaled
Agile Framework Program Consultant (SPC). He can be reached via his
website (www.agile-rescue.com) or via his blog (www.agilerescue.de).
Kate Terlecka
Scrum Master, Coach & Trainer at Brass Willow
Kate Terlecka is one of the most experienced professional Coach,
Trainer & Independent Consultant in the field of Agile and Scrum in
Poland, and has a wide experience of team management all over the
world. She is one of the Scrum.org’s Professional Scrum Trainers and the
Agile Special Forces – usually thrown at “the challenge of your life” teams
and projects. She researches human behavior and team dynamics with
focus on gender and cultural differences. Kate also teaches classes on
Scrum and Management Practices, as well as coaches individuals. She is
also a talented author of the blog named “Control Your Chaos” and owner
of the BrassWillow company. Feel free to get acquainted with
achievements of this efficient master.

6. Pascal Mauray
Senior Consultant (Test & Project Management) at Trasys PSF
Luxembourg
Pascal Mauray is an experienced professional in the Business Analysis,
Test- and Project Management. He participated in implementing large
systems. Now he is employed in setting up, enhancing and facilitating
nearshoring with development teams in North Africa in the KASAM.
Patrick Merg
Product-, Project-, Engineering Leadership at Snap-on Diagnostics
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 strong background in Agile project management, program
management, leading software engineering teams and innovative product
development.
Our experts’ opinions are presented below. You will learn WHY we get poor software development
(main causes, the most common mistakes and so on) and also HOW to avoid poor code quality at
the output.

7. Felix Rüssel:
It might be true that it is more difficult to align a remote team of developers than a local one, it is
basically about team culture and shared quality understanding. If you are able to establish a common
understanding of quality level expectations, then you are on a good track.
Maarten Pors:
Besides the usual issues like bad project management, lack of common understanding of goals, it is
about communication and trust.
Elizabeth Harrin:
I think, if you do get poor quality results, then there are a number of factors that contribute, including
poor specifications, the language barrier and the inability to keep both the client and the vendor up to
date with changes and progress.
Patrick Merg:
Being successful with remote teams requires a level of maturity that many organizations lack. There
often 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.
Pascal Mauray:
• Remote team is not the root cause of poor quality. Remote team adds more difficulty and
complexity in establishing good communication, exchange and understanding between both the
customer and the development team.
• Lack of analysis on what business wants, assumption what is requested is fully understood in
the same way by the team in charge of developing and delivering the product are explanations why
customers get low-quality products.

8. Michael Boyle:
1. Poor requirements: the business is not clear in what it wants;
2. Lack of a Business Analyst: one of the biggest development needs we have is tied to
understanding what is needed and conveying this information to the developers;
3. Cultural differences: especially when #1 and #2 come into play, very often it is difficult for
development to go back to the business and say “it doesn’t make sense” or “it is not clear what you
mean”.
Felix Rüssel:
1. Missing common understanding of the goals (why), the requirements (what), the technical
constraints (how) and constraints on time/budget (resources). In short: there is no real plan (be it
agile or traditional) for the work to be done.
2. 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.
3. 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 an IT professional are not able to do that. So, a lot of waste is built up but
nobody wants to talk about it.
Maarten Pors:
1. Communication, communication and communication. It is as simple as that! Now let’s assume,
that you have an application and you want something simple done. Say you want the OK button to be
green. But there are many different shades of green. Of course, you need good project management,
you need a scope, you need requirements and you need an agile process to make it work. But in the
end, if you do not have good communication and mutual trust, it will not work!
2. I have to agree with Mr. Felix Rüssel: “A lot of “managers” I have met during my life as an IT
professional are not able to make good and fast decisions. So a lot of waste is built up but nobody

9. wants to talk about it.”
3. Good knowledge of IT and IT-related stuff doesn’t necessarily make you a good manager or a
good communicator. So find someone who is good at communication and it doesn’t have to be the
best software engineer in your company.
Elizabeth Harrin:
1. Poor specifications – a client, that thinks they know what they want and a vendor, who does
not check with them at each step of the way as the requirements will no doubt evolve.
2. Poor communications – either because of a lack of understanding of the other’s language or
because they fail to keep each other informed.
3. Lack of business understanding – when the vendor does not have an adequate understanding
of the client’s business and the objectives they are trying to achieve with this software.
Pascal Mauray:
1. Try to implement a kind of incremental implementation, so that, after each iteration, it is
possible to validate what is delivered in comparison to what was expected. This will allow immediate
correction.
2. In a more general point of view, provide an excellent analysis trying to convert requirements of
the highest level of quality into specifications for the team in charge of the development. This has to
be done as soon as possible.
3. Put in place a team manager aware of both cultural aspects. He should be able to manage a
kind of iterative process to understand, what the actions to correct the approach of the remote
development team are and to validate the understanding by the remote team.
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 with which they 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

10. 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 of a faster pace often is 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 need be. 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 at a sustainable pace, will usually
create a higher quality product. Unhappy teams = cranky systems.
Kate Terlecka:
There are a few reasons, but three of them are the most significant in my opinion.
Human interaction
You have, probably, heard, that only 20% of the communication is enclosed in words. The rest is in
the interaction – the body language, the tone of voice, facial expressions and the general feel of the
other person. If you’ve never met, you cannot imagine what that particular person needs. If this
happens, engineers will build something that will be
good to their best knowledge, but it’s their
knowledge – not the person’s using the solution.
This way, technically, this system can be good and
high quality, but if it comes to usability, it will fail to
deliver the value. The same rule applies in the
other direction. A customer or a user of a software team cannot imagine, what they will need in the
creation process without meeting them. So instead of making them meet, someone puts an analyst
that serves as a go-between. This creates the effect of the Chinese Whispers – the person in the end
has no way of knowing what the person in the front actually meant.
What’s even more interesting is that you don’t really need a remote team for all of this to happen.
Lots of companies fail to talk to their IT guys, even if they sit 3 meters from them.
Complexity
The problem with software is that it’s an extremely complex element. It’s actually so complex, in lots
of cases it’s literally unimaginable. Even experienced professionals are unable to comprehend the
whole, large computer system. They rely on some
rules and set limits to operate in this world. It’s just
like programmers were creating a new universe,
with the laws of physics included. And each and
every system is different. The possibilities are
endless. There are some guidelines that help

11. create a system which is maintainable and easily understandable, but applying these rules seems
expensive. The problem one starts facing is when
we are getting close to the deadline and programmers are pushed to cut corners. This results in
exponential growth of the complexity and price of the system.
Value
Last, but not least – or actually the most important is value. When working with a remote team, you
only pass orders through some way of communicating. The most important thing should be realizing
what you actually want to accomplish with this system. The usual answer is: I want to make/save
money. True, but how? If the team building the software knows that the primary focus is to, for
example, shorten the time of customer service, they will strive to automate as much of the process for
the customer service assistant as possible. If the value is in people making payments, they will focus
on the swiftness and reliability of the payment app. But first, you, as the customer, have to realize
what that value is. This way you will get the quality and reliability you need.
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 troubles go
away. Insist on frequent demonstrations and good software process. Be very sure the team is on the
same page.
Stacia Viscardi:
Keep an eye on quality before the project begins, during the procurement process. Look for vendors

12. that run an 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 the 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.
Kate Terlecka:
Pay attention to three factors: human interaction, complexity and value. Be there for the people who
are building your software, contact them with real users, so that you can get what you need and your
money’s worth. Mind complexity – remember that they are building a new universe, setting new laws.
So agree on standards, trust their expertise and inspect the outcome often, so that you know you
understand each other. But to do that, you need to know what value really means for you.
So start here.
Elizabeth Harrin:
No one buys software, they buy a
solution to a problem and vendors
need to understand the problem
in order to be able to adequately
produce quality software. So spend time together establishing, what you want to achieve and the
options for achieving it.
Maarten Pors:
Take some time to explore the possibility of remote software teams, (nearshoring) they are fast, they
are good but…you need to invest time into the relationship with your remote engineers. And what if
you don’t have the time or resources to invest but you still want to use remote engineers? Then look
for someone with experience that can help you. This makes communications easier and reduces the
chances of a bad project that ends in producing a bad product.
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

13. 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 and testing processes).
Pascal Mauray:
Try to use a kind of
incremental
implementation, so that,
after each iteration, it is
possible to validate what is
delivered in comparison to
what was expected. This
will allow for immediate correction.
In a more general point of view, provide an excellent analysis trying to convert requirements of the
highest level of quality into specifications for the team in charge of the development. This has to be
done as soon as possible.
Put in place a team manager aware of both cultures. He should be able to manage a kind of iterative
process to understand what the actions to correct the approach of the remote development team are
and to validate the understanding by the remote team.
Our next series of publications will deal with the challenge of communication when working with
dedicated remote teams.Keep in touch with us and don’t miss the most interesting and necessary
information on the subject!

14. Who we are?
Ainstainer Software Development Teams is a
software development outsourcing company,
with software development centre in Kharkov,
Ukraine.
What we do?
We offer a wide range of such software
development services as establishing dedicated
teams, Web-, Software Apps-, Mobile-, Google
Glass Development, Responsive Web Design
and Mobile-, Web- & Graphic Design.
Who we work with?
Ainstainer offers cost-effective and capitalproductive solutions for such segments as
Software Product-, Agile-Minded-, Startup-,
eCommerce Companies and Software
Development Service Providers. We have
already successfully collaborated with customers
from America, Denmark, Belgium, Norway,
Sweden, Germany and Holland.
Learn more about us here!
Join us at: