Virtual Co-Development Opportunities

When talking about the virtual office or remote working in general we often find ourselves comparing to a physical office and talking about how it is almost as good in a variety of situations. Or highlighting the indirect benefits to the business such as the ability to focus less time commuting, the improved happiness of employees, and lower turnover. These are all great but they are not easy benefits to convey to customers.

There are a few areas where a ‘virtual office’ is better and I previously described how we could be more Agile by being virtual but over the last few months we have discovered that we can solve some really fundamental business objectives for our clients without compromising on any of our values, standards, or profit margin.

Example case study

As an example: we have a client that historically outsourced much of their software needs to third parties, the result for them is a mismatch of tools that do not integrate well and have varying standards of quality. They also have problematic and often costly support models and the overhead of dealing with a myriad different vendors.
As a result they have now adopted a policy of owning and supporting their own tools and bringing back in house the tools that had previously been outsourced.

But this raises a number of issues. There are four issues in particular with this situation that they are seeking to resolve. I see these issues as being common to almost all engagements and all companies when they have identified a need for using an external software consultancy.

Bandwidth

Bandwidth: their IT department has limited capacity, the teams can only do so much and there is a lot of work to do. There are only so many people available to do it and they have a limited spectrum of skills. Conversely the value of the projects to the organisation is vast. However, limitations on hiring, head count and domain knowledge acquisition mean that the cost of delay justifies using a consultancy to bolster the capability.

Cost

Cost: The work could be outsourced and ownership retained if a consultancy firm is employed. After a period of knowledge handover the internal teams could support the software after the project is complete. However, hiring a large team of consultants is expensive, coordination and communication can be difficult. Integration with other tools at the client site is complex – often slow and painful, and knowledge handover is time consuming, all of this is very costly.

Outsourcing to a third party may be difficult from a budgeting perspective. Bespoke software projects are notoriously difficult to assess scope and cost and it is not unusually for projects to exceed initial estimates.

Knowledge

Knowledge/Expertise: The internal teams may not have the knowledge and experience necessary to do all of the work, especially in specialist areas like mobile application support and so it is often necessary to hire experts and then transfer knowledge to internal employees. Knowledge handover is time consuming and when done at the end of a project is often incomplete or doesn’t fully sink in. Risking later failures or expense.

Trust

Trust – Generally software is pretty opaque and so when there are problems or delays or unexpected work, or tasks that are more complex than anticipated clients are naturally anxious as it is hard to tell the difference between genuine problems or mismanagement. Trust is often unspoken and hard to rationalize, particularly when you are paying large sums of money for what is often a black box. It can sometimes seem like writing a blank cheque and hoping. Much of this is the nebulous nature of software and the every changing environment but when you are paying the bills this is a hard pill to swallow.

Co-Development

One of our common offerings is co-development this will generally resolve some of these problems.

Bandwidth: We can offer a co-development setup where we intermingle part of the client’s development team with our smaller team and work together on a project essentially half a team each. This is a great solution for this situation, the client retains ownership of the software, they are already working in the client’s IT environment with their employees, so integrating with other systems and teams is easier. Because the client is not committing a full team to the activity their bandwidth is maximized, they could essentially double their capability if they split all of their teams this way.

Knowledge: This method enables the consultancy to supply the expertise and the client to supply the domain knowledge. Knowledge is transferred throughout the project with no need for a clumsy handover period at the end. Knowledge gained by doing the work is far more valuable and reusable. It also shares knowledge of practices and processes in addition to the knowledge of the software.

Trust: By using a co-development effort it becomes a partnership, your team is part of the solution so you have much more insight into the situation so much more confidence in what is being reported. If there is a problem that is more complex than anticipated your own employees are engaged and able to offer transparent and unfiltered insight into the situation giving you far greater trust and awareness. As your team are part of the decisions there is less second guessing and more accepting that the decision made was the best with the information we had at the time. This is not a substitute for good planning and good management but it removes the nagging uncertainty when using a third party.

Cost: The main problem with this model is that unless the client is very close this becomes expensive and inconvenient. The development team needs to be prepared to work away from home for extended periods, there is a lot of lost time for travel. Generally speaking people do not enjoy working away for long periods and of course the client now has travel and accommodation costs on top of consultancy rates, making the service very expensive.

We essentially solved three of the problems but made the cost problem worse and added the complication of inconvenience to the employees. It limits this solution to those where cost is less of an issue or those local to the consultancy.

  • + Bandwidth:
  • – Cost & Inconvenience
  • + Knowledge
  • + Trust

Virtual Co-Development

Virtual co-development enables us to solve all of these problems. A Virtual co-development model brings all of the benefits of co-development listed above but by the virtue of being virtual there are no travel or accommodation costs, there is no time spent travelling. This cuts out a significant chunk of the cost with very little in the way of consequence.

The virtual nature also makes the team more accessible to the client and the home office, it essentially brings everyone closer.

