Droptica.

com
 Best practices for
software
development
teams

No part of this E-book may be reproduced or transmitted in any form or by any means, electronic or
mechanical, including photocopying, recording or by any information storage and retrieval system,
without written permission from the publisher.

The information and methods describe within this E-book are personal thoughts of the authors.
Pieces of information are not intended to be a definitive set of instructions for managing software
development agency and are for general informational purposes only. While we try to keep the
information up-to-date and correct, there are no representations or warranties, express or implied,
about the completeness, accuracy, reliability, suitability or availability with respect to the information,
products or services contained in this E-book for any purpose. Any use of this information is at your
own risk. You may discover there are other methods and materials to accomplish the same end results.
We encourage to seek your own path.

Droptica.com
Table od Contents

A note from the authors................................................................................. 6

Introduction.................................................................................................. 6

Part ONE:
Teamwork makes the dream work................................................................. 7

1.1 How to hand over the project to another software house........................ 8

1.1.1. How many projects are too many?.....................................................................................................8
1.1.2. How to prepare...................................................................................................................................9
1.1.2.1. Organize project assets...................................................................................................................9
1.1.2.2. Status report.....................................................................................................................................9
1.1.2.3. Deployment pipelines...................................................................................................................10
1.1.2.4 Maintain control..............................................................................................................................10

1.2. Software outsourcing - how to find the best team?.............................. 10

1.2.1 The matter of experience..................................................................................................................11
1.2.2. Has the team worked together?.......................................................................................................11
1.2.3. Cut communication lines.................................................................................................................12
1.2.4. Check availability and scalability......................................................................................................12
1.2.5. Build trust..........................................................................................................................................12
1.2.6. Access to specialist knowledge.......................................................................................................12

1.3. How to communicate with your customers.......................................... 12

1.3.1 Communicate directly......................................................................................................................13
1.3.2. Ask before making assumption........................................................................................................13
1.3.3. Explain things effectively .................................................................................................................14
1.3.4 Be patient, professional, polite..........................................................................................................14
Voice of Droptica..............................................................................................................................15

1.4. Models of cooperation of the development team and the client based
on the examples used at Droptica............................................................... 15
1.4.1. Model 1: Product Owner at the client, with the rest of the team at own company........................16

Droptica.com
Voice of Client............................................................................................................................................16
1.4.3. Mixed models...................................................................................................................................17
Voice of Droptica........................................................................................................................................18

Part TWO:
Effective software delivery.......................................................................... 19

2.1. How does Scrum improve software development quality?.................. 20

2.1.1. Definition of quality...........................................................................................................................20
2.1.2. What is Scrum?.................................................................................................................................20
2.1.3. Frequency of release........................................................................................................................20
2.1.3.1 Requirements: consultation and good code.................................................................................21
2.1.4. Tests from the beginning of the project...........................................................................................22
2.1.4.1 Benefits: less costly mistakes, fast response, quick reaction.........................................................22

2.2. Remote scrum team............................................................................. 23

2.2.1 Why choose remote scrum team?....................................................................................................23
2.2.3. So many meetings! ..........................................................................................................................24
Voice of Droptica........................................................................................................................................25

2.3. Why do we automate software development? ..................................... 25

2.3.1 Characteristics of automated software development process...............................................26
2.3.2. Automatic testing..............................................................................................................................27
2.3.3. Benefits of automation......................................................................................................................28
Voice of Droptica........................................................................................................................................29

2.4. Sprint Retrospective meetings - the way to continuous improvement of

work ............................................................................................................ 29
2.4.1 What is Sprint Retrospective?...........................................................................................................29
2.4.2. Benefits for the client........................................................................................................................29
2.4.3. How to prepare for sprint retro?..............................................................................................30
2.4.4. Examples of improvements we introduced...........................................................................31
2.4.4.1. DevOps and software development.............................................................................................31
2.4.4.2. Marketing.......................................................................................................................................31
2.4.4.3. Overall work organisation.............................................................................................................32

Droptica.com
Part THREE:
Sharpen your tools....................................................................................... 33

3.1. With the right tools, working with a team that is spread out over many
locations can be comfortable and pleasant................................................. 34
3.1.1. Project management tools...............................................................................................................34
3.1.2. Two communication speeds............................................................................................................35
3.1.2.1.Text chat..........................................................................................................................................35
3.1.2.2. E-mail, Phone call, Video chat.......................................................................................................36
3.1.3. Important quality assurance elements.............................................................................................36
3.1.3.1. Daily Scrum....................................................................................................................................36
3.1.3.2. Code Review.................................................................................................................................37
3.1.4. Good practices.................................................................................................................................37

3.2. Ideal IDE and Linux configuration for work with PHP and Drupal......... 37
3.2.1. IDEal IDE...........................................................................................................................................38
3.2.2. Docker, Nginx proxy for Docker, docker-drupal..............................................................................38
Voice of Droptica........................................................................................................................................39
3.2.3. PHP CodeSniffer...............................................................................................................................39
3.2.4. XDebug.............................................................................................................................................40
3.2.5. MySQL Workbench..........................................................................................................................40
Voice of Droptica........................................................................................................................................40

Summary..................................................................................................... 41

Droptica.com
 A note from the authors
“The Best practices for software development teams” is an E-book that summarizes over the five years
of experience in software and business development that Droptica has.
It is a compilation of some older and newer texts from our blog available at https://www.droptica.com,
as well as some never previously published content.

There are many myths and misconceptions about working with distributed teams or offshore
agencies. These myths can make it hard for business owners to build a trust and use the services of
said agencies. Unnecessarily.
We wrote this E-book to prove, that working with a team that is spread out over many locations can
be comfortable and pleasant, just like working in a team sitting at a single office. We hope it will be as
useful to you as fun to write it was for us.

Introduction
How to effectively cooperate with a client operating at different time zone?
How to pick the best tools for your agency?
How to create advanced products when the needs of the market are shifting like in kaleidoscope?
Those questions, and many more pop out daily when you are managing a software development team.
At Droptica. We know that figuring it all out is a tough nut to crack.

We are in business since 2013. In this time we managed to create a unique operational model that lets
us to maximize the effects of our work. We are able to adjust to our client’s needs many elements like
the way the project is implemented, managed and ensure the certain standards of communication.
For our clients that means the full control over the progress and costs of their projects. For us, it’s the
efficient way to manage the whole team.

With over five years of experience, we are able to constantly improve our work, so the services we
offer bring real benefits to our customers. The projects we carry out are:

-working
-free of errors
-profitable

What is our recipe for success? We are sharing the best of our pieces of advice for software
development teams and agencies in the form of this handy E-book.

Droptica.com 6
1 Part ONE:
Teamwork makes the
dream work
If you run a software development company, you probably know how hard it could be to organize
all the processes. Especially when you feel overwhelmed because of having too many projects to
manage. Or maybe you have just one project on your mind, but you can’t begin without hiring an
experienced software development team?

Perhaps you should hand over some of your duties to another company.

1.1 How to hand over the project to another

software house
Sometimes you need to say ‘No’, to a client or to the urge to do everything by yourself. Otherwise, it
can be a recipe for failure. Don’t be afraid of giving over a project, as it can really help your business.
Here’s how you can benefit from moving a project to another software house.

1.1.1. How many projects are too many?

It’s obvious that everyone wants to stay ahead of the competitors, so you’re getting excited when
there’s another client on the horizon. What if there will be too many of them? Or if they bring in
complex projects to be made?

