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.

Can being remote enhance agility?

I am a very lucky person, I have my dream job. I work for a huge Solutions Provider as a member of their software consultancy group. The consultancy group has multiple physical offices in the St Louis area, and offices in Denver, New York and London. we have now decided to expand into the virtual space and launch a Virtual Office dedicated to collaborative software delivery. My role is to create this office, define the tools, practices, processes and then to build the team: hiring and supporting the staff and managing and growing the office. It is an incredible opportunity and it is not overstating to say that I wake up excited (and daunted) about it every day.

I wrote a while ago about the new role and about the challenge of remaining true to an Agile mindset. My goal was not to lose our agility as we became separated by technology and tools. https://yorkesoftware.com/2018/10/11/a-3-pipe-problem/

It was a surprise to discover that with the right attitudes and the right tools we are actually able to enhance our agility. We are actually more agile in a virtual space than we were in the physical space.

What is Agility?

To many this will sound like an exaggeration, but as a consultancy firm we sometimes operate in a less than optimal situation, there are challenges when you are working in a slightly abstracted situation. To be truly ‘Agile’ the goal is generally to get the team and business working together and to shorten feedback loops, deliver software quickly. But the reality is that ‘the business’ is a client. They are removed often physically which is bad enough but often they have other priorities and so are removed in an availability sense too. So whilst our teams are together, it is rare that we get the business (SMEs and Product Owners) on site and embedded with our team, when we can this is the ideal situation.

More often we get together for project kick-offs and planning and regularly for demos and retros. But stand-ups are often conducted via web conferencing tools, as are story writing and weekly planning/prioritization meetings. This puts a barrier between the team and the business, we do our best to break down these barriers but the reality is that they exist.

I call out being a consultancy as it is an extreme case but it also happens in most businesses, the PO and SMEs generally have another job and other priorities and the development team gets a slice of time and attention, so this is not unique to consultancy.

Brave New World

So understandably I went into this new venture with the expectation of doing my best to mitigate an already existing problem and to strive to not let it be worse in a Virtual Team.

In the early stages we found a tool called Sococo which is very hard to describe as technically it offers the same as many other remote communication tools, but it uses the metaphor of a physical office to make it easy for us to relate to the situation. When we used this tool something quite amazing happened, suddenly we were in the same metaphoric space as ‘the business’, we were truly working together. If I had a question for the PO I can drop by their office. If we need clarification from a SME we can invite them to join an Ad-hoc meeting.

We were no longer waiting for scheduled meetings to ask questions, we were chatting immediately. Feedback loops became immediate conversations, if someone was busy they would drop in between calls or other meetings rather than scheduling something formal. The casual nature of the metaphor brought us all together. This is how I imagined agile teams should behave in an office, but all too often logistics (read lack of meeting rooms) meant this was rarely a reality.

As a little tangent I worked with a delivery team a few years ago where the PO was available to the team all day but was in an office maybe a 60 second walk away. She made it clear the team could drop by or call her. But they never did. As an experiment I asked her to sit at a desk in the team area, immediately the team was a buzz of questions and conversation, we worked faster and discussions were spontaneous and relevant to the work at hand. This is how Sococo feels now. I can’t express how excited I am about it.

Daily Demos

An interesting thing has happened too, the team had an aspirational goal of daily demos, demonstrating completed stories and getting feedback on direction each day at stand-up. The aim was to challenge the team to keep stories small and to focus on shortening the feedback loop.

What happened instead was the realization that you don’t need to wait for stand-up. When a story was done the team would pull everyone together immediately get feedback and then discuss and plan what was next.

We realized that scheduled meetings for everything from story writing to stand-ups were primarily about availability of people and especially meeting rooms, they had little to do with the product or agility. When not restricted by availability of meeting rooms you can simply talk about what is needed when you need to. It is so liberating.
Naturally such a change requires a great deal of discipline to be effective but you have the potential to be focused on the shortest feedback loop, and reacting immediately.

By moving to a virtual environment we are becoming more agile than we were even together in the office, and having fun doing it. These may not sound like ground breaking discoveries but I can assure you they are having a profound impact on our work.

Are you pulling your weight?

A question I have been hearing a lot lately is how do you know whether an employee is putting in their hours, or not slacking off. This question seems to be particularly concerning for people in the context of working from home where the perception is that it is more prevalent.

The irony here of course is that being in the office is no measure of not slacking off, there have been many books written about different ways you can slack off whilst appearing to be busy.

I have heard tales of the productive worker that works hard all day long only later to discover they were working on a side project or even for a second employer. Long lunches, toilet breaks, extended coffee breaks, fake meetings, or just browsing the internet or discretely playing games on your mobile phone. Physical presence in an office is not an effective measure of whether you are slacking off.

The average American worker admits to wasting 2.09 hours a day, excluding lunch, according to 10,044 self-selected respondents in a survey released by America Online and Salary.com.

What does it mean to Pull your own weight?

Let’s take a little aside and explore the phrase “pulling your own weight” there are a few suggested origins of the phrase but the one I like best relates to the English Long-bowman, to be considered an ‘archer’ you had to be able to “pull your own weight” Longbows had a draw of up to 180 Lbs. You really did have to pull your own body weight.
An experienced archer could fire 12 aimed shots in a minute at ranges of 200-300 yards, although in battle they were expected to fire at a slower ‘sustainable pace’ of 6 aimed shots per minute. For context a modern bow draws at around 40 Lbs for women and 60 Lb for men.

In a modern terms we usually mean contributing proportionate to your role. We tend to think in terms of productivity and output. Despite this we often tend to focus on hours spent – hence the rise of slacking off at work, even though we can easily slack off time without being noticed, but it is far harder to slack off output or deny outcomes.

So how do you know whether your employees are working?

Personally I think that is the wrong question. When you explore deeper you discover that the employee surveys on why people slack off are far more interesting than the ways which they slack off.
Many described being bored as the primary reason, others felt that their job was easy. So it seems to be a question of engagement.

I suspect in other cases it is that you have hired the wrong people and better filtering at hiring would result in a more motivated workforce. Ironically when you have a motivated workforce getting them to take a break becomes more of a challenge.

So I guess what I am saying is that if you are a leader that is worried about whether your staff are working, then the issue is far more likely to be with you than it is with them.

  • Hire the right people. (Hungry Humble, Smart)*
  • Be clear what is expected of them.
  • Help them understand why it is important – and who benefits from their work.
  • Be interested in them as individuals.

Interestingly all of those actions fall to the leader rather than the employee.

If you follow these steps then I suspect that you won’t need to worry whether they are pulling their weight, you will be too busy trying to keep up with what they can achieve.

Where does the responsibility lay

If your employees are slacking off then it is a failure on the part of the leader not the employee. So when you hear someone ask how they can tell if an employee is doing their hours and not slacking off. Ask them if they have hired motivated people they can trust? Have they given clear objectives and set expectations? Do their employees understand the context and purpose of their role? Do you value them and do they know it?

If and when you do see someone slacking in a damaging way, take a look and see if the route cause is one of these 4 issues, you’d be surprised how often it is one of them.

What I am confident of though is that any efforts to monitor time in the office (or home) – such as time clocks, pressure sensors on seats, keystroke monitors, swipe cards on toilets, or a foreman to watch people – and of course a foreman for the foreman – obviously you need someone to watch the watchers. All will have minimal impact on people slacking but will have deeply damaging impact to productivity.

*Taken from The Ideal Team Player, by Patrick Lencioni

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.