Category Archives: Agile

As TangoSource’s role description says, web designers are architects of the web. They focus on the look and feel of the website; and so, they should be visual arts experts, who are skilled in color scheming, graphic design, UX and information flow. However, this is just a glance at the whole knowledge baggage that a web designer should own and dominate in order to create good and effective web solutions.

The web design process is not a linear path, but a convergence of multiple disciplines, techniques, and methodologies, which have to adapt to every project’s needs, whilst keeping up with the new technologies coming up every day. It involves and integrates several disciplines as Information Architecture, SEO, User Experience Design, User Interface Design, Graphic Design, Product Design, User Centered Design, and Front-End Development, to mention some of them.

However, many of the sources I’ve reached on the internet address web design just as development’s initial step, before starting to write the code. This development method approach is called Waterfall, in which every step leads to the next one, and every part of the team works separately and sequentially.

The Waterfall method starts with a project plan. Before any part of web development can begin, designers must have a clear vision of the final product in mind. The planning stage is upfront and quite extensive, but one of Waterfall’s benefits is that most of the times, web developers can accurately estimate the timetable and budget for a project.

This workflow approach was the most popular one until a couple of decades ago. And it certainly has its benefits, but one of its disadvantages is its lack of flexibility, as it doesn’t allow an open communication with the client and the rest of the team throughout the process. In many of the cases, if any part of the initial design changes, the team has to rethink the whole project.

Waterfall Model

During my recent experience working at TangoSource, I’ve had the opportunity to work with the Scrum Framework, one of the web development Agile Methodologies approaches which work through iterative, incremental cycles. It allows designers, developers, project managers and stakeholders to actively participate in the whole process, encouraging an open communication through it. Something to always keep in mind is that getting feedback from different perspectives is really valuable, as you gain team and customer insights for a faster testing and ideation.

In other words, in an Agile environment, the phases run parallel instead of following each other, as in Waterfall methodology. This way, design, development, and testing all occur at the same time, as the product is divided into smaller and independent parts, called Sprints. These Sprints can be individually released, according to the continuously evolving requirements and solutions, defined by the project’s needs. This also speeds up the feedback process and mistakes come to light, making bugs easier to identify and reducing time and money waste. Sounds idyllic, right?

Agile Model

These principles constitute the basis of the Lean Startup Mindset, known as the 3 step process: Build, Measure, Learn Feedback Loop. This infinite informational loop gives business the opportunity to create, launch, learn and iterate on new and old products, and it works as follows:

Build – Create a Minimum Viable Product (MVP) based on a set of assumptions.

Learn – Accept or reject your initial hypothesis and iterate on the MVP.

Build Measure Learn Loop

The essence of the Lean Startup Methodology consists of helping reduce time and risks associated with launching a new product to the market, by taking advantage of the efficient use of resources, and continuously testing said product for market risk. This is done by guaranteeing user’s interest before building the solution and testing for initial user engagement while continuing working on improving the solution to an identified problem.

As we have seen, Lean Startup Mindset and Agile Methodology share some principles and adapt them to their own techniques. This doesn’t mean that you have to choose one over another, but you can rather take from each one the tools that best fit you since they have their own way to add value to your own process.

“As a designer, making the transition from freelancer to working within a big company with multiple teams on Agile projects, can be a big leap. In my experience, it is a useful framework to work within and its principles can even be used in your own personal projects.”

– Joel

If you’ve heard about the term ‘Agile Design’, it is simply the application of some of the agile development principles to the design process. One of this flexible framework advantages is that it can be easily adapted, according to different workflows, teams, and projects needs.

On the other hand, the incremental cycles approach can present some difficulties on the design end. One of the risks that a web designer might face while working with iterative processes, is potentially finding visual style inconsistencies between the early stages of the project and the final outcome. Especially, if there wasn’t a document defining the style guidelines from the beginning.

For this matter, defining a style guide is one of the best ways to ensure visual consistency. A style guide is an equivalent of creating a development documentation in which every project’s guideline is promptly defined. This guarantees us focusing every effort in the right direction and avoiding style incongruities during the whole process, or whenever future development or third-party production intervenes.

“The Agile approach of Continuous Integration is reflected in the use of style guides, because creating content first and then using it to build a flexible framework reflects the iterative and cyclical nature of Agile development. The iterative format comes from the ability to experiment, test and tweak the way the coded elements are used in a layout.”