Did you ever:

• felt that you are unable to provide the manpower to finish all the work you are involved in?
• felt overwhelmed by the complexity of the project?
• noticed that communication lines are so long they resemble more the game of Chinese Whispers

Droptica.com 8
 than an effective exchange of thoughts?
• wished that looking for the right solution wouldn’t take more time than implementing it?

Those are serious warning signs when it comes to ensuring the success of your project. Believe us,
if you lose control over the number of the projects, sooner or later you’ll experience the long-term
damage from juggling too many of them. On the other hand, successful project handover will lead to
present a positive image of your organization and it will improve your reputation.

1.1.2. How to prepare

1.1.2.1. Organize project assets

Before you select the new team for the project, get as much feedback as you can to create a know-
how for another team. Make it transparent for others so they will know what’s the main purpose of the
project and what technology is needed to make it work as expected. Make it clear how the software
development process should look like and what are the unique selling points. Let them know the
target audience and their main expectations and needs. In general, you need to provide sufficient
documentation and information.

When you gather all the information that simplifies understanding the project without making the
new team feel puzzled, it will save a lot of time and money as well. Extensive software documentation
with code standards will make a real change and improve the transition process. Also, you need to
clearly communicate dates, priorities and responsibility allocation. The documentation needs to be
meaningful and coherent to the end users, there’s no time for rewriting the entire specification.

1.1.2.2. Status report

Each stage of the project is filled with a set of activities so it’s easier to define how much work is left
to make it successful. The new team has to understand at what stage the project is in the transition
moment. Some crucial issues to focus on are:

• What has been already done?

• What should be done in the coming weeks?
• What are the unique challenges of developing this particular software and how your team has
managed (or failed) to deal with them?
• What difficulties are expected to lie ahead and what would be the best way to deal with them
based on the previous experience?
• What are the priorities assigned to the tasks? Are there any tasks that need immediate attention?

Keep everyone in the loop and share software changes (software changelog) with the new team. Give
them the list of the files included and create a handy guide for them to make installing software in a
new environment much easier. Also, provide them with a list of all dependencies that are required to
run the software.

Moreover, don’t forget about the list of detected bugs, as it really helps to make the transition process
smoother and less painful.

Droptica.com 9
1.1.2.3. Deployment pipelines

How the software works is one thing, but what’s also important is how the team is organized and who is
responsible for a certain part of the project. You need to clearly define roles and assign responsibilities
for maximum productivity. It will be much easier for a new team to group people with similar skills to
get the work done.

To make the things easier, give them a detailed explanation on your in-house workflows. What
processes were implemented to achieve results this far? How is the team managed? Don’t keep it for
yourself if you want them to do their job right.

1.1.2.4 Maintain control

The last and the most important stage of the transition process is the overlap period. This is the time
when the new software house is taking over the project, so it’s good to work together for some time
to make sure that the new team fully understand the project and knows what’s the next stage of the
development process. This can speed up the onboarding process, for sure.

When there’s more than one project manager, addressing tasks successfully can be a bit difficult,
so it’s good to work together to make sure that priorities are clear for both sides. It’s much easier to
achieve through face to face communication, so synchronize iterations and make sure that the new
team will successfully manage the project.

But how to pick the best team?

1.2. Software outsourcing - how to find the best

team?
Outsourcing software can bring about many benefits, including reduced cost, access to the specific
experience or might just fill a void of specialists on your market.

Choosing the right team for the job is not an easy process. It makes sense to look for the right one,
rather than to hire the cheapest or the first one you find. With the right team, you will be able to
mitigate many risks that come from hiring external outsourcing provider, like cultural mismatch,
communication issues or lack of motivation and deliver your project much quicker and at a reduced
cost.

Drupal is fantastic for all sorts of websites and applications. That’s why we’ll use it as a main example
here. The points mentioned below, however, are valid also for any sorts of software development tools.

There are a few critical elements you should consider when you are looking for to outsource a software
project.

Droptica.com 10
1.2.1 The matter of experience
It takes time to master Drupal. If you are building a large application, it is good to have at least one
really experienced developer/software architect (three or more years of working with Drupal), who
delivered in that time a few sizeable projects. This person will work as your architect and gatekeeper.
Planning architecture, choosing contrib modules and code reviews and helping others would be his
daily routine.

The rest of the team also should have had at least some experience in using Drupal, unless you have
time to train them. Drupal 8 is a bit easier to pick up by a developer who previously worked with an
MVC framework like Symfony or Laravel, but it is still quite far from allowing Drupal newbies to just
joining in and coding. Six months for smaller to 1-2 years in larger applications would be a proper
exposure.

The time needed to pick up other software development tools may vary. On the other hand, it won’t
hurt to have someone really experienced on board when the very complex project appears on your
radar.

1.2.2. Has the team worked together?

This one is not that critical, but having a team that uses similar tools and standards goes a long way
towards ensuring that your application is built smoothly. Teams assembled “for one project” tend to do
much poorlier than ones that had time to iron out their cooperation practices.

You can circumvent many of the issues stemming from a distributed by a well-established automation
of the software development process. It is though, and so much easier to introduce it if all devs are
already used to it.

Droptica.com 11
1.2.3. Cut communication lines
How will you communicate with the team? Ensure there will be a clear and easy communication
between you and all the team members directly. There is nothing worse on a project than long
communication channels that distort information and extend communication time.

1.2.4. Check availability and scalability

Can the team scale if needed? Often projects start small but then grow larger and require more
resources. Will the team be able to increase in size or will you have to look for additional people?

The other side of the coin is turnover. An average turnover rate in a software company is about 10-20%.
If your team consists of 5 people for a project that lasts a year, it is almost certain that someone will
leave. Is the team able to provide a replacement that can start quickly?

1.2.5. Build trust

Can you build trust? On a long project, it is essential to build a trustworthy relationship between you
and the team. If you feel there are any issues or ambiguous situations, it is better to clear them all
before the project begins.

1.2.6. Access to specialist knowledge

If you hire a team of developers, it is also worth exploring if they will provide you easy access to
other services or expertise that might come handy on the project now and then. On a typical Drupal
assignment, you may have some tasks that might require:

• a DevOps specialist (e.g., setting up environments, servers or CI infrastructure)

• UX/design specialists
• Quality assurance (testers) who can perform manual or write automated tests of your application

When you have chosen your team, it’s time to set the project up. If you prepared everything according
to what we wrote in chapter 1.1, work on a software project shall already be organized so that delivery
can run smoothly, even if there are multiple independent teams involved.
But what if client change his mind?

1.3. How to communicate with your customers.

Picture this: You’ve got the chance to build a great project and did a lot of work already but the
customer starts complaining which ends up in having to rebuild it from the very start. This means you
have twice as much work and that the customer would probably never work with you again. And all of
this is a cost of poor communication. See the point?

Good communication with customers is one of the most important things when managing the

Droptica.com 12
software development teams. It’s not only about listening to customers’ needs and expectations, but
it also creates your brand reputation. No matter whether you have expertise and skills set of PHP, Java
or Drupal — without the communication, you’ll be perceived as a person difficult to deal with, which
equals missed opportunities.

1.3.1 Communicate directly

