Contacts:

www.ainstainer.com

info@ainstainer.com

UK: +44 208 819-62-52

US: +1 917 259-10-03

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

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.

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.

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.

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.

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.

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

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

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

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

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

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!

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 capital-productive 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: