12th May 2020

Operating under lockdown; The New Normal

The Coronavirus pandemic has affected individuals and businesses across the globe, and here at Si Novi we too have needed to adapt. But we're fortunate that we can keep operating, even learning and improving from the "new normal" ways of remote working.
Cloud Development

An unprecedented event

These last few months with the world under the shadow of the Coronavirus pandemic have been strange, uncertain and worrying. Individuals and businesses have been affected in so many ways, and normal life interrupted, perhaps changed forever.

We're lucky in that the nature of our business, being online and generally remote from our clients, lends itself well to good continuity under these circumstances. We feel for businesses who have been forced to shut up shop, and who rely on the physical presence of customers and footfall through the door. I very much hope our local communities and small high street businesses - who may have already been struggling with the changing economic landscape over the last few years - are able to survive and thrive post-lockdown.

But even with our natural online ways of working here at Si Novi, we have had to adapt.

Image of Si Novi's Manchester Studio

Adapting to remote working

We're a small team that in theory could never need to have an office space - but we invest in our studio environment in central Manchester to give us somewhere to collaborate and work closely together, blending our digital development with physical assets like product story maps, whiteboard infrastructure diagrams and hand sketches. We often work on software that integrates with physical hardware and telematics devices, and sometimes being in proximity to the devices can be essential.

So being forced to leave our studio and work from home has been somewhat frustrating - not least because in mid-February we moved into a lovely new studio in Bruntwood's West Village! I certainly miss the community in our building and our superb broadband upload speed.

But in many ways the enforced remote working has improved our ways of working, and given us the opportunity to chop out redundant processes that can creep in to the working week.

Our weekly planning meeting at the beginning of each week happens as usual, but now it takes place over a Slack audio or video call, and we have a digital version of our normal physical post-it system, built up in Google Sheets. This multi-sheet workbook keeps us organised and focused on the right priorities for the week.

We'll probably keep that even once we're back in the office as it's a really effective way of recording, prioritising and working through our on-the-business tasks and client projects.

In terms of development work we've been doing less pair coding and more code reviews. When working remotely it's not as easy to pair code (yes you can screen share, but it's not the same somehow), so we find that pushing work backwards and forwards, tagging others in to review, improve and iterate works well. Client showcases and reviews take place over video calls or through recorded demonstrations and with new app iterations shipped on Testflight or on development environments.

Our "on the business" work has adapted too. In addition to the regular software development projects and ongoing software support & maintenance activities for our clients, we of course spend a proportion of our time running the business itself. These activities include finance, marketing, internal ops and the development of our own products and digital services.

In this area of the business we've delegated out the tasks a little more and taken primary responsibility for particular projects. This has nice rewards when you can bring an app back after a few weeks and showcase the updates and get feedback from each other.

Efficient remote working when developing software

I remember an anecdote from many years ago about a business who were building a remote development team. I can't remember who told me this, or where I read it or even who it was about, but it's stuck in my head ever since.

So - the business wanted to develop a remote team. Instead of just hiring recruiter to recruit a load of people and putting them in a new office in the new remote location and giving them Slack (or probably Hipchat in those days), this business developed their team as follows:

  • Hire the remote team and ship them to the HQ location for a month (or three).
  • Get the HQ team and the remote team working together on a project in the same room. Hang out, socialise, talk about dev stuff. The usual.
  • After a few weeks / sprints, separate the HQ and remote team into separate rooms and continue working on the project. Use the online communication tools you plan to use. Continue to socialise at break times and get together to discuss how the remote processes are working.
  • Continue like this for a few more weeks.
  • Send the remote team off to their own location, with social bonds and friendships forged and a remote working process that was co-developed and has the buy-in of both teams.

My recollection is that it was a successful operation… and regardless, the moral that I take from this story is that, if possible, remote working should be based on solid foundations of personal relationships and shared processes that have the buy-in of all team members.

Luckily we have that in abundance here at Si Novi as Martin and I have co-developed web-based software for over a decade, so our foundations are well set.

The tools of remote working

Slack, Google GSuite, Email. In this regard, nothing has really changed. We use these remote working and productivity tools on a daily basis regardless of our location.

We are perhaps pushing a lot more bandwidth through Slack than when working in our studio, and the tool that's been invaluable is Google Docs - the shared editing and commenting is really powerful for collaborative remote working.

Using Google Meet makes for easy browser-based video conferencing with clients, although we've found the video & audio quality sometimes can be sketchy - Slack seems much better for calls.

A key learning we've made over the last couple of months is when on Slack, there are only two answers to the question “Shall we have a call?”. One is the negative - no, not right now, etc. The other is /call. Never, ever message back “yes” - or you'll all be staring at your screen for two minutes wondering who'll start the call...


Do you have any thoughts on this article? Get in touch: hello@sinovi.uk

About the author

James Galley

An AWS-certified developer, James architects and produces cloud-based web applications using Amazon Web Services. Recent projects include high-throughput event driven applications using Kinesis and DynamoDB, fully serverless web applications powered by AWS Lambda and high-performance static sites deployed to S3.

Profile image of James Galley
contact us

We're here to help

Talk to us today about API development on the AWS cloud.

We're a software development and cloud consultancy, operating as an outsourced technology partner for businesses - building, hosting and maintaining functional web based applications in the AWS cloud with trusted web technologies.

Discuss your next project