Do you remember the Chinese whispers, also known as the Broken telephone? It’s a children’s game
tDo you remember the Chinese whispers, also known as the Broken telephone? It’s a children’s game
that makes kids stand in a straight line and pass around the message. The children whisper the given
word or phrase to the person standing next to them. They just need to pass the message but it usually
comes with making audition errors so the last person receives a different version of the original phrase.

Funny, right? And now think about it in regard to the business communication. As you can see, the
more people involved, the harder the communication becomes because each person hears and
communicates a different version of the original phrase.

Now think about your customer that has specific expectations and there are a few people between
you and the customer. What if they interpret information in different ways? If you’re responsible for the
project, consider speaking to your customer directly, without intermediaries.
Before making a deal with your customer, determine which communication channels you’ll use to
discuss the project. It’s good to set it up beforehand to avoid confusion in the future. Sometimes, when
you see that it could be difficult to communicate directly with your potential client, perhaps it’s better
to pass on the deal. In the long run, it can be better for your brand reputation.

1.3.2. Ask before making assumption

A client gave you full specification and you proceed the work, even if you have some comments on the

Droptica.com 13
project, because ‘a client is always right.’ You don’t want to be perceived as a person who complains a
lot so you simply adapt. Could it be the biggest mistake you made?

One thing that should always be implemented every time when you communicate with customers is
to verify the list of features provided. It helps better understand the real needs of your client and saves
you time when you start working on a project. A professional web developer always helps customers
create a specification that fits their needs best.

Ignoring even small things from the very start could turn into big problems in the end. As you can
guess, it’s better to spend some extra time before you start working on a project to make sure that
both you and your client has a similar way of thinking about the final product.

The easiest way to achieve the state, when you don’t have to make assumptions and your client is well
informed is to make him a part of the process. Yes, nobody likes being controlled at work, it’s not that
easy to focus when you always have someone behind your back.

However, it’s better to keep a client close to the project to make them know how the product looks at
each stage. It’s much easier to make some changes during the development process than to the final
product that you’ve been working for such a long time on. Keep in mind that the more time you spend
fixing issues for one customer, the less time you have for new assignments. So you lose money twice.
When your client is in the process, it ensures your team that everything goes as planned. It’s also easier
to explain the process to a client, maintain control of what is important and what is not, and leave no
doubts in their mind.

If you don’t address all the issues of the project at the beginning, a few weeks of your hard work could
be thrown away because the final project could turn out as a non-functional product. After all, you’ll
be the person responsible for the issues, not your client. This is why asking questions and reporting
doubts it important, even if it doesn’t go hand in hand with the client’s vision. When you see that the
client requests features that are unnecessary or that there are some functionalities missing, don’t
hesitate to share your thoughts with them. Explain thoroughly why you recommend making these
changes. It positions you as an expert and shows your experience in a specified field.

1.3.3. Explain things effectively

To avoid any misunderstandings, ask your client to give you as much descriptive information about the
final product as possible. Let them speak in their own words to make it easier for both of you. This will
lead to creating a specification without unnecessary buzzwords and terms wrongly used by a client.
When the client tries to use professional terms but confuses their meanings, ask questions that could
be helpful. Ask for describing the idea using simple words and create a list to verify it later with a client.
You’ll be surprised how simple questions could work wonders. Moreover, the client will see you as
much more polite person.

1.3.4 Be patient, professional, polite

People don’t like when their arguments are questioned or when someone tries to prove them wrong.
Even if the list of features needs a makeover, communicate it to your client the right way. Tell them
that you like what you see but have some doubts regarding the final products. Show the client that the

Droptica.com 14
features proposed could affect the functionality of the ready-made product and suggest the changes.

The thing is to find a way to convince the client that their vision needs small changes to create the
product they expect. Don’t try to be pushy or arrogant, just give them strong arguments based on
your experience. It’s not that easy and you need practice before you’re able to get it the right way.
Sometimes it takes years of practice, but it’s definitely worth it. Once you learn how to communicate
with customers, you will end up having many satisfied customer base that will be recommending you
to their friends.

Voice of Droptica
Maciej Łukiański, Co-owner of Droptica:

“What is most surprising and saddening to me is how difficult to our clients is to buy good
software and reach assumed results.

Once we had a client that already have tried to make his system twice, using different
technology and with help of two different contractors. After three years of work and
tremendous costs, he was still at square one with the software that wasn’t working
properly, not to mention meeting his expectations.

We managed to build the system he desired. Thanks to it he is now able to develop his
business and lead in the market”

1.4. Models of cooperation of the development

team and the client based on the examples used
at Droptica
Effective communication is a very important part of cooperation with your client, but not the one and
only.

Droptica helps clients from all over the world to complete and implement their projects. Each of these
clients has already developed their way of working. Everyone is different. We always want to maximise
the results of our work, so our development team always adjusts and adapts their way of working to the
client’s needs.

The elements that are adapted and changed the most often include:

• project implementation methods (Scrum, Kanban, etc.);

• number of people in the team;
• roles in the team (backend developers, frontend developers, QA, UX/UI, etc.);
• the method of communication; Tools: JIRA, Slack, telephone or video calls, meetings;
• the frequency of communications;

Droptica.com 15
• communication channels (who, with whom);
• implementation standards (some clients consider application performance to be the most
important, others focus on implementing and providing new functionalities on a regular basis,
while another group focuses on aesthetics and want their application to look good).

On the basis of these factors, there are many models of cooperation with clients possible to form.
Below there are some examples we use at Droptica.

1.4.1. Model 1: Product Owner at the client, with the rest of the team at own
company
This is probably the most popular model employed at Droptica. We use it mainly when the end client
comes to us. In most cases, the client already has a web system based on Drupal, Symfony or React
and needs developers to develop the system further. Product Owner has a vision of application
development and looks for a team that can efficiently perform the envisioned tasks.

In this model, we have a great impact on the development of the system. Our team not only performs
assigned programming tasks but also proposes directions for development of the system and suggests
improvements. In addition to developing basic functionalities, we also design user interfaces (UX/UI)
and often carry out A/B tests that show us the best solutions for the client.

Voice of Client

We use this model to develop WydawnictwoWAM.pl website. This

is what the client has to say about us and about working in this
model:

“We established cooperation with Droptica around two years ago to develop our online
store available at http://www.wydawnictwowam.pl. Both the quality of all the works
carried out, as well as our cooperation were stellar. The technical solutions suggested and
implemented by Droptica were a great help and often improved the value of our system,
often exceeding our initial expectations. Cooperation with Droptica is characterised by
very friendly, direct and precise communication on their part. Thanks to that, we were –
and constantly are – able to define and detail all the tasks related to the development of
our sales platform. We also appreciate their very clear settlement system, which allows
us to better plan and allocate funds for development. In other words, we definitely
recommend working with Droptica”.

1.4.2. Product Owner, QA, PM on the client’s side, software developers

provided by own company
In this model, we provide our customers with solid development support. Most of the project
planning and management process is carried out by the client, while our experts carry out specific

Droptica.com 16
development tasks. It is a kind of cooperation that we usually go for with large companies and
corporations, expanding their Drupal, PHP, and ReactJS teams. As a rule, in such a model we work on
servers and project management systems provided by the client. We adapt to their processes.

1.4.3. Mixed models

Other models are usually combinations of the two models presented above. For example, Droptica
provides not only developers but also testers, while the entire project is managed by the client. We
also sometimes work on projects where we collaborate with other software developers from the
client’s company, working not as an independent development team, but a part of a larger team.

