Every company with a development team in place has some kind of development process. Usually, the process is based on Agile or lean methodologies, with some mixture between the in-office and remote work. Most companies have the infrastructure, but unfortunately, are not prepared operationally to switch to a fully remote approach. Ready or not, many had to go remote overnight due to the SARS-CoV-2 coronavirus pandemic.
In this article, I’ll give you a couple of tips on adapting your software development process to 100% remote work in the coronavirus economy — or any other crisis that demands cost efficiency. Let's go through some common remote software development process pitfalls and ways to avoid them.
Table of contents:
- How to deal with the lack of social interactions in remote software development processes?
- How to keep your remote software development team together?
- How to avoid common video conferencing pitfalls?
- How to avoid infrastructural technical debt?
How to deal with the lack of social interactions in remote software development processes?
The Agile approach to the development team setup emphasizes the importance of colocation, both to boost the efficiency of the team and to improve communication.The majority of the process ceremonies, like retrospectives or daily standups, promote collaboration — the team works as a single, living organism. Many people tend to forget that a tremendous amount of information is absorbed almost involuntarily.
When your team sits together, you just hear what's happening in the room. You overhear other people's discussions. You take in the info without participating in the conversation. And there are a lot of small social integrations in the office, too, like eating meals together or making small-talk while waiting for your coffee (it always takes longer when you really need to wake up, doesn't it?).
All these things help the team to integrate and understand that they're working towards a common goal.
Of course, teams working together as a whole in one office are rare now. Most companies mix in-office work with remote work (or allow home office) or have some external contractors in the team, but it's a healthy combination, and it all works out well.
But everything's different in the current situation of the pandemic. The majority of software development work is fully remote now, and each team member works separately. Also, this is unlikely to change anytime soon — the timeframe is expected to be weeks or even months instead of days. We must manage to keep the team together.
How to keep your remote software development team together?
Here are a few suggestions on how to keep the team integrated while working 100% remotely:
1. Encourage the team to interact more
Usually, the daily standup is the only meeting during the day when every team member listens to the rest of the team. The team should be encouraged to perform as many activities together as possible (like pair programming on joint conferences) to keep the spirit of working together.
2. Form a “virtual office”
The kitchen tends to be the centerpiece of the social life of the office. People meet there while making coffee, eating breakfast or lunch, etc. Of course, that kitchen is gone now. But we can always create a "virtual kitchen" — a permanent conference, where team members can connect and socialize.
3. Make check-up calls
This situation is hard for everyone. It’s important to schedule 1-1 calls, not only to get an update about the work progress but also to ask others how is it going, make some small-talk, etc. It’s best to use the camera whenever possible, to add a personal touch to the meetings.
4. Schedule online social events
Ceremonies are not meant to only organize how people work. The social aspect of these meetings is just as important. We can try organizing some purely social online events. If we go for computer game sessions, for example, perhaps only a small part of the team will attend — as usual.
But more accessible meetings can be a gamechanger, think of something like “a town hall with a beer” — an event when company matters are being discussed, but in a less official manner, with a beer. Of course, this kind of meeting should be organized at the end of the day, not to promote drinking beer during working hours. :)
How to avoid common videoconferencing pitfalls?
After everyone has switched to remote work, every meeting has become a remote meeting. The simplest way of adapting to the new situation was just to exchange all face-to-face meetings with video conferences.
Simple? Yes.
Efficient? Hell no.
Unfortunately, turning all face-to-face meetings into video conferences alone holds a significant problem: they are less efficient. There are solid reasons why all of the Agile guidebooks are suggesting to have the team working together physically. Assuming that a video conference is a 1-1 equivalent to a face-to-face meeting is just wrong. It’s necessary to optimize the video conferences to keep the software development process efficient.
Here are a few ways to avoid common video conferencing pitfalls:
1. Don't invite too many people
It's common to invite the whole team (or everyone even remotely involved in a certain topic) to a meeting. This usually ends up in a situation when only 20-30% of participants are involved in the discussion, and the rest are just wasting their time.
When scheduling a meeting, we should think about the impact each of the participants can have. Sometimes the simplest solutions are the best. For example, when we consider a cross-team meeting, it might be better to invite a representative of each team (each time a different person) instead of inviting all the team members of each team.
2. Don’t forget about the agenda
Most meetings just happen. They are scheduled because they were always scheduled, without much thought. It's a dangerous habit, especially for meetings with a lot of participants. A pointless 1-hour meeting of 8 people is an equivalent of a whole working day wasted. Each meeting should have a purpose and defined deliverables. Otherwise, we risk starting it with "OK, so what do we do here".
3. Don’t disrupt your team’s work
It's crucial to allow the team to have long periods of focus when they can work without disruptions. For example, if I have four 15-minutes long meetings scheduled at 1 pm, 2 pm, 3 pm, and 4 pm, my day will be mostly sub-productive even though I will only spend 1 hour in meetings. If I schedule these meetings wisely, one after another, I will have 3 hours of continuous work, which will be much more efficient.
It's great to have a company-wide policy of periods when as few meetings as possible are organized. For instance, a “no-meetings Friday”. This would mean that on Fridays, one can only organize daily standups.
4. Don’t schedule unnecessary calls
“This could’ve been an email” — this slogan is as accurate as it has ever been. As online meetings are less efficient compared to face-to-face ones, more and more meetings are scheduled to compensate. But we all need to remember that meetings are the most disruptive events during our work.
With an email or IM, we have some control over when to read it, which is not possible with meetings. It can easily lead to a situation when we will have at least 20% more combined meeting time compared to the traditional in-office working fashion. That means at least 20% less work done (even more, if we will calculate increased context switching and fewer periods of focus).
The only way to mitigate this risk is to make a thorough consideration if we really need to invite all those people to a meeting. Maybe we can just drop them a line via email or Slack and achieve the same goal.
Even if this approach does not render the meeting completely optional, it will help to make the prep work less disruptive, and it will drastically reduce the amount of time needed for the meeting.
A penny saved is a penny earned
The vast majority of mature development and product teams have a roadmap that identifies the most important goals to achieve in a certain period, usually between a quarter and a year. The goals (both business and technical) are predicted to have an impact on company products or future development.
Unfortunately, the current coronavirus situation renders most of such predictions useless. Especially the business predictions, as previous ROI assumptions associated with new features are no longer valid. It may even lead us to the conclusion that the new features are completely irrelevant in the current scheme of things.
We definitely need to reconsider the whole roadmap, as the situation forces us to reevaluate some of the technical debt and infrastructure optimization items. Sometimes, it's easy to overlook the fact that cutting 10k from our monthly GCP/AWS bill is as good as making a new feature with 10k recurring revenue.
Of course, the features that we have planned in the past had much better ROI, but it might not be the case right now.
How to avoid infrastructural technical debt?
Perhaps each of us has heard of technical debt. It happens when we take shortcuts to release something faster. It's usually related to code — replicated code, unextendable code, lazy classes, broken SOLID principles. However, a lot of technical debt is also made on the infrastructure side.
“We have a new feature, it will bring us 100k a month, but it will cost us an additional 10k monthly in server bills”.
Sounds familiar?
In times of prosperity, it's a no-brainer: it pays off to release the feature as soon as possible, as it has a net of 90k per month. It's easy to forget about the 10k part, as there is always a new shiny object, a new 100k feature ahead. Focusing on those items is more efficient than optimizing the infrastructure, as the gain heavily outweighs the costs.
Unfortunately, with the uncertain market, new features might fail to bring the expected revenue, and the cost might be left as a burden. It’s time to take a look at the infrastructure in search of potential savings.
Here are a few things we can do to painlessly save some money on our infrastructure:
1. Scale the costs of your infrastructure
If we have less traffic now, we should be paying less for the servers, right? Yes. Is this how it works? Not always. Unfortunately, most of the infrastructures are built in a non-scaling way. There are a lot of servers running with small loads (because there is no traffic) but at the full cost, as they are still available in the AWS/GCP setup.
To avoid this kind of situation, we should optimize our infrastructure to have a scalable setup. Even simple tools like load balancers, combined with Elastic Beanstalk from AWS, can produce amazing results — for example, having only two servers running all the time and scaling up when the traffic spikes.
A skilled DevOps team can efficiently implement this kind of setup. Afterward, we'll be paying for what we need. When there's no traffic, we'll only have the operational minimum to keep our application up. When more users come, new machines will be spun up on-demand to handle the load.
This way, we can combine the optimal bill with a system operational for, basically, an indefinite number of users. This is a great approach when we want to scale up or down easily, or our business runs in bursts of traffic (like, for example, events-based businesses).
2. Use the infrastructure when you need it
Infrastructure running 24/7 is probably right for the production environment. It often runs non-stop for the development, QA, and staging environments, too, despite having the dev team working only Monday to Friday, 8 am to 8 pm (assuming flexible working hours). If our team is big, we probably have some serious sets of machines in those environments to mimic the production (on the staging environment) or to allow testing of multiple feature branches simultaneously (on the QA environment).
It is very important to ensure a modern setup of those environments. A solid DevOps team usually follows the IaC (infrastructure as code) approach using tools like Terraform and container-orchestration systems like Kubernetes, to ensure the machines are available only when needed. This kind of setup allows for easy shutdown and setup of the environments when needed.
3. Optimize your data processes
Data processes can be expensive, and they tend to snowball. Even when the business goes quiet, data sources are probably still available, and we're still able to fetch the data. Typical DataFlow and Pub/Sub processes might be costly, even if properly utilizing ready-to-use tools available, for example, on GCP. We definitely should evaluate if we need this data at the current moment.
One of the big (and stockpiling) costs is data storage. Once we decide that we don’t need all of the data currently, it's a great opportunity to implement automated data retention policies to move the older data to cheaper, but somewhat less accessible storage, like AWS Glacier.
4. Optimize your side tools
Of course, the servers usually make up for 90% of our recurring infrastructure costs (to separate it from the payroll or office costs). However, some costs are often overlooked. The costs of GSuite, Atlassian, or Slack tend to be neglected, but at least they're noticed. But there usually is a set of random tools that we have used in the past and forgotten, but they are still being paid for, as the subscription renews automatically.
These might be some chart tools, old software quality tools, unused monitoring tools, communication or conferencing tools, obsolete CI services, and many more. They might sum up to several thousand per month.
This kind of inefficiency is not as glaring when we are business leaders, and our commercial goals are much more important. But when we have no rabbit to chase, it's a perfect opportunity to improve our organization in this area as well, to be better prepared for scaling up in the future.
We should start with an honest identification of all of our monthly spendings and make the initial assessment of “can I disable this tool completely?”. It can be surprising how many paid tools can be removed because nobody in our team uses them, and many can be easily replaced with free alternatives. We should take a look at the crucial tools as well.
Of course, if we’re using Jira and Confluence, we'll still want to keep paying the Atlassian bill. But it’s a good idea to go through the user list and make sure to deactivate all of the unused accounts (it is not that uncommon to cut the access in Jumpcloud, but still pay for the Jira account), then assess all of the paid plugins, as there might be a few dozens of those.
Keep in mind that these changes don’t only bring immediate relief. They will make our companies more efficient in the future as well. They will not only allow us to scale down during the bad times but will also keep us prepared for rapid growth when needed. Having a scalable organization is crucial in the modern market, as we need to be flexible and easily adapt to changing circumstances.
Working towards the light in a tunnel
The majority of our work now will likely be focused on maintaining stability and introducing cost-saving optimizations. However, remember that in a few months or so, the market will start to bounce back, and we should always chase the occasion to be the leader.
First, we should evaluate the things that we were working on before the pandemic has started. Maybe some of them are close to the finish line and can be easily finalized? Apart from that, we should consider what kind of functional changes might give us an advantage over our competitors. As the market changes, the potential business ideas need to be adjusted as well. Maybe we can also devote some percentage of our development power to those?
We live in interesting times. A lot of things are happening at the moment and creating new challenges for businesses. But we should stay focused on the right things, so we can prepare our businesses to boom in the future!
