At Colloq, we are three freelancers with a regular project workload. We’re distributed across the globe. This article is about how we now manage to work efficiently on a side-project, and the story of how we got there.
Most of us know that running a side-project can be a daunting and rather difficult task to successfully manage, even and especially on your own. For a project involving three people, all working on client projects in parallel, making progress on a side-project is a challenge. We learned this the hard way, but I’m glad we nearly failed at first.
I have been working with agile project management methodologies for several years now. I have done so in various different teams—on-site and remote—with Scrum and Kanban, as well as in smaller and bigger teams and projects. Some projects were successful, others not so much. The main difference to Colloq is: This is my own project, there’s no external management, it’s all up to ourselves.
Connecting the Remote Team
Let’s start with a key issue of working as a remote team. Our industry often claims how easy it is to work remotely. Everyone is connected via Internet to each other the whole day. Except, in reality I’ve only seen very few remote teams succeeding over time. Many teams go back to on-site teams or shut down as a company. Establishing a successful remote team is exciting but it’s also hard work. A successful remote team requires much more effort than a traditional on-site team.
From the start it was clear that Colloq will work 100% remote. Anselm lives in Iffeldorf near Munich, Germany (UTC+2). Tobias currently lives in Lisbon, Portugal (UTC+1) and tends to change his living place from time to time. Holger lives in Hong Kong (UTC+8), a city that is 11000km away from Lisbon. Holger and Tobias are eight hours apart so when Holger is about to wrap up his day, Tobias is just getting started.
Good communication is key to success in a project. For a team setup like this, we can already see that asynchronous communication is a necessity.
But it’s much better to work on a project together. When you have an immediate question you don’t want to post an issue and wait for a reply; This would be pretty inefficient for the project’s progress.
So right from the start we had a couple of video meetings, to see each other’s faces or to talk to each other in person. This does not only boost motivation to work on the project, it often is the best way to discuss features or to find solutions to important questions. To make these calls work, we make compromises: Tobias gets up a little earlier than usual so Holger doesn’t need to sacrifice his whole evening.
During work days, Anselm occasionally holds Virtual Office meetings with Holger in the morning. On some days, Tobias joins later on before Holger leaves. All our Scrum meetings take place during the European morning so all can attend.
“Let’s do ScrumBan”
When we started to build Colloq in September, we decided that we want to use a mix between Scrum and Kanban. No one of us wanted to have many meetings and we believed that a strict Scrum workflow would hinder our productivity. Instead, we wanted to rather have a sort of Kanban workflow mixed with some elements of Scrum. We wrote tickets, we developed on our platform, and we felt like we made progress. Little did we notice that we weren’t very efficient, let’s not speak about the achieved objective progress. After four months, we reached a point where we admitted to have failed. We hadn’t build anything that was near a stage of release and little of the features we wanted for a first version were ready. This was our tipping point, and very often, this can be the death of a side-project.
Still convinced of our idea, we needed to make some major changes to the way we work on the project. We acknowledged that it doesn’t make sense to treat it as a side-project anymore. Instead, the importance of Colloq would need to be at least equal to client projects to each of us.
Live or Die
In early March I decided to finally take the Scrum Master certification in a 2-day workshop. I chose one with Jeff Sutherland, the “co-founder of Scrum”, as the instructor. This course gave me a lot more insight into real-world Scrum implementations, and showed me insights on how to deal with uncommon issues. And I rediscovered the potential of what Scrum can do, if applied correctly, to a team.
After that, we decided to give a strict Scrum workflow a chance. We transformed our workflow from ‘undefined and loose’ towards a pretty clearly defined one, strictly following the Scrum principles. We agreed that any customisation at the beginning of the Scrum project could be a potential issue, so we avoided it at all cost. This change turned out to be one of the best decisions we made. Now that we understand ourselves better as team, we are starting to evolve our workflows.
At the tipping point we had a major backlog containing over 150 issues, with a lot of stories that were loosely defined and had no foreseeable scope. Seeing such a huge backlog after 4 months of work with little progress is pretty devastating. As a result, we struggled to see the light at the end of the tunnel and our motivation went down a lot.
Once we applied our new workflow, our motivation immediately went back up again. We now have a Scrum Master (Anselm), a Product Owner (Tobias), and all three as Development Team. By having clear responsibilities, we are more attached to our project than ever. We used a couple of days dedicated on refining our Backlog. We split stories into way smaller parts, prioritised them properly. We re-evaluated whether the task has a clear User Story and if it’s likely to be finished within one Sprint. We created a proper Scrum Board. We started to create a Definition of Done for each Story. And we started to work in one week Sprints, ending them with a review of what has been done (15 minutes), a team retrospective (about 1hr), and the new planning right after (currently about 60-90 minutes).
To our surprise, and despite all the improvements, we failed to achieve our Sprint Goal for the first four Sprints again. We concluded that we had massively over-committed due to excitement. Finally, after a clear discussion that over-commitment doesn’t work, we stepped back and went for way less work in a Sprint. After the next sprint we had completed all our planned stories in time—a great relief and success. We hadn’t achieved very much, but we finally had estimated much closer to what we are able to deliver in a Sprint.
Since then, not only did we improve our work performance but also our workflow a lot. The retrospectives at the end of each Sprint provide a great space to check on the team’s health. We use them to find out how people feel, what worked well this time, and what should be improved.
Already four years ago I learned how much value retrospectives can bring to a team. So far, I still believe that they are one of the most powerful tools we have to improve work and teamwork.
Since our project restart, we changed a lot, including these items:
- We now have a daily Slack reminder to remind us to post a short summary of what we’ve been doing and if there are any blockers. - We changed the way we write tickets with even more details. - We adjusted the way we do Virtual Office over the day to be more inclusive to further away time zones.
Our team is not perfect, and it’s likely never going to be. We still have a lot of things to figure out. There sure is room for improvement in regards to planning, testing, and in achieving a better workload, but we’ll eventually get there.
Reflecting how much we have improved since the beginning of this project makes me proud. Seeing this progress as a team is very gratifying and motivates people to get even better. And that is what we’re going to do: Constantly improving.
In our next article, we will shine a light onto how a small amount of tools helps us to achieve constant improvement and supports our way of working.