We are flexible regarding the form of cooperation with our clients. However, not to lie here, we like the
first model the most. In that model, we take on a great deal of responsibility for the project and we are
able to influence the direction of development together with the client. This gives us great satisfaction,
and we offer numerous ideas for improving the system, which allows our clients to better achieve their
business goals.

Droptica.com 17
 Voice of Droptica
Grzegorz Bartman, Co-owner of Droptica:

“A good code is a very important thing in our business, but to create it, both the client
and the vendor have to find a common language before. I’ve seen some projects before
developed by a few good programmers but the communication was failing at the same
time. Those projects finished with huge delays or costs much higher than assumed... Or
hadn’t finished at all.

To me, at the beginning of each project it is necessary to:

Discuss the matters face to face or at video chat. The whole developing team (not only
programmers, but whole Scrum team) and representatives of client (Product Owner and
other people ordering and interested in developing the software) should be present at the
conversation.
Set the standards of communication in the issue tracking system and other channels. In
Droptica we use additionally Slack and Google Meets applications.
Set the standards of conversations, i.e. the frequency. The conversations, either face to
face or video-chats should be held at least biweekly.

Those elements should be a part of every project. Without them, it’s almost too easy to fail
to meet the client’s needs.
Some people might think that holding meetings as such may be a waste of the time and
money. In the long term however, it equals huge savings. I can say it for sure after more
than 10 years of experience with creating commercial IT projects.”

Droptica.com 18
 2 Part TWO:
Effective software delivery
After implementing Scrum at Droptica, we observed outstanding results in terms of the quality
of our projects. In our opinion, Scrum not only helps with maintaining quality – it simply enforces
it. It puts emphasis on testing as early as possible. Writing good code that can be developed
becomes a necessity. It supports automatic testing and automation of the development process.
It reduces unnecessary costs and increases business flexibility. How does Scrum do it and what
the heck it’s in the first place?

2.1. How does Scrum improve software

development quality?
In Scrum, like other agile methodologies, there is a lot of emphasis on quality. But does it really help in
improving quality? We hope that the following arguments will convince you that this is the case.

2.1.1. Definition of quality

Let’s start from the scratch. If we asked a large group of people what they associated with the quality
of the project, we would certainly get many answers. Personally, we like Joseph Phillips’ definition the
most, since he believes that “quality is the potential of a project to meet the requirements expected
and defined by the client. Quality is an asset, a value and a source of profit drawn from the proper
implementation of the project.”

This statement may be quite general, but it boils down to a simple thing – good quality software should
do exactly what the client and end user expect of it. We can extend these definitions and say that
quality software should not do anything unexpected, either.

2.1.2. What is Scrum?

Many books have been written on Scrum, but we’ll try to be brief here. Scrum is an iterative and
incremental way of running a project, based on the principles contained in the Agile manifesto, that is:

• Individuals and interactions over processes and tools.

• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

If you would like to learn more about Scrum, I would recommend reading The Scrum Guide” by Jeff
Sutherland and Ken Schwaber. We’ll also explain more further in the book.

2.1.3. Frequency of release

One of the most characteristic things in Scrum, is that the project is divided into sprints (from weekly
to maximum monthly periods), which end with delivering a working piece of code.

Droptica.com 20
2.1.3.1 Requirements: consultation and good code

Imagine that you are writing poor quality code. After a number of releases, the technological debt
starts to grow higher and higher, to the point that maintaining such an architecture will start to be an
obstacle to further development – you can be sure that your client won’t be happy about that. The
Scrum model requires you to write a code that is easy to maintain and develop.

However, such a situation probably won’t happen. Daily meetings of the development team, including
testers, support communication within the team. If a bug is found, the entire team is aware of it and
can react quickly, before technological debt pile up.

And do you remember the lesson from the first part of the book, the one about asking before the
assumptions? In Scrum, not only does the team have to communicate with each other – it is also
necessary to talk to the customer’s representative (Product Owner). This is important because the
team not only informs them about the progress of their work but also gets answers regarding any
ambiguities and doubts, for example about how a specific function should work.

Also, Scrum is often called the art of maximising work not done. You maximise the rejection of the
tasks that are unnecessary from the point of view of your business. You do only the things that bring
particular value to the system. Everything else goes straight to the waste bin.

Of course, the client usually speaks the business language, while the developers speak technical, but
our experience shows that during subsequent meetings, they start to communicate better and better.
This eliminates cases in which the developers have to guess how the system is supposed to work and
cases in which the client would like to know something about the progress of the work but doesn’t
know whom to ask.

Droptica.com 21
2.1.4. Tests from the beginning of the project
At the end of each period, there needs to be a version that can be deployed and shown to the
end user. This requires testing from the very first sprint and as early as possible in order to be able
to present a proven solution for the customer. This changes the role of a tester, who is no longer a
bouncer who stands at the final gate and rejects ugly solutions. Instead, they become a player in
the development team, whom he helps in ensuring the quality of the project. Testers cease to be a
separate role, instead, they are a part of one team that pursues the final goal of a given sprint before it
ends.

Even during sprint planning, testers’ perspective on the project and their understanding of how the
system will behave in certain situations can be really useful.

Another interesting solution may be writing tests even before the code is created, forcing the testers to
think about use cases and ask about the ones that the developer could not predict when developing a
given feature.

2.1.4.1 Benefits: less costly mistakes, fast response, quick reaction

In the traditional business model, the development team is provided with a specification, according
to which the project is developed. It is easy to imagine a case in which a well-prepared specification
is used to develop a project that is fully compliant with all the requirements listed there. The
development takes six months and after that, it is presented to the end user, who hates everything that
the designers came up with. It would seem that the quality of the delivered project is excellent since
it was consistent with what the customer wanted; however, the market won’t remember this as one of
your successes.

In Scrum, at the end of each sprint, we provide a working feature which – if the customer wants – can
be implemented and shown to the end user. Thanks to that, if we go in the wrong direction, we lose
one sprint’s worth of work at most.

Droptica.com 22
What’s more, we try to deliver versions of the projects that are ready to be deployed and shown to the
end user as often as possible. This allows us to test our business concepts faster than in the traditional
methods and start reaping the benefits of them earlier.
The same applies to the changes that the market is imposing on us. Since our project must be created
in a way that makes it easier to modify, we can quickly adapt our project to new conditions.

Let’s always try to think about good quality in the context of your projects, and your customers will
certainly appreciate that approach. All in all the motto of the Gucci family is: “Quality is remembered
long after the price is forgotten”. This is not supposed to say that only expensive projects are good –
the point of this is to remind you of the fact that if you do not take care of the quality of the project, your
users will not be quick to forget it.

2.2. Remote scrum team

But is Scrum any good for remote teams? All that is needed is an experience in technology and
working in agile teams.

2.2.1 Why choose remote scrum team?

Introduction of the Scrum method in Droptica solved most of the problems. Which ones exactly?
Here are the two most important of them:

• The client was not regularly informed about the progress of works, which means the client was not
satisfied. Sprints, review, backlog refinement – all this compels a constant contact with the client
even located really far away from any our offices.
• The tasks were not thought through before starting them, therefore they took a long time to finish.
And again, the client was not satisfied. Backlog refinement and planning – these events ensure
that the team has to really ponder on completing each task. We’ve already mentioned the benefits
coming from this approach.