– Luke Clum

If you want to dive a little more into this, Tom Greever has given us nine valuable Principles Of Design Implementation, which perfectly adapt to the iterative process design essence, and on which every design team can base to create their own style documentation.

These days, you can find several different tools out there to help you ensure not only visual consistency but also responsiveness and cross-browser functionalities. A great resource to use is the website styleguides.io, where you can find articles, books, and some other tools to help you as a starting point in your extensive quest.

Being aware of design principles is crucial for an effective digital communication, and therefore, a successful product. But it is also important to understand that visuals don’t construct the whole design, but just a part of it. There always has to be a solid communicative speech on which design decisions can rely.

“Web design — and really, design in general — is all about finding the right balance between form and function. You need to use the right fonts, colors, and design motifs. But the way people navigate and experience your site is just as important.”

– Matt Meazey

Certainly, there’s more than one way to do things, but there is one main focus which has to remain as the center of our thinking process: creating real solutions for digital communication. Innovation is a plus. Always remember that as every project and team is different, you’re best off choosing the methods that work for you, and adapting them on the road.

Some people underestimate sprint retrospective meetings and think of it as simply the time when a sprint ends and they can move on to what’s coming next week. But in reality, this meeting provides an opportunity for the team to identify relevant action items to improve their performance. This is the moment where the team can meet and examine each other’s performance for the sake of the project. It’s also an opportunity to update and improve the team’s definition of done.

There are many ways to lead a retrospective meeting. I’ll share with you what has worked for us.

At the beginning of each meeting

Make the purpose of the meeting clear for everyone. If this is the team’s first retrospective meeting, it’s important to define how it will work and mention the rules. The Scrum Master (as moderator) should make sure that everyone has their say.

A brief summary…

Refresh everyone’s memories about what happened during the sprint that just ended. Offer a brief summary of the most important events of the ending sprint. You could also merge this part with the next section (the brainstorming part). The team can share their ideas and opinions while the Scrum Master tells them about the most important events that occurred during the last sprint. In this way, they could express their thoughts while remembering the events.

Brainstorming

This is when the team refers to tasks that went well, could have been done better or went simply bad. Those three areas can be called differently depending on your approach, we personally use:

Start doing

Continue doing

Stop doing

The areas could be tools and methods, communication, working styles, processes, etc.

In my experience, people can lack the confidence to be straightforward and say what they really think about an issue. The Scrum Master should try to elicit their thoughts and help them express themselves. Tact is important here. You need to choose the right words to avoid being offensive when referring to the way that people do certain things. Being indirect can also help, by talking about the issue and not the person who caused it.

Room for improvement

It is important to have action items for every identified issue. And the Scrum Master should make sure that she follows up on each of those. Some people suggest focusing on only a couple action items per sprint.

Closing the meeting

Here is where the Scrum Master gives a brief summary of what was achieved during the meeting. Thank everyone for their time and energy invested in this important event. They should reflect on the way the meeting was conducted and find ways to improve it if necessary.

I personally believe that leading a retrospective meeting is part psychology and part engineering. You have to know how to work with people, communicate effectively, and manage communication among the team.

We have developed our own tool to manage retrospective meetings (as well as pointing sessions): TangoSource’s Planning Poker. We invite you to use it and tell us if you find it useful, and if you have any suggestions. You can read more about it in this other post from us. Plus, it’s free!

We also offer Scrum project management consulting, shoot us an email at contact@tangosource.com if you want to hear more.

Thanks for reading! Let me know how your experience has been with retro meetings (and any tips or tricks you might have learned) in the comment section below.

Have you seen a team that doesn’t understand the reason behind developing certain feature? Have you had a sprint review where more than a half of the features are rejected? Or that the team develops a huge feature that doesn’t add any significant value to the product? If you’ve seen this in your project, it might mean that your Product Owner is doing something wrong.

We can consider the Product Owner to be the main stakeholder. She should own the product and determine direction. The reality is that the Product Owner role is different from that of a project manager, since she has the passion, the vision, and, unlike a project manager, has to say no to people. Let me explain.

Saying NO to stakeholders.

On a typical project, the team delivers a certain amount of story points per sprint. But it’s common to see that once stakeholders notice what the team is capable of doing, they start asking for more and more stuff. Imagine that certain project has around ten stakeholders, and each one of them suggests a new idea, which represents, let’s say, two story points. The problem is that the team is only capable of delivering ten story points per sprint, and if we let this situation run out of control, then we will end with an infinite queue of pending work.

