Launched a New Website Working as a Distributed Team

At UruIT, we are all about distributed teams. Of course, as a nearshore development company, we have to stand for this form of work and create the best environment for boosting our remote teams’ capabilities. Our main goal is to deliver high-quality software development services to our US clients. So, instead of being an obstacle, working remote is often an opportunity.

As we put our money where our mouth is, we also form distributed teams internally to tackle projects for our own needs in Uruguay, like for marketing, for example. Actually, since April, I’ve been part of a distributed team experience for redesigning UruIT’s website (that you can see right now, we’re live!). 

As the marketer responsible for this project, I spent the last few months working side by side with a Product Owner, developers, designers, and other types of roles for building our brand new website. Part of the team was based in our offices in Uruguay and part of it was remote. Some team members worked 100% remotely. At the same time, others would come to the office occasionally for meetings or work hours and some were here at all times.

In this blog post, I’d like to share more about this project. You will read about our challenges, and tips for finding success with a distributed team, based on our experience.

 

 

uruit.com: a new approach for an old project

I joined UruIT at the beginning of 2017. Since then, the idea has been floated around to redesign our website. However, it wasn’t until this year that we were able to set up a team to handle the project from start to finish. Historically, we managed the website with in-house talent, people interested in joining the team and/or that was not assigned to a client project. Since our #1 priority as a company is to make sure our clients are well attended, our designers and developers never quite had the full availability to work on our website. If you are a marketer in a similar company, I bet you know the drill 😀 

But in 2019, we decided to assemble a dedicated team for our own website. This team would be composed of our “on the bench” talent and temporary consultants in order to accelerate time to market and meet deadlines. Our main requirement was that team members should be available for communication during office hours. Although the team configuration changed over time, this was the most stable team we’d built for this project in what seemed like ages:

The team

• On our side: myself, the marketing team representative, the Product Owner, and technical leaders from development and design who validated the consultants’ work and guided them on how to follow our branding and coding practices.
• On the remote side: a consulting designer and developer(s) from companies that we knew and trusted.

To organize ourselves, we decided to follow the Agile practices that are a part of UruIT’s culture. We started the project with a story mapping activity for identifying a common goal and our vision for the website. Later on, we prioritized and defined what functionalities to tackle on the first release and which ones we would work on in the future. Afterwards, we used a Trello board for keeping up with the project’s roadmap and the backlog of functionalities to develop each sprint.

Then, Scrum was our main choice for moving the process forward. We had weekly planning and review meetings, daily checkpoints, and occasionally, refinement instances and retrospective meetings. Those last two were particularly useful for dealing with some of the issues I’ll explain shortly, such as the team configuration changing over time. For making sure the whole team was connected, we relied on tools such as Slack for day-to-day communication and Zoom for video conferencing. 

Fortunately, the team atmosphere was very positive. In our final Retro, everyone said they enjoyed and felt comfortable working with each other. I particularly felt like it was a pleasant environment. Over these months, I was able to learn more than ever!

 

 

Nevertheless, some challenges came up, and this is how we faced them:

A team composition in flux

Historically, the internal team in the past that was dedicated to our site changed often. People got more or less busy, priorities shifted, new projects appeared, etc. In order to foster stability for this re-design project, we decided that two UruITers would dedicate a specific chunk of their time to this project exclusively. That meant the Product Owner and me! As the two UruITers with the greatest bandwidth to lead this project, we aimed at maintaining our internal knowledge and supporting new team members better.

However, other members joined and left the project during its execution, at different times, especially designers and developers. This imbalance sometimes made processes slow. When someone left the team, we experienced a delay as we had to find and onboard a replacement. As a result, the project’s different areas weren’t moving forward at the same pace. Sometimes there were many new designs and not enough developers to act on them or vice versa.

To manage this constantly changing environment, first of all, we hired consultants that committed themselves to be available during office hours. That way, the whole team could be in touch throughout most of the day. The Scrum ceremonies were ideal moments for integrating team members, clearing up any doubts, and setting the project’s tone.

In addition, when design got behind, the development team used its spare time to improve the code, work on the infrastructure, test, fix bugs, and more. When the situation changed and we had several interfaces to implement and little development capacity, the team got together to plan how we could incorporate more developers on demand. During the whole process, we also evolved our focus on the priorities. We put a lot of effort on refinement, making stories smaller, more specific, and easier to tackle.

Different work styles

Although we had ceremonies, not everyone that was part of this distributed team experience had incorporated Agile practices such as prioritizing the most important things and focusing on generating valuable and working software from day one. For us at UruIT, this work methodology is present all the time. When we start a project, we prefer to create a small functionality that fulfills its purpose and then evolve from there. However, as the web project had such a diverse team, with professionals that were not used to our own work culture, we had trouble sticking to it. For instance, sometimes we spent more time and resources than we should have on aspects of the website that weren’t as important.

Our Product Owner was key in this process. She helped us steer our efforts in the best direction for fulfilling the product’s goals. The PO reminded us constantly of the importance of following the plan and focusing on the most important features. She was also the one who led the stories refinement, helping developers to better visualize the required tasks according to the project’s priorities. 

Transparency issues

Transparency is an important value inside an Agile environment and sometimes we were lacking in it. We had moments in which not everyone was sure of what the others were working on. 

What helped us manage these situations was having open talks with the whole team to clarify concerns. By putting the problem on the table and inviting everyone to participate in the discussion, we owned the responsibility of finding solutions. When we all agreed on incorporating a rule or changing something, everyone was fully onboard to do their part and improve things. 

As an example, sometimes we’d end a sprint with a lot of stories to review. However, a story that’s almost finished is not a completed one. In order to expand on this and make the team aware of the importance of closing the planned stories for each sprint, we had meetings for evaluating things.

What is a reasonable story that anyone could start and finish within our 1-week sprint? Do we need to split this story that’s in progress into two so we can release a more valuable part?

By having these discussions, we gained visibility into the real progress. Therefore, we could accelerate our work, generating features of value and improving our control over the roadmap.

Last-minute work

We planned a lot, but, as they inevitably do, difficulties arose last minute. As you can imagine, after the previous redesign in 2015, the website had a lot of particularities that we didn’t know from the beginning. Some examples are pages that weren’t visible and an extensive redirect list to tackle. Also, we underestimated parts of the website’s migration to a new hosting provider and how it affected related platforms, such as the company’s blog.

As a result, urgent tasks sometimes came up that made the team have to stop what they were doing in order to solve them. In these cases, we counted on the help of other consultants who had specific knowledge in subjects such as WordPress and SEO. Thinking back, it would have been better to include those guys from day one and plan things ahead of time.

In other cases, the team adjusted the work and had enough flexibility for incorporating the most important tasks. To do so, we communicated the need as soon as possible and adapted our plans. Or, we’d put our foot down and let go of things that showed up out of nowhere, in order to keep up with the plan. It wasn’t always easy to make these decisions, but our main criteria was to maintain the hard release date. If the task meant we would have to delay the website’s launch, we added it to our Backlog for re-prioritizing it in future releases.

A distributed team experience

These are some of our learning points and ideas for improving the management of a distributed team experience. Our website is a work in progress and we’re just starting the next release. So, if you have any suggestions, let us know! Also, if you feel this post could be useful to other remote teams, do share! Hope we all can create a connected and efficient work environment – regardless of where we are!