Want to squeeze more from Scrum? Hire remote Scrum team. Why? Exactly, what is the difference
between a remote team and a local team? Actually – just their location. If you can have a local team, it
is worth choosing this option. It will be more convenient.

However, in today’s IT market it is difficult to complete a team of 2, 3 or more specialists in a short time
for a larger project. That is why you should think about a Scrum team experienced in working with a
remote client. By expanding the options to the whole world, you have more choices.

2.2.2. Monitoring of the work

How can I monitor what a team thousands of miles away is doing? Scrum has a way to do it: Sprint
Burndown Chart. It is a chart that is updated daily. It shows the regular pace of project development.
It shows whether the team implements the sprint plan. It is the best tool for monitoring the progress of
works. Using traditional software development methods, you usually find out about delays at the end of
a larger stage. With Scrum, the client can check every day what progress the team has made. They can

Droptica.com 23
be sure that the team works and delivers consecutive parts of the software.

2.2.3. So many meetings!

There are more duties of product owner than checking if everything is on schedule. Planning the
sprint, daily Scrum, retro, review, backlog refinement. The list of meetings is long. There is no doubt
that they take time. The client often expects to pay for programming, not for conversations and
meetings.

We used to think the same way. However, after a test implementation of Scrum in one of our own
internal projects, we have changed our minds. Now if it is only possible, we all want to develop all our
projects – for clients and internal – using Scrum. We see that it saves a great amount of time, money
and unnecessary emotional baggage. The same can be confirmed by the clients with whom we now
work using Scrum, while we did not have a specific way of working before.

Abraham Lincoln once said, “If I had eight hours to chop down a tree, I’d spend six sharpening my
axe.”

The meetings guarantee a good rethinking of tasks, sticking to a common direction and pursuing the
same business goals. It is definitely worth it, especially when dealing with remote clients.
If you are not sure if Scrum will work for you, test it. Order two or three sprints and see what results you
will get. It is a small cost within the scale of projects taking several months, and such an approach will
provide an unambiguous answer to the question whether it is worth using Scrum.

Droptica.com 24
 Voice of Droptica
Paweł Szymański, Drupal developer says:

I appreciate Scrum very much.

It is obvious that when you start the work in the new place, it’s sometimes though at the
beginning to warm up to new responsibilities.
I worked before in the company which introduced some elements of Scrum, like the Daily
Stand Up to discuss the issues. However, it’s Droptica that let me fully appreciate how
much programmer’s job can be improved with full Scrum methodology implemented. It
works for both experienced and fresh developers.

Firstly, I work at the team, and the whole team is responsible for the outcomes. This means
that I constantly have some support from other people who know the project, for whom
my task is a priority (because it’s also their task) and who are able to help me or take over
some parts of said task if it more time-consuming than it looked before.
In example, each day we hold a meeting called The Daily Stand up. Its purpose is to
discuss what has been done the previous day, what shall be done this day and if there are
any problems. There’s always someone who points out possible bugs, reasons of delays
or stresses nuances of the task, i.e. “Please notice that the client wished to have this
functionality also on the subpages of the service”.

Secondly, other people in the team are doing similar tasks. It’s a good basis for
comparison, am I doing this task so long because I am at some kind of dead-end with too
little experience or it is just more time consuming than we expected?Another thing is that
each of the teammates knows the project and client’s wishes. This alone lets us take over
the tasks of the absent programmer or explain the state of the project to a client. We just
extensively practised this during holiday season :)

To sum up, Scrum to me is a system of interlinked elements that speed up effective

onboarding for the new person in the team.

2.3. Why do we automate software

development?
At Droptica, we are definitely enthusiastic supporters of automation. As we already mentioned
before, quality is one of the principles that we uphold. We want to create the best software, in line
with our clients’ requirements – efficient, error-free and cost-effective. One of the most crucial factors
impacting the quality of the software that we develop is automation of the software development
process.

Over the course of the last years, we’ve had many opportunities to work with multiple clients on

Droptica.com 25
various projects, collaborating with diverse teams. We have always lobbied for the highest degree
of automation and getting as close as possible to Continuous Integration, often saving projects from
grave consequences.

Before we move on to the benefits of automation, we’re going to provide you with a short summary of
the way it works.

2.3.1 Characteristics of automated software development process

The automated software development process is characterised by the following characteristics:

1. A single common code repository is put in place. All developers place the code they write in the
repository. Currently, Git is the most popular version control system used as a repository. The
code in the repository is the sole source of software in the project. There are no additional scripts,
programs or other code sent by e-mail or distributed in the company in any other way.
2. There is the so-called “build process” in place. The build process is a standardised method for
creating and building subsequent software copies. Every developer, tester, testing script and
mechanism uses the exact same process for obtaining the current version of the software.
3. The build process is automated. Obtaining the current version of the software does not require
anybody to perform numerous manual actions. In an ideal situation, the build process is another
script or a piece of software, which is also versioned in the code repository. The developer then
downloads the latest code from the repository, starts the build process (for example by starting a
script) and obtains the current state of the application. The same script should be used by all the
testing tools and testing environments, as well as for building demo versions.
4. The build process is fast. Building the software takes a short time, which allows for testing the
results and implementing fixes multiple times.
5. The team commits changes often, every day or several times per day at best. The working code is
pushed to the master branch in the version control system on an ongoing basis.
6. The testing environment should resemble the production environment as closely as possible. In an
ideal situation, it would be a direct copy of a production environment.

Droptica.com 26
7. The process of pushing software to production is automated. In the best case scenario, pushing
new changes to production should be done by clicking a single button or running a single script.

In other words, build automation can be boiled down to few points:

• “You know where you stand” – you can have a certain degree of certainty regarding the current
state of your software.
• Everyone works on the same version.
• There is a single and objective way to check whether something works or not.

This alone can spare you the fate of many teams that waste a large amount of time on checking
why something worked in one environment, only to fail when deployed to another one, or trying to
replicate errors from the testing environment in a development or a local one.

2.3.2. Automatic testing

Automated building is just half the success. Testing is the other half.
Today’s software is very complex, often comprising hundreds of thousands of lines of code spread
across many files. Such complex projects use numerous libraries and other dependencies. Changes in
code and libraries tend to affect multiple functionalities in the system.

When implementing changes, software developers usually checks whether the code works as
intended. However, more often than not, they don’t have the knowledge or the ability to check
whether their changes affect other functionalities of the system they are working on. The same applies
to testers – they are simply unable to check the entire system for errors which could have snuck in
when testing new functionalities.

When there is no automated testing in place, teams deal with preventing errors from being deployed

Droptica.com 27
to production by testing all the software before it’s deployed; however, this is a Sisyphean task. Every
error that is found and subsequently patched requires changes in the codebase, which means testing
the entire system from scratch. Often, using such practices causes a long spiral of tests, errors, more
tests, more new errors... Or, to make matters worse, sloppy testing resulting in errors being pushed to
production.
This issue can be solved by implementing automated testing. There are many methods of creating
tests and software testing, which is why we’re not going to list them here, just describe the required
characteristics:

• Tests should be automated, and they should be easy to run. Every developer should be able to run
all the tests in their development environment.
• Tests should be quick because otherwise they might be skipped due to them taking a long time
to complete. Tests should be done every single time when the software is changed. In an ideal
situation, each commit would be tested, but you should definitely test at least every piece of code
to be pushed to the master branch.
• Tests should cover the largest possible scope of the software. The number of tests and the way
they are planned should enable testing all the crucial and significant functions of the software,
and the team should be certain that the fact that all tests completed successfully means that the
software works properly. There are many techniques for estimating test coverage, which can be
used to control the number of tests.
• Tests should be a part of the build. In an ideal situation, every build should automatically launch all
the tests and display their results.
• Every change should be checked by testing the entire system. Again, in an ideal situation you
would test every single commit, but often it’s enough to test the code before merging it with the
master branch. When a developer updates the master branch with code that breaks the software,
they hinder the work of other people who want to start working on a new task using the latest build
– it simply won’t work due to errors in code. Teams that do not use automated testing often face an
issue where some new commit breaks a part of the software and everybody who wanted to work
on it are stalled until the error is fixed. Automated testing prevents such situations.

2.3.3. Benefits of automation

When you automate the building process, along with testing, you will end up with a mechanism by
which you always know the state of your software. What is important, before adding any new changes,
you can check whether or not they introduce new errors. Thanks to that, you can almost always decide
to deploy the current version of the software to production. What is more, you can do it quickly and
safely because it will be done by an automated process, which was tested beforehand in a testing
environment, which is identical to production.

By achieving this level of automation, you can safely develop new functionalities, knowing that they
surely work and don’t break anything, and then deploy your software. Basically, you eliminate the risk
of breaking something, and if you find any error, you can fix it quickly.

Droptica.com 28
 Voice of Droptica
Michał Potasiak, tester says:

In my career, I met with a lot of different kind of mistakes. From minor typos to gaps that
made it possible to circumvent the payment system or access data to an unauthorized
user. However, the most bizarre and the most difficult to handle later are errors that occur
only on the test environment.

If the error occurs everywhere, most often there is not such a big issue. It is known, that
something’s wrong and needs to be improved. Resistance occurs, when software on the
local environment of the programmer is working correctly, and with us the same sequence
always ends in a mistake.

In our organization, this problem was partially eliminated by the docker, which always
builds the same set of containers on the test environment as on local environments.

An additional security measure for testers is a paragraph the social contract of the project
stating, that if the error occurs on the test environment, it is necessary to eliminate it before
closing the task, even in the case when the error is not on developer environments.

2.4. Sprint Retrospective meetings - the way to

continuous improvement of work
Your development team constantly makes the same mistakes and does not improve the quality of its
Your development team constantly makes the same mistakes and does not improve the quality of its
work. Sometimes constant monitoring of the pace of project development and even automation of
process are not enough to ensure the quality of software and fluency of work. Are you familiar with this
issue?

If so, we have a solution for you and it’s really simple – it’s called Sprint Retrospective. We’ve already
mentioned it briefly earlier in the book. We are going to elaborate more on this topic, as it is a really
important part of our work. And should be of yours too!

2.4.1 What is Sprint Retrospective?

This is one of the meetings in the Scrum methodology. The meeting takes place on a regular basis, at
the end of each sprint. At Droptica, for most of the projects, we hold a meeting once every two weeks.
During the meeting, the development team analyses the previous sprints and deliberates about what
can still be improved – how to eliminate errors and blockers, and how to speed up work.

2.4.2. Benefits for the client

The meeting usually takes no more than 15-60 minutes. A Sprint Retrospective usually has anywhere

Droptica.com 29
from three to six participants, depending on the size of the team carrying out the given project. Other
companies might implement this process in another way, shape or form. It’s easy to calculate that this
meeting can cost the client at least several man-hours. Is it worth it? Yes – without question! During
each meeting, the team proposes improvements and agrees to implement some of them starting
with the next sprint. In many cases, these improvements reduce the lead time. The change meeting
is held once, and the improvement is applied continuously throughout the subsequent sprints. After a
number of sprints, we can achieve pretty sizeable time and money savings.

2.4.3. How to prepare for sprint retro?

We like to keep things simple, so for this purpose, we use a Google Docs – Spreadsheet shared to
everyone included in the project. For on-site teams, simple sheet of paper should be enough. It is
important not to throw it right away after the meeting, though.
There are five columns in the document:

1. Date;
2. DROP – what we should stop doing;
3. KEEP – what we should keep doing;
4. IMPROVE – what needs to be improved;
5. ADD – what needs to be added.

During the meeting, each person proposes various improvements that they would like to see and
suggests what should be removed, corrected, added, and so on. Once everyone has spoken, the
team chooses which of the proposals they want to implement with the next sprint. We try to choose
1-3 suggestions and implement them, to avoid making too big changes. We also identify the change

Droptica.com 30
owner, who is responsible for implementing the specific change.

2.4.4. Examples of improvements we introduced

Below, you can find a list of selected improvements suggested throughout several of our projects.
We would like to point out that we managed to implement the agile methodology to many of our
branches, not only software development. We did it to standardize our processes for all the company.
There were obviously things that needed to be smoothed out - and sprint retrospections were just the
right tool to achieve it.

2.4.4.1. DevOps and software development

• We run automated tests more often in order to squish all bugs faster. This allows us to avoid
unpleasant surprises a minute before the deployment;
• We will improve the speed of building a new version of the website on the test server by reducing
the database size by about 90%;
• Before we start working on a task, we talk about business goals, as well as carrying out the
tasks from the software development standpoint in order to maintain consistency of the whole
application and to choose solutions that are optimal for the project;
• Code review should be carried out by at least two people;
• We use git-flow and each task is carried out on its own branch. All tests and code reviews are done
on this branch. After these are carried out, we merge the branch with the main development
branch.

2.4.4.2. Marketing

• After a few sprints, we decided that the full Scrum methodology isn’t quite what we needed to
manage our marketing process. We moved to an Agile methodology with elements of Scrum.

Droptica.com 31
 One of the elements we keep is sprint retrospective;
• We shortened the two-week sprint to one week, to react and adapt to current conditions even
faster;
• We separated repetitive tasks, ad hoc tasks, and The Big Projects. Each of parts now have a unique
workflow settled at the beginning;
• The Big Projects now always have one person responsible for completing all the tasks. This person
reports progress made to the product owner, divides the tasks and oversees the whole process.
The person acting as a “chairman’ for one project may have less responsibility in another one, so all
the work is divided among the team evenly.

2.4.4.3. Overall work organisation

• Every day we send a short message to the client (Product Owner) on Slack with a summary of what
we have done since yesterday and what we are going to do today;
• We break up the tasks in Jira into smaller ones, so that one task takes no longer than 3-4 hours. We
can then better follow the progress of the work and quickly react to delays;
• If during a sprint it turns out that the task is more difficult than we had anticipated, we change the
Story Points for the task;
• We continuously update our documentation. We adhere to the principle that if a question is asked
at least twice, it should be added to the documentation;
• The computer used for video calls must always be connected to the Internet with an Ethernet
cable – this removes the annoyance of dropped and lagging video calls;
• In many projects, we have also removed the deployment from the DoD (definition of done - a set
of rules that define completion of the task for every person engaged). Usually, these deployments
take place once every two weeks or once a month, sometimes even on the client’s side. When we
have a weekly sprint, this should not block us from closing the task.
• Planning with taking support into consideration – on the basis of previous sprints we know how
much time we spend on things that cannot be planned (for example hotfixes added by the client);