Shifting to work virtually does come with a slight adjustment period and there are a few technical hurdles to be able to share screens and get access to client’s software environment but these are fairly trivial and common problems and access to a a VPN will resolve this generally and as most companies are already prepared for employees working remotely some of the time it is rarely a complicated request.

  • + Bandwidth
  • + Cost
  • + Knowledge
  • + Trust

Magic Bullet?

It is rare to be able to offer a solution that seemingly ticks all the boxes but this seems to me to be one of those rare opportunities where we are able to offer a better service for less cost, with less complications and without compromising profit margins, it really is a win-win situation.

The partnership style of this also reduces complications over scope and budget, it can be more easily budgeted for. By the partnership nature of the work budgets for the outsourced elements can be very accurate as they can be for a fixed duration – rather than arbitrary scope set before the product is fully understood or nebulous outcomes. There is no risk of being forced to extend because of incomplete work or scope change. The ongoing partnership means that the internal team can continue at any time with little or no hand-off. It becomes a much more clean and simple contract.

This model won’t suit everyone and is not ideal for all clients but for those with similar needs to the client above I feel this is a golden opportunity and one where being a virtual team is a clear and distinct advantage.

A 3-pipe problem

Sherlock Holmes was a master of deductive reasoning and problem solving, rarely was a problem beyond his capability. However, every once in a while he encountered problems that required a greater level of consideration, it would stretch his mind to it’s limits and required him not to be disturbed for an extended period, he described these as 3-pipe problems, he would need the time it took for him to smoke three pipes.

IMG_0640

I am no Holmes but I have the joy of a 3-pipe problem to immerse myself in. I have been asked to lead an endeavour to create, build and run a virtual office comprising of cross-functional teams that create software. The challenge is to grow an office but maintain agility, retain our company culture, and have the teams happy and engaged. Oh and be profitable too.

Where I have seen remote work successful in the past has been where there were clear tasks assigned and collaboration was a minor element of the work. My observations of many remote workplaces is that they focus on individual contributions, collaboration is asynchronous and there is a heavy overhead of management assigning tasks.

What I am envisioning is a workplace where the team is self organised, and whilst there is likely an increased element of asynchronous working it will be alongside effective collaboration. I see my role as identifying healthy boundaries that enable collaboration and creativity.

36509555 - remote work or global wi-fi internet connection

Communication

Naturally communication is key, just as it is in brick and mortar offices, but when we are face to face we have a lifetime of skills to rely on. Instinctive awareness of body language, sensing mood and tone, not to mention touch – hand shakes and physical contact create bonds we don’t fully understand.

Remote teams communicating effectively is far more complex than simply joining a webex. I see the ability to communicate and collaborate as the number 1 challenge of this role.

Why this?

As an agile coach I strongly support the Agile manifesto (alongside Lean, ToC, and Lean Startup) and the manifesto favours individuals and interactions over processes and tools. It also advocates face to face communication. And yet I am taking on a role that is putting barriers between people and pretty soon I’ll be talking about how processes tools are vital for enhancing individuals in their interactions.

So why take on a job that seemingly flies in the face of this? The answer is twofold, First I believe the manifesto is a mindset for guiding teams in improving their way of working to get better at delivering software. I believe we can adhere to that mindset in this environment, I don’t see a conflict. Secondly I think that the focus and scope of the manifesto didn’t consider the larger picture and the changing state of the workers needs. Face to face is better – no argument from me, but it comes at a cost. We need to weigh up what is lost and what is gained from remote working and decide if what we gain is worth the sacrifice and I think with the right attitude, training and tools the desired outcome of effective collaboration can still be achieved and achieved in a way that is better for many team members.

What is more, I think this will be one of the most challenging coaching roles I have faced. Just like teams, coaching is far more effective face to face. The coaching may take on a different dynamic but I still very much see this as a coaching role.

Processes and Tools.

I warned you! To have effective communication and collaboration in a virtual workplace processes and tools are vital ,and are a prerequisite to the individuals and their interactions. But I don’t see a conflict here, in face to face communication there are processes and tools, we just don’t feel the need to mention them as they are natural to us.

Don’t shout, don’t mumble, don’t interrupt, pay attention, look at the speaker, be respectful. Lots of processes and a lot of non-verbal communication. And just watch for hand gestures or pens on post-it’s or whiteboards these are all tools, we hardly consider them that way and we certainly wouldn’t object to any of those processes or tools, they are necessary for our interactions.

In a virtual world the need is the same but the tools are different, tone of voice and body language are harder to decipher, so we need to be more attentive and more explicit. pen and paper are replaced with online collaboration tools, shared screens, electronic gestures and Slack messages to clarify misunderstandings.

IMG_0639

The scope of the task is daunting but I so excited about this. My employer is already a leader in Agile software delivery, this is the chance to demonstrate that we can be agile about flexible work environments without sacrificing what has made us successful: collaboration and self-organization.

This blog will continue to be Agile focused but I’ll also share some of the experiments as we discover what works for us.