The Product Owner is the one in charge of prioritizing the work queue. More than that, he is the one in charge of preventing the creation of that infinite queue of features, and the only way to do it is by saying NO to stakeholders. At least from time to time.

It’s true that the Product Owner must develop a good relationship with the stakeholders, and part of this is helping them decide what should or shouldn’t be part of the product backlog. By having a clear product vision, a well-studied market, and regular interviews with end users, the Product Owner should be able to determine what features are the best for the product.

Saying NO to the current backlog

The business value produced by each feature tells the PO what should be the priority for each story. Let me clarify, when I say value I’m not talking about the size in story points, I talk about the actual ROI of each story.

The Product Owner should be skilled enough to find out the real value of each feature, by studying end-user behavior and market trends. Let me give you an example of that.

“Jim Employee” is part of the marketing department of a graphic design company that sells templates to graphic designers. On a sprint review, Jim proposed to add a small countdown clock right below the daily offer section. The only problem is that his requirement was down the road in the backlog because of the urgent features that the accounting department has requested.

“Mark Product-Owner” decided to support Jim with his idea and he put it at the very beginning of the next sprint. After an (expected) argument with accounting, he stood his ground, and the team developed Jim’s idea.

At the end, that small requirement increased sales, and it wouldn’t have been possible without Mark’s support.

What if one of the stakeholders proposes a simple change to the interface that improves the end product a whole lot? If the stakeholder doesn’t have enough influence and there’s a lot of pending work on the backlog, chances are that the feature could stay in the backlog forever. It is the product owner’s job to support good ideas that have high value.

Saying NO to the Scrum Master.

It is true that the scrum master is the one in charge of making sure that Scrum is followed as intended. However, there is just one person that can say no to the Scrum Master and change a sprint’s path or add features, and that is the Product Owner.

According to Voltaire, “With great power comes great responsibility” and, in this case, that quote applies very well. The Product Owner is the only one that can say no to the Scrum Master, and if she doesn’t use this power wisely the team could end with a useless Scrum implementation.

But, when can a Product Owner interrupt a sprint? There is no rule for this; it depends on the urgency of the requirement. As a rough guideline, I could say that most of the time a sprint can only be interrupted because of the appearance of an urgent bug on the production server. It is the Product Owner and the Scrum Master’s job to exert their judgement and decide when a sprint can be interrupted for the sake of the project’s health. Nonetheless, the Product Owner has the last word.

Saying NO to the team.

It’s the team’s job to think outside-the-box. However if they didn’t have any external boundaries to keep them in check, the product could easily become something different than what the market, users, and the company need and want.

One example of this happened to me when I was Product Owner of a project that started as a small demo to a group of investors. After a few months of work it became a more serious networking application.

On a Sprint Review Meeting, one of the most experienced developers of the team asked me to spend a significant part of the upcoming sprint time on redefining the architecture of the application. He explained to me that the design that we had up to that point didn’t fully support the new requirements, and we had to do it right away.

At that time, we just had one “urgent feature” to develop, so it was easy for me to say yes to that. I wasn’t sure I had made the right decision until some time passed, and the velocity of the team went up. When I asked about what changed, they told me that the new architecture was allowing them to develop things faster.

Later, I received a suggestion from the same developer about moving to a NoSQL database. According to him, that database model offered better compatibility with what the product was becoming. I analyzed the situation, asked for some advice and I decided that it wasn’t a good idea to proceed at that moment with the change. We were far away from launching the product and, even though we were near to the deadline, the improvement on the application’s response time wouldn’t be significant.

In other words, the Product Owner is in charge of making room where the team can experiment with their ideas.

Having a great relationship with everyone.

I’d say that this is the hardest part of the work since this involves a lot of what some people call “soft skills”. It involves leadership, friendliness, persuasion, and more.

The Product Owner must have a good relationship with her team and become the main bearer of the product’s vision. She or he should maintain a good relationship with the Scrum Master since he will help her to mediate difficult situations and will support her with the improvement of the Product Owner’s performance. Finally, she should maintain positive relationships with the stakeholders. They are her customers, investors, and end-users. Without them, the project wouldn’t be possible.