At Droptica, Scrum retrospective gave us some tangible effects. We highly recommend this way
to objectively look back into the past to every team, even if they do not use Scrum in project
management (like our marketing team currently do!). You can simply schedule a 1-2-hour meeting in
the calendar once every two weeks and talk about what can be improved.

Scrum retrospective, when combined with previously discussed tools and methods creates a really
powerful way to efficiently deliver working, bug-free software. You can achieve pretty significant
results in just a few weeks. Try it for yourself!

Droptica.com 32
3 Part THREE:
Sharpen your tools
 3.1. With the right tools, working with a team
that is spread out over many locations can be
comfortable and pleasant.
At Droptica, remote work is something ordinary. From the very first day, we had two offices in Wrocław
and Gdańsk. Recently, we also opened our third office in Rzeszów. Every day, developers, testers,
graphic designers and other specialists work together in each of these locations. In addition, 90% of
our clients come from abroad, like in the case of most software houses. Throughout several years, we
have developed methods of effective and efficient cooperation in a dispersed team. We are constantly
improving our work model, testing new tools and ways of working. Tools mentioned below are what
currently works for us the best.

3.1.1. Project management tools

Since the beginning of Droptica’s existence, we have been using Redmine. Redmine had several
add-ons, including Backlogs module supporting work in the Scrum model. These days, we are using
Jira, since it works even better with Scrum. Both systems help us to control what is going on with the
projects. Each of the projects is divided into sprints, and each sprint is divided further into specific
tasks. All information about the realization of every task is saved and stored in Jira. Our clients also
have access to our Jira for full transparency.

In our opinion, such a system is a necessity. Without it, it would be difficult, if not impossible, to control
what is going on with the project, especially in the case of projects running for many months. E-mail
communication is completely unsuitable for this purpose. The market offers many possibilities, some
of them free or offering options that can be adjusted to almost any business, so all you need is to do
some research and find the most suitable project management tool for your company.

Droptica.com 34
3.1.2. Two communication speeds
Project management support systems are very useful, but not sufficient for efficient implementation of
the project. Members of the team must be able to communicate comfortably and quickly. If the team
works in one office, it is enough to just talk to somebody and ask. In the case of a dispersed team, this
issue becomes quite complex.

3.1.2.1.Text chat
Writing an e-mail or adding a ticket in Jira to ask a quick question takes time. Most often, you have to
do the following:

• open Jira;
• find a project;
• find the right task;
• add a comment;
• check in a while if there is an answer;

This process often takes far more time than simply asking the question and getting an answer,
especially when it’s a “yes/no” type of question.

At Droptica, we solve this problem by communicating using Slack. Thanks to this application, our
distributed team works as if all the members were located in one office. We communicate quickly and
efficiently, eliminating unnecessary communication routes. The number of comments to tasks in Jira
also goes way down, making it easier to analyse the status of work on a given task.

We set up several channels for each project. Channels are used to eliminate as many notifications and
as much communication via e-mails as possible and to split up messages thematically.

Most often, we set up the following chat channels:

• projectname chat – a channel for internal communication regarding the project. This channel is
used by the entire development team, as well as project support team (DevOps, testers, etc.);
• projectname client - a channel available to the client and the development team. This channel is a
place for communicating with the client, asking quick questions about tasks, setting up meeting
dates, calls, etc;
• channels with notifications from the systems used in connection with a given project, such as
Jira, Jenkins, GitHub, Bitbucket, etc. Usually, each system gets its own channel. Every person
can join channels that are important for them and eliminate notifications that are not important or
redundant, for example, a graphic designer does not need to read GitHub notifications.

Before Slack, we used group chats on Skype, then we moved on to HipChat for a while. We found
Slack to be the best solution that fits our needs perfectly. It is also important that our clients often
already use Slack, which makes it easy for them to join our channels as another organisation.

Droptica.com 35
3.1.2.2. E-mail, Phone call, Video chat

There are situations where an explanation on Slack or Jira would take too much time. Elaborate issues
may be hard to describe, but easy to show on shared screen or explain on the phone. We tend to turn
to good old tools: phone calls and video chats and emails with some bigger attachments. We use the
whole spectrum of Google products:

• emails
• calendars(to schedule meetings)
• Google Drive (to collaborate on documents like this one)
• Google Meets (former Hangouts). This one is used mostly for shorter video chats like daily scrum
meetings.

For the convenience of our clients, we also use Skype For Business, Zoom and other forms of contact,
whichever the client prefers.

3.1.3. Important quality assurance elements

We’ve already had written about how important at our work is to ensure the quality. Most of the
previously mentioned tools and practices, like Scrum retrospective, can be introduced in any kind of
team, remote or on-site. Below are some more that in our opinion are especially useful for the remote
teams.

3.1.3.1. Daily Scrum

There is no Scrum without Daily Scrum. In a dispersed team, it is necessary to conduct a video
conference once a day. Sometimes such calls are also attended by the representative of the client,

Droptica.com 36
who is often hundreds or thousands of miles away from our offices. We conduct these meetings using
several tools, depending on the preferences of the team or our client.

3.1.3.2. Code Review

We review the code on GitHub or Bitbucket, depending on the project. These systems allow to easily
browse the code and add comments to selected script lines. There is no need for one person to come
to the other person’s desk to view the quality of the code.

3.1.4. Good practices

Working according to Scrum methodology forces us to constantly improve communication within the
development team and between the client and the team. It’s not possible to rely only on emails, so all
the abovementioned methods are necessary to better understand each other. Everyday, we hold the
Daily Scrum meeting in the form of a video chat. We also often have video calls with customers, for
example during the Sprint Review or during the Backlog Refinement. Every once in a while, we also
meet with the client at our office or we pay them a visit.

It is also important for the communication process to work in a way that does not disturb others too
often. Slack is a very useful tool, but it can also lead to too many unnecessary messages, which can be
distracting and interrupt work. We disagree it’s Slack’s fault. It’s rather how it’s managed. It’s similar to
having the entire team working in one office. It certainly makes communication much easier. However,
it also has its drawbacks – for example, it makes it much easier to disturb somebody while working with
unnecessary discussions. Sometimes this can reduce productivity. The team should be aware of this
and use Slack only when necessary and send messages only to those who need them. We try to never
involve people whose presence is unnecessary in a given case.

At Droptica we combine remote work with office work, which enables us to take advantage of both
models. If necessary, we build teams working at just one office.
More than one location gives us a competitive advantage because we have access to more specialists
from three cities and their general areas. This allows us to build great development teams for our
clients.

The fact that Droptica has multiple offices also forces all of our team members to learn how to work
remotely. That’s why all of our experts know how to work with a remote client right away.

3.2. Ideal IDE and Linux configuration for work

with PHP and Drupal
The projects implemented by Droptica require a large amount of coding in PHP. Taking advantage of
various tool and configurations allows us to streamline the process and make it far more convenient
and pleasant. At the end of this E-book, we wanted to share our experiences and describe an ideal
software configuration for coding in PHP (mainly in Drupal) from our standpoint at Droptica.

Droptica.com 37
3.2.1. IDEal IDE
Most of the time at work we spent writing code (PHP, CSS/SASS, JS HTML). In the last years we tested
various IDEs. Initially, we used Netbeans and Eclipse, then we moved to Sublime with plugins for PHP
and Drupal. However, since 2015 we use PHPStorm. In our opinion, this is currently the best IDE for
PHP on the market. It is not free but the cost is quickly made up for in achieved productivity. It has a
30-day trial so can be easily tried out.

