I hope that by this time, you’ve gotten some idea of how to deal with remote teams, especially when there are significant work culture differences. If you’re dropping in for the first time, make sure your catch up on the context of the project we’re talking about from the Part 1 and Part 2 of this series where we talk about the technical and communication issues.
What I’d like to dive into in part 3, is a topic that has a variety of different theories and approaches. Many authors have written about multiple strategies on how to tackle and plan a software project. I’ve read at least 10 project management books, each with different task break outlines, more or less agile approaches, and ways of getting your team to gain “velocity” (productivity over a set amount of time).
Over the years, I’ve come to realize that no one strategy will be 100% applicable to a team, and that every team is unique in its own way. My advice would be to always take a hybrid approach, be flexible around certain project traits and as mentioned before, have at least one source of truth to be able to keep track of everything.
Moving back to the project at hand, it was very difficult for the three teams involved to decide on one project management tool. Suggestions included Excel spreadsheets, Github issues, Asana and JIRA, to name some of the most popular choices that were brought up. Personally, I wanted something fresh, modern and flexible. I’ve had experience working with Basecamp, JIRA, and Github’s latest kanban tool. All of these worked well, but depending on the level of control desired and granularity of tasks, boards and to-do lists would need more or less maintenance.
In the end, we chose JIRA for its immense flexibility. JIRA allows you to define different components such as a frontend site, an admin for your client, or a mobile app. Epics are also very handy to avoid big tasks and group together achievable milestones.
Let me tackle and describe now some of my important, project management related lessons.
If you find stuff that is not tracked, create a ticket (and assign an owner)
In an ideal situation, tasks/bugs are put onto JIRA, and you would work through the board ticket by ticket reviewing the their statuses if needed. However, once in a while, things will inevitably come up in a meeting or be mentioned vocally, but not tracked. It’s quicker to just go ahead and implement these types of fixes without putting them through JIRA right?
Okay that might have been a loaded question if you haven’t guessed from the heading of this paragraph, but I’ve found this to be a significant error that happens all too often. Hot fixes like these carry extra development time at the end of the project. It might even lead to confusion and different expectations. This usually differs from features to complete which are tasks that someone needs to complete in order to unblock some other tasks or a teammate. It’s very important for communication purposes and almost critical to set a task owner. I’ve come to appreciate the word “owner” in project management. Owing differs so much from completing a task. It implies pro-activity, figuring stuff out and communicating with related stakeholders.
Tasks should be clear enough for anyone to start working on
Again, cultural differences makes this even more difficult. There are many different approaches to what “being clear” entails and it might change depending on the project manager.
I’ve found it pretty useful to always attach the name of the user who’s going to be impacted by the task. In software development you might have different people using what you build, like a user, an admin, an editor and so on. The task title might look something like: “As an editor, I would like to approve a publication”. This is much better than only “Approve a publication”. It’s also quite helpful to include a related screenshot or design to the task so that the person tackling it has a better understanding.
Lastly, I think having a separation of tasks where some of them are more design related and others are functionality related, helps a lot to deliver value to your client. Following the same above example. Let’s say you’re building an app but you need to connect to an API to finish the feature. A separation might be something like:
“As an editor, I would like to approve a publication with hard coded content”: This task only takes care of building a feature for your app with hard coded content.
“As an editor, I would like to approve a publication”: This task, once having the previous one completed, takes care of integrating it with the API.
End sprints and track finished work
Whether you’re using sprints or any other name for your deliverables’ unit of time, it’s important to close, evaluate and move forward with a new period. A common reason people leave sprints open is when there are tasks that are not yet completed, so the action would be to keep going until an amount of work is done.
However, there are several problems with this approach. First of all, when you avoid closing and evaluating a development period, you are left with unknown productivity, which can then lead to the following sprint with an unrealistic workload. Secondly, an open sprint means you are unable to track any progress that’s been made within that time period, which makes it difficult to measure your deliverables for that sprint.
One great benefit of using JIRA and sprints, was that we had release notes automatically when we sent something to our client. It helps for software projects to also have versions at the end of a sprint. For example, v0.1, v0.2 and so on.
Choose your tracking tool wisely
Choosing this crucial tool will surely impact the performance of the project. I won’t go into detail on what kind of features a perfect project management tool should have, but I will talk briefly about what features stood out from JIRA.
The first great thing about JIRA is its flexibility. JIRA is suitable for almost any kind of project. For some PMs, it’s like the holy grail of tools. I particularly like the granularity you get when detailing a story or task, especially if one item is blocking or related to another task. It just gives a good picture, overall.
Secondly, even though JIRA is a big tool, its performance has improved a lot since the last time I used it 2 years ago. It has better and modern UI, and sometimes you forget you’re using this giant task manager. In general, the whole Atlassian ecosystem has improved with other critical tools for software development.
Lastly, you can modify a sprint and even create a whole new plan for the deliverables without much effort. Sprint and backlog layouts create a sense of what is priority and what can be saved for later. This is very important and helpful for setting team expectations.
Don’t wait for the PM to create tickets, create tickets and assign yourself
Again. Be proactive. Your lack of action might impact you later on. Ask for tool permission if you don’t already have it. Start creating tasks on your own, and assign them.
As soon as you become involved with the project and spend a couple of months on it, you’ll get used to your project manager’s way of writing tickets. Try to imitate that. You’ll probably have to make some tweaks here and there but the important thing is, the task is tracked and has an owner.
—
I had a blast writing these posts. I hope it has delivered some basic understandings of the challenges team members face when dealing with remotes teams.
Even though these suggestions are mostly related to this project, there are learnings that can be applicable in many cases elsewhere. I hope that you will find at least a couple of these points over this series helpful when you start your next project. I can only say now that I’ve “survived” this project that I’ve gained a lot of knowledge as as result of it. I’m sure I’ll be incorporating these learnings in other endeavors.
More blogs by Felipe
