OmbuLabs Blog

Let’s deep-dive into what happens on the first day of a Design Sprint. On Mondays, we understand the problem.

I want to give credit to the creators of the Design Sprint method, Jake Knapp, John Zeratsky, and Braden Kowitz from Google Ventures who developed this Design Thinking method in the mid 2010s. Their process is the starting point from which all variations of Design Sprints come from, and I work with their framework to create Design Sprints that are customized to suit client needs.

Just before the world shut down in 2020, the team at OmbuLabs participated in an in-person retreat in Punta Cana. It was a wonderful experience, and the team was eager to have another retreat in 2021. We even began planning one, but with the safety of team members at risk because of the pandemic and the difficulty of traveling it soon became obvious that an in-person retreat would not be possible. Therefore we turned our attention to having the retreat virtually.

This ended up being a very successful event, and we wanted to share the experience and strategies that we used to plan and execute this retreat which took place virtually over four days towards the end of 2021.

One of the main goals we set for 2021 is to become more efficient as an agile team. And one of the challenges we addressed was how to minimize the decision-making bottleneck. To confront that we decided to take some actions that I’m listing below.

At OmbuLabs our goal is always to smooth processes, and make work easier. Isn’t that what software engineering is really all about in the first place?

When we are getting ready to do a project or to make a proposal one of the questions that we are always asked by clients is “how long will it take”? To come up with an estimate on timing we like to use a system of points and blind estimates by multiple team members to find an average of how complex the project will be. We can then use this information, together with our database of delivered projects, to estimate how long the project will take.

To accomplish this, and make the process smoother we built a tool called Points and now we have moved it to open source in case it can be of use to any other teams out there!

As a distributed, remote team we use different tools to communicate at OmbuLabs, like Slack and Zoom. Those are great for live communication. But every company has information that needs to be kept and stored somewhere. In our case, we started off using the GitHub Wiki and Google Docs. However, documentation and policies need to be maintained, updated and checked regularly. And having information scattered in different tools, formats and accounts became a hassle.

That’s where a knowledge base comes in. At OmbuLabs we use Tettra and we will share our experience in a different article. But regardless of what tool you choose, here are some practices that will help you keep your knowledge base organized and updated.

As a remote team, we work and communicate asynchronously a lot of the time. Additionally, as a software agency, we work not only on client projects but also internal projects related to various aspects of the company. This means we will have stories and pull requests opened accross different internal projects at all times and it is important that everyone is on the same page when it comes to what needs their attention and what the next steps are.

We have shared more information on how we use Pivotal Tracker here. We also like to use GitHub to its full potential. Therefore, we needed a standardized workflow that would take into account how we use both these tools and ensure everybody on the team knows what is going on by looking at a Pivotal Tracker board or a list of open Pull Requests.

In this article, I will walk you through the workflow we created for our team. You can find a flowchart representation of the workflow here.

Remote work is a growing reality. In the 21st century, we have distributed companies that work 100% remotely, with team members scattered around the world.

While remote work has its benefits - diversity in background and experiences, access to an immense talent pool, cut down office costs to name a few - it also brings its challenges. And the biggest one is communication.

There are several pieces of software that aim to facilitate communication in a remote work environment. At OmbuLabs, we use Slack for our day-to-day conversations and Zoom for our calls. However, as a remote team, we don’t get to meet our teammates face to face. We don’t have “water cooler” chats or as many opportunities for casual chats as an office environment.

So how can we bring our team closer together? How can we build that team spirit that comes from seeing everyone and talking about our casual, social lives? Well, last month we had a team retreat. And it was great.

At OmbuLabs, we strongly believe in continuous improvement.

As a Scrum team, before starting a sprint we estimate the complexity of the stories using the Fibonacci scale. But how do we become better at estimating stories? How do we know we’re evolving as a team?

In this article I outline the process we are following to become better estimators.