There are also some additional PHPStorm configuration options, which make your work easier by
automatically formatting your code according to the accepted standards:

1. Automatically adding an empty line at the end of the file when saving:
Settings > Editor > General, select Ensure line feed at file end on Save
2. Automatically removing white spaces at the end of the lines when saving the file.
Settings > Editor > General, Strip trailing spaces on Save, select ‘All’.
You can also choose ‘Modified Lines’ if you do not want white spaces to be removed from other
places in the code, which were not modified.
3. Automatically formatting the code after typing in the closing curly bracket.
4. Settings > Editor > General > Smart Keys, select Reformat block on typing ‘}’

3.2.2. Docker, Nginx proxy for Docker, docker-drupal

Many web developers prefer installing a full LAMP stack on their local server, with Apache/MySQL
and PHP installed on top of Linux. This is not a bad solution, but such a local installation is always
going to be different from the client’s server environment. And in this case, the more differences, the
more work and potential conflicts you will face, along with the “works for me” responses. For a long
time, we got away with just LAMP. As time passed, projects we worked on were getting more and
more complex and needed additional software and services to work. This made working on multiple
projects at the same time more difficult.

Docker helped us solve this problem. It allows you to run identical server configurations in both
development and production environments. However, the most crucial advantage of Docker is the
fact that the developer is no longer required to manually configure all the .conf and .ini files. Each
project has its own environment encapsulated in containers and a developer can have multiple
projects running locally without interference.

As great as Docker is however it is not too user-friendly. At Droptica, we use a custom piece of software
called docker-console, which allows our developers to quickly start a new or existing project in Drupal.
Tools such as Composer, Drush, Sass/Compass are in their containers and they work without the need
to install them locally on a developer’s machine. Usually, they also have a range of tools for making
debugging easier at their disposal. One of such tools is Mailcatcher, which catches all the emails sent
by Drupal.

That was already great but we still encountered drawbacks. To manage this we created Docker-Drupal
( https://github.com/droptica/docker-drupal) - an application which helps us with development. After
installing it, you have access to a docker-drupal command. This command uses our ‘development’
docker image which attaches itself to the environment and can execute commands for you.
Depending on a project we often add additional elements, as it is easily extensible.

Droptica.com 38
Since the introduction of docker-drupal, starting on a new project in Droptica usually requires cloning
the repository and running “drocker-drupal up && drocker-drupal build” and after a few minutes a
new fully working website is available for the developer in an environment identical to the one in
production with all the services in the same versions.

One of the most useful docker images is the nginx proxy image that allows for using hosts (local
domains) in order to display websites running on Docker in a web browser. In short, thanks to nginx
proxy, we can type in http://www.droptica.dev instead of an IP address (for example: “172.17.0.4”.)
Nginx proxy is very useful when we are running a Drupal multisite and there are multiple domains
under a single container’s IP address (e.g. sites/droptica.com, sites/droptica.pl).

Voice of Droptica
Michał Potasiak, tester says:

When I joined Droptica, we didn’t have a tool to automate the tests and the issue was still
discussed. Fascinated by Selenium, I thought it could be a good idea to introduce it as a
standard for our projects. I got off to a rocky start, as I struggled with the technology. After
a crucible, I managed to set up a working environment that had been “magically” clicking
through “something” and checking the website in my place.

About the same time, Droptica adopted Docker in our projects. I’ve been very skeptical
at first. After all, I went for so much trouble just to set the tests right, and suddenly there is
not only the new thing to get the grasp of, but also a need to set the working environment
from the scratch. However, I decided to embrace the situation and use it to make my
working experience better. Selenium is a very handy tool, but honestly, most of the
solutions one can find on the Internet are referring to Java or Python.

That’s how I discovered Codeception. It appeared to be a perfect solution to my

problems. I can still create tests using webdriver, and additionally, I have access to faster
tests with phpbrowser and unit tests. The last thing left was to create a new configuration.
Droptica developers stepped in and helped me to do it right for the first time. Today,
adding the tests to the project is much easier and takes no more than 15 minutes of work,
and “properly tested code” speaks volumes.

3.2.3. PHP CodeSniffer

PHP CodeSniffer is a very useful tool, which helps you maintain clear codebase, conforming to
standards. As you can read in the Readme file, CodeSniffer is made up of two scripts. One is used
for detecting violations of a defined coding standard (phpcs), and the other is used to automatically
correct coding standard violations (phpcbf).

PHPStorm, however, only allows you to use the former one (phpcs). After configuration, all the lines

Droptica.com 39
containing code violating the standard will be highlighted in the currently edited file.
In order to be able to use PHP CS, you have to install it first, for example by using Composer or in any
other way described in the project’s readme file.

3.2.4. XDebug
XDebug enables debugging web applications developed in PHP in a “classic” style, using breakpoints
and running code line-by-line. XDebug is fully compatible with PHPStorm, and connecting the IDE to
the debugger is very simple, regardless of whether you use docker or set up the entire environment
all by yourself. A very good and in-depth manual regarding connecting XDebug and PHPStorm is
available at PHPStorm’s web page. Moreover, there are many plug-ins made for Chrome and Firefox
browsers available, just install it, enable it for a given page and enjoy the possibilities offered by
XDebug.

3.2.5. MySQL Workbench

A piece of software for managing MySQL databases. It allows you to import and export databases,
view tables, as well as query databases, regardless of whether they are local, in docker or remote via
ssh. It does not have any limits regarding the size of an imported database (compared to the default
PHPMyAdmin configuration).

It is possible that in the future we will find better options. They are different now from what we
recommended a year or two ago, and they will probably be different in the future – the configuration
will get even better.

We understand that the change of habits and tools we are accustomed to may be hard, confusing,
maybe even expensive at first. However, it’s not as costly as letting the competitors outpace us with
better software.

Voice of Droptica
Grzegorz Pietrzak, developer says:

The most important thing in creating software is that you have limitless possibilities. The
code is like a magic canvas. When you use it - ideas from your imagination come into the
real world. There are no boundaries.

But the most important lesson you learn as a developer is how to write good code and
share it with others. It is where the world of opportunities open to you. If you know how to
contribute to a team, your ideas become a part of something bigger. Something that you
can call a perfect software.

Droptica.com 40
Summary
We all know that change happens whether we are ready for it or not. Moreover, it’s not only a constant,
but the rate of change accelerates continuously. Innovations, technology, competitors, and market
forces continue to intensify.
Like many companies, we can choose to let that change overcome us...

...or we can embrace and leverage change to achieve a higher good.

The very survival of organizations depends on its workforce’s ability to adapt to an ever-changing
customer’s demands. Picking the right tools, framework and communication routes are basics when it
comes to creating the elasticity needed in today’s software development market.

We shared some of Droptica’s secrets with you in the hope this little drop in the whole digital ocean
will help to shape the current market into the place offering more opportunities for both customers
and software development teams.
We have some more tips and tricks at our sleeves.
Follow our blog and social media to learn them all.

Thank you for the reading!

Droptica Team

Droptica.com 41
 [email protected]

Follow us at:

/Droptica /Droptica @Droptica

UL. DUŃSKA 9 UL. BUDOWLANYCH 64D UL. WARSZAWSKA 18

54-427 WROCŁAW 80-298 GDAŃSK 35-205 RZESZÓW

www.droptica.com
Droptica.com