I have been working in development teams of one sort or another for most of my digital career, very often as a remote worker.
But is working remotely with Scrum teams really feasible?
Short answer, I think it is, as long as your team can embrace remote working.
Working remotely can bring an advantage to the Scrum team
Being part of a team is something I really enjoy, and I pride myself on being able to work harmoniously with the many and varying roles within teams.
Business owners, clients, anyalysts, stakeholders, coders, designers, users and product owners — I enjoy working with them all.
Distributed teams and remote working
Very often I have been part of a distributed team. These teams have variously been located right across the UK, Europe and beyond. It can be really exciting to Skype with a developer or client in Texas, Beijing, Sweden or Australia. Skype is quite remarkable in making someone who is 6 or 12 thousand miles away seem like they are in the next room.
And the conference call capability of Skype means that real, productive meetings can be held at a fraction of the cost of a colocated meeting.
The wealth of other collaborative tools that proliferate the web make remote collaboration entirely feasible, productive and very enjoyable.
Distributed teams and WordPress
WordPress, by its very nature is a beast created out of distribution. Hundreds and thousands of developers worldwide have contributed plugins, themes and even core code. The internet itself is a distributed platform, and WordPress is a manifestation of the wonders of worldwide connectivity and collaboration.
It would be unwise therefore to suggest that distributed teams are a thing of the past, simply because of the benefits of colocated teams.
Agile ringing the changes in work-space design
It is true Agile has become the de-facto project management methodology for many digital teams, and the need for roles to collaborate within the same physical space has greatly intensified.
Within organisations both large and small, more and more digital teams are starting to reap the benefits of colocation. Scrum by its very nature appears to demand that teams are located in the same building.
Sky has recently launched their new technology hub in Leeds Dock, where they have taken colocation to the next level with a purpose-built workspace for around 600 developers. Needless to say, Agile, Scrum, Kanban lie at the heart of their digital organisation.
Does Scrum mean the end of remote working?
Probably not. It is easy to argue against distributed teams, but economic imperatives make outsourcing, in-sourcing, near-sourcing, and rural-sourcing compelling for many organisations.
Add to this the need for specialised skills not always available within the Scrum team, plus capacity management issues and you have three key reasons why working remotely with Scrum can still be essential to some teams.
Tech Republic have an interesting read on the benefits of remote working.
Colocation is the ideal, remote is the reality
Colocation still remains the most effective way a team can collaborate to create high quality software. Yet remote teams are here to stay. For all sorts of reasons, more and more Scrum teams will find themselves working with team members that aren’t there physically.
So it is the ability of the Scrum teams to communicate over physical boundaries that will pay dividends in higher quality, less confusion, faster throughput, and happier individuals.
The Remote Development Team
If we accept the reality that there will always be a need for remote workers and remote teams we need to see how Scrum can help. When two companies merge, for example, or simply when two tech companies need to collaborate on a joint venture, development teams can find themselves geographically separated. Working remotely with Scrum results in three obvious situations:-
- Remote Development Teams – work together, but are physically separated from the rest of the company.
- Remote Team Member – a single member of the team works in a different location than the rest of the team.
- Distributed Team – individual team members working together toward the same goal, but each from a unique location.
Scrum to the rescue?
Not quite. In fact a lot of people will tell you that remote working and Scrum are incompatible. Yet the Scrum framework doesn’t say anything about distributed development teams. Scrum does not say all members of a Scrum team, or a Development team MUST work in the same room, building, city, or time zone.
Well-run Scrum teams will expose impediments, and if communication is an impediment, Scrum makes that highly visible.
The obvious mistakes are having Product Owners located in a separate building, or worse the Scrum Master. That clearly is not going to work.
The key concern for the Scrum Master is how to integrate remote workers into the physical aspects of the Scrum team. This does not mean just the Daily Scrum, Planning and Sprint Reviews, but also the chat and informal connections between team members.
Working remotely with Scrum: Decoupling the code
Planning meetings and all other face-to-face contact are restricted for the remote worker. This in turn can lead the remote worker to create more self-contained code. Many WordPress coders use object-oriented code and specifically interfaces, for example when developing a WordPress plugin.
Using an abstraction layer in a remote workers code means her work is more easily isolated and tested, which is a good thing. Her implementation is distinct from the interface she has declared and made available to other members of her team. This type of pluggable system leads to cleanly decoupled code, and is a best practice in WordPress coding, precisely because of the need to avoid colliding with code from thousands of other plugins.
Keep it simple
In terms of Scrum, code abstraction actually introduces layers of complexity that are not always desirable. This is especially true when it is a proprietary solution, such as a large consumer website built partly at least on in-house code. The need here is for speed and simplicity.
We are all in this together!
Changing the coding to suit the configuration of the team is not always the ideal way to solve the problem of integrating remote workers. To quote the Agile manifesto, Individuals and interactions over processes and tools.
The key here is in finding ways to include and involve your remote workers in your team. There is an emphasis on the remote worker being a confident communicator, comfortable working remotely but ready and willing to engage with the team across a variety of channels. Ideally the remote worker will be able to make regular visits to the core team and hopefully participate in social events as well.
Equally the team need to accommodate the remote worker, as it is in the best interest of everyone that everyone works together as a team. “We are all in this together” must be a reality, not just a slogan.
Building excellent, open and honest communication is the way to build trust and trust is the way to create happiness.
And we all know happy teams make better code – wherever they are located!
Get in touch for more about info about remote working with us