When a new team member comes onboard, there are several tools and resources they need to access, as well as processes, practices and guidelines they need to be aware of. There is also workflow and company culture information you want to communicate. After all, each company has its unique features and you want new team members to be comfortable with the existing team.

For remote teams, this process can be very challenging. Thankfully, if you use Slack, you can use their Workflows feature to easily onboard new team members, making the process actionable and easy to follow.

In this article I’ll describe how I used Slack Workflows to make the onboarding process here at OmbuLabs quick and easy.

Different clients bring different projects, perspectives, workflows, and experiences, as well as different challenges. Before starting a project, one of those challenges is to define who will be the Product Owner.

Ideally, you would be able to assign the role internally or to the client based solely on the characteristics of the project. However, that’s not always the case. It might just be that the client insists on being the Product Owner or that you are a small team and can’t really assign the role internally. Whatever the reason, you might end up in a situation where your client isn’t really a good Product Owner.

Here I’ll share some strategies we implement to help our clients become better Product Owners and ensure the best experience for them and for our team.

We have been a fully remote company for a year and a half now. Making the transition to being fully remote can be challenging for any team. During the past year and a half we have worked on making sure that our team is as productive, communicative and social as it was when we had a traditional office space. Here are some tips that we have found to be useful for remote teams:

Pull Requests let developers tell other team members about changes they’ve made to a project repository. Once a pull request is created, team members can review the set of changes, discuss potential modifications and even push follow-up commits before the changes are merged into the repository. Therefore, it is important to make sure that your pull requests are easily understandable to the reviewers.

Sprint Retrospectives are a crucial part of our project management strategy at OmbuLabs. Because we are a remote and international team of software developers, we miss out on the “water-cooler” conversations and small talk that would normally occur between employees in a typical office environment.

At OmbuLabs, we like to split our time between working on our own products, open source and client projects.

Our own products include everything from OmbuShop, an e-commerce platform, to FastRuby.io, a Ruby on Rails upgrade service. In terms of open source, we recently created Audit Tool and are constantly searching for more projects to contribute to. We also work on a variety of interesting client projects, and with our current team size, like to take on two to three of them at a time.

As an Account Manager, it can get hectic trying to manage all of this. Google Calendar can be a serious help.

At OmbuLabs, we have a number of tools that help us to keep organized, write better code and communicate more effectively with our clients.

When starting a new software development project with a client, it is important to get started on the right foot. The way you communicate with a client at the beginning of a project can set the tone for how communication will be throughout the project.

Therefore, at OmbuLabs, we believe it is crucial to start off every new project with a Kickoff Call, where we can take time to get to know the client’s team and speak in depth about their goals and priorities for the project. We like to discuss the following list of topics with clients during our calls:

We like to use GitHub to its full potential at OmbuLabs, so any tool we add to the toolset needs to integrate nicely with it. As a growing agency working in larger and increasingly more complex projects, we need a project management tool that allows us to keep track of our work and plan accordingly. For this, we use Pivotal Tracker.

There are many things that are easier with Pivotal Tracker, as long as you are using it the right way. Some of its features are very useful for agile teams like ours. This is how we like to use it to ship value with every sprint and keep track of our team velocity.

There are a few agile practices that I really love. Pair programming is one of them.

We try to do it as much as possible at OmbuLabs. We usually keep the sessions under two hours and try to follow a regular schedule.

When we find ourselves blocked by a code problem, we use our daily scrum to coordinate a pairing session. It’s quite a step up from rubberducking or using a cardboard programmer to find a solution to a problem.

The Joys

As a Senior developer, I find that pairing sessions are great for coaching Junior developers. I enjoy teaching them about best practices, design patterns, frameworks, languages, code style, XP, and TDD.

From the point of view of a Junior developer, I believe it’s a great opportunity to learn from someone who “has been there before”. When you program with someone with more experience, you will often learn about design patterns, elegant object-oriented solutions, tips and tricks.