The Product Owner role is a complex one that needs skills and knowledge in professional communication, user experience, and market research. At TangoSource, we have internal Product Owners who act as the eyes and ears of our customers. They are in charge of interviewing the stakeholders, studying the market trends, and defining the features of the project. Ultimately, they’re responsible for the results at the end of the sprint.

Want to know more about how we run Scrum within the company? Drop me a line or follow me on Twitter, I’ll be glad to strike a conversation.

Intro

Are you happy with the app you use to do feature estimation in your Scrum process? We weren’t either. How about the way you collect feedback after a sprint is done? We’ve got you covered.

Introducing Planning Poker: the tool to manage Scrum pointing sessions AND retrospectives in the same place, under an Open Source license, for free! How sweet is that? In this post, we’ll tell you why we built this app, and what were we looking for (spoiler alert: you will see those expectations fulfilled in our app). Then, we’ll show you how it actually works, on a step-by-step tutorial to master the main features. Finally, we’ll refer to the technical stack and the reasons behind choosing those specific technologies. We want to open up a line of communication to receive comments and suggestions for improvement. In the end, this is Open Source, right?

More specifically, in this post we’ll cover the following topics:

Why we built this app

How it works

Pointing sessions

Creating a pointing session

Setting point values

Joining a pointing session

Pointing stories

Statistics

Leaving a pointing session

Retrospective meetings

Creating a session

Joining a session

Adding entries

Editing entries

Deleting entries

Revealing entries

Reviewing entries

Leaving a session

The technical stack we used to build it.

Let’s get started.

Why did we build this app?

Planning Poker was born out of the need to have a fast, simple, and fun tool for the process of estimating the complexity of a feature. At the same time, we needed something to help us manage retrospective meetings. In Planning Poker, the estimation sessions and the retrospectives are carried out in accordance with the Scrum methodology in a distributed environment. We needed an application that kept these processes simple yet flexible, allowing for the addition of custom values if needed. Since we couldn’t find an application that had this exact set of features, we set forth to do it ourselves.

We also wanted to give something back to the community. During our run as a web dev company, we’ve made use of great open source software, and are grateful to the the people who wrote that software. We thought that if we came up with something worth sharing, we would release it under an open source license and return the favor. It was about time that we built and offered something that could make the lives of Scrum teams easier.

So, how does it actually work?

There are two types of users in our application:

Player: These types of users are only allowed to vote, add and modify all of their entries in retrospective sessions. In this way, moderators can have control of the meetings and lead them without interruptions.

Moderator: This is a role commonly used by Scrum Masters. They are allowed to change the description of the story that is being estimated, and clear values to start a new estimation. In retrospective sessions, they are allowed to reveal entries when users finish entering them so that the team can review entries together.

Setting point values:

You will notice that you can modify the description (names) for points. We included this functionality to give users the freedom to choose the scale and the names for the corresponding elements that works best for them. However, we have also included the most popular pointing range, the Fibonacci series, which is set as default. So, if you don’t need to change anything on the scale, you can move on to the next step of the process without delay. Finally, we added two more features to allow players to express that they are not sure about the estimation of a certain story, or that they need to take a break.

It is important to note that the application doesn’t store those values in memory. They are refreshed when a new session is created, and the only person who can modify them is the creator of the session.

Customize point values and labels view

Joining a pointing session:

Once a user creates a session, she can invite the rest of the team by sharing the link or session ID with them. All users will be prompted to choose a username and user type.

To join with a link:

Click link.

Fill username and user type in prompt.

Click “OK”.

Enter username modal joining session

To join with a session ID:

Go to our home page.

Fill username.

Enter session ID in the corresponding field.

Choose user type.

Click “Join”.

Joining a session with an Id

Pointing:

We provide an input to define the description of the story in order to keep all members on the same page. Since the voting process shouldn’t be affected by teammates influencing each other, your vote is secret and you are not allowed to see other teammates’ votes. Accordingly, they won’t see yours until all players are finished voting.

Pointing view

Statistics:

The application displays statistics right after all users have finished voting. Yo’ll be informed of how many players voted the same value. If there was consensus you’ll be notified as well. Votes can’t be changed afterwards.

Pointing Statistics

Leaving a session:

Once your team is finished, you can clear the voting area in order to start pointing a different story. Alternatively, if you have finished your sprint planning, you can just close the browser and the session will be deleted.

Creating a Retrospective session:

This process is very similar to the one for creating a pointing session, except that this time we have to select that we are creating a retrospective session instead.

Enter your username.

Select your user type.

Select retrospective from the session type dropdown menu.

Click “Start”.

Create retrospective session as Moderator

Joining a retrospective session:

Same as if pointing a session: once you create a session, you can invite the rest of the team by sharing the link or session ID with them. All users will be prompted to choose a username and user type as well.

To join with a link:

Click link.

Fill username and user type in prompt.

Click “OK”

To join with a session ID

Go to join session section in the home page.

Fill username and user type in prompt.

Enter session Id.

Click “Join”.

Adding entries:

Once you enter a session you can see three columns like these:

Retrospective view

Click the “+” button on any column.

Write your entry in the box.

Press Enter.

More of column in add entry mode

Writing an entry for More of column

Added entry in More of Column

Editing Entries:

Once you add an entry you are allowed to edit it by clicking on the pencil icon.

Click edit icon.

Modify entry.

Click “OK”.

Editing an entry modal

Deleting Entries:

You are allowed to delete your entries too, just on the trash icon next to the entry.

Revealing entries:

Only moderators are allowed to reveal entries, this will show the content of the entries to all users. You can do it by clicking on the “Reveal” button.

Reviewing entries:

Preview entry in review mode

Once you reveal entries you will be allowed to click on them. That will open a pop up with the text of the entry so you can read the complete entry. There’s an option to mark them as ready or go to the next/previous button.

More of entry marked as read

If you are a moderator, you have the option of showing where you are with the rest of the users in the session. With that, you can make sure that all users are looking at the same thing, reading the same entry.

Show for others option

Leaving a session:

This works exactly the same as pointing sessions. When you finish your retrospective meeting, you can just close the browser and the session will be deleted.

How is it built?

We chose Node.js as the main backend platform for this project. We did this because of its “Event Loop” feature and because it does asynchronous operations, which makes our I/O operations fast. But that’s not all, it also features socket support. As you probably know, websockets are two-way communications between the server and the client via TCP instead of HTTP. This means that you can create powerful real-time applications that can push changes immediately. In our case, this came in handy when displaying user votes.

Using Node.js helped us reduce the number of issues that commonly occur when working with multiple languages. Since we had JavaScript already running on the server and the browser, it just made our lives easier. We also used Angular.js. We chose it mostly because of the ‘data-binding’ benefit. Since we were building an application with real-time output, we needed to keep the UI updated, and Angular.js is perfect for that. We’ve been working with this framework for a while, and it makes our development process faster. Plus:

It’s maintained by a very friendly and highly-skilled community.

It allows for the extension of HTML.

It allows for dependency injection.

We needed to chose a Javascript library to handle websockets, so we went for Socket.io. We did this for these reasons:

It handles browser inconsistencies and varying support levels.

It includes additional features like rooms, which allows for work in different teams/rooms/sessions/channels.

And finally, we included Express.js too. We know there are a lot of new frameworks for Node.js out there, but since reliability is of the highest priorities for us, we had to go for Express.js. It has been available for a couple years now and its community and creators are very active. Besides that, this framework is simple and very flexible, and allowed for scalability.

We hope that you found this post interesting. If you have any questions or comments feel free to leave them on the comments section below. Here’s the link to the project on Github. Have a suggestion or found a bug? Send a pull request and we’ll be happy to take a look. We at TangoSource are constantly looking for new and interesting projects that empower our clients and keep the end-user happy. Have something in mind? Send us an email at info@tangosource.com, we’d love to talk 🙂

… but don’t let that fool you! Working remotely is a double-edged sword.

I have found three main areas you need to take care of if you want to stay productive while working remotely: discipline, communication, and time zones. Keep reading to see why I am saying this, plus some tips that will prevent you from performing poorly. And who knows, perhaps you’ll end up having a better performance working remotely than if working onsite.

Discipline

I remember the first time I worked remotely, it felt awesome! I could start or pause work at any time I wanted. And that feeling of freedom, of being able to go to the kitchen and grab some food, watch some TV if I got bored… it was great. I used to wake up at 9:00am, have breakfast, take a shower, and then start work at 10:00am. At this point I was running an hour late, if we compare it with a typical office schedule.

It didn’t take long before I found myself working the whole day. Starting at 10:00am, making frequent breaks, plus doing all the chores and errands a normal person in his twenties has to do. The result: I ended my work days at 12:00am… I had turned into a slave of the freedom that I had.

The solution

You need to take remote work as seriously as if you were working onsite. Remember, with so much freedom it might not seem like it is the same, but you still have have a job to do!

Obviously, taking breaks once in a while does not hurt, but I recommend you avoid granting yourself too much freedom until you have mastered your procrastinating nature. It’s possible to tell if your impulses are under control after a couple of months of working on it, tracking how successful you have become at achieving your goals. And yes, you read right, it takes months. It has been proved that it takes over 2 months of daily practice to develop and establish a new habit.

If it is very hard for you to be disciplined, there are some tools available out there that could help you keep focused on work. A very popular (and effective) one is the pomodoro technique. This time-management method can help you improve your focus and mental agility. Pomodoro promotes work intervals that last 25 minutes, and are alternated with 5-minute breaks, thus increasing your productivity. I have tried it myself and it works, it structures your work day in a way that makes you spend your time more efficiently.Try it out yourself and see if it brings any positive changes to your productivity.

Communication

When I started working remotely I was in charge of a team of 3 people. As you can imagine, not only was my own performance compromised, but also that of my team and project’s. Unread emails and messages were something I had to deal with every day; slowly but surely this was something that was affecting our work deliveries.

The solution

Remember, when you work remotely, you aren’t really alone. You have co-workers, clients, supervisors and other people you work with. Because of this, it is very important to share your status frequently. You can decide on different strategies with your teammates. These are some I personally prefer:

1. Email at the beginning and at the end of the day. I recommend this specially to improve communication with your client. Generally, they are very busy during the day because they have very tight schedules. A good practice I like keeping is sharing my work plan for the day with the client, using the following Scrum-based format:

What I accomplished since yesterday:

goal 1

goal 2

goal n

What I’m planning to accomplish today:

goal 1

goal 2

goal n

Impediments:

list the stuff that prevented you from achieving a goal

2. Use text messengers appropriately. Use them concisely and only when communicating important stuff to your teammates, you don’t want to interrupt them frequently as you don’t want to be interrupted often either. Here are some examples of things worth communicating and how to do it briefly:

‘A bug appeared in production…’,

‘I finished the feature…’

‘I would like to know the status of…’

Or simply ‘I am leaving!’, so everyone is aware you won’t be available from that moment on.

3. Keep project management tools updated. Some PM tools allow the addition of comments inside stories (also known as tickets). I recommend you to keep your stories updated by adding a comment with an status whenever any of the following happens:

You hit a milestone while building a feature.

You have made progress solving a bug.

You are going to perform a chore.

You are stuck.

This way, the client and your teammates know what’s the progress on that story. You will help others to determine if the committed work is in risk of not being delivered, and you can receive help to speed up your work.

Beware of different time zones

This is perhaps the least harmful of the three, because it does not affect your work directly, but it can be a rock in the shoe. I didn’t know this was going to be a constant pain until I started working remotely. I had to deal with 3 different time zones: our customer was on PST, my co-workers on CST, and I was on EST. I was 3 hours ahead of our customer and 1 from my co-workers, and this brought communication issues. When any of them tried to contact me it was very likely that I had already finished my work day.

The solution

Be sensible when arranging meetings, inform others the time when you usually have lunch. Let them know at least one week in advance if you are going to take days off (including those you take for religious reasons, if that’s your case). It took me about 4 weeks to get used to all time zones and to adjust my personal schedule, sometimes having to move my lunch time an hour earlier or later, but at the end it was worth it.

Other good practices

Here at TangoSource we are proud of our remote work practices. We summarized best practices for remote work on our playbook so that anyone can work remotely effectively. Here are a couple of examples:

Create a daily routine list. This list contains recurring action items that you will be checking at the beginning, during, and at the end of the day. An example of a daily routine is: checking and answering emails at the beginning of the day, check messenger apps during the day, and sharing your status at the end of the day.

Create a weekly routine list. This list contains all action items that you will need to take care of during the week. Example: meetings, days off, deployments to servers, etc. Having this routine will help you to have a well-organized schedule.

The conclusion

It took me four to five months to master the three areas mentioned above. If you’re struggling to deliver results while working remotely, or if you’ve never done it and are afraid to try, well, now you know what to do. Put these ideas in practice, don’t give up, and soon you’ll be ready to work from the Caribbean!

Are you interested in learning more about TangoSource and having us as part of your development team? Shoot us an email! We would absolutely love to hear from you! 🙂