10 Benefits of Remote Work, After Two Years at Home.

It seems there have been thousands of internet blogs and Facebook posts giving advice on remote work from people that have been working remotely for less than a week – such is the internet, so why not add to the noise with my opinions too?

I don’t want to give the impression that remote work is rocket science or that I am any kind of expert, I will gladly admit that I have muddled through this last couple of years and have learned far more from my mistakes and ill-founded assumptions than through careful planning or education. However, I like to think that I have grown and learned a few things along the way.

Remote working is far more nuanced and complex than people realize and there is an awful lot of good intentions and bad advice out there. The news organizations are even worse, the BBC had an article recently that I think must have been written 20 years ago about remote work and dragged out and polished up and presented as advice, it looked like it was written by someone that had never actually worked from home and was just a series of stereotypes on home working.

Our history

A very brief history of our experience. Two years ago I was asked to create a remote office for our software consultancy division. The goal was to enable us to recruit more software delivery teams and grow the company more quickly. The constraint was that it had to be an Agile environment and had to maintain the culture of our organization.

Remote Collaborative Teams

I quickly realized that this was actually a novel idea, the vast majority of remote work is asynchronous and solo – the very opposite of Agile.
Agile, the way we do it at least, is very interactive. Our teams have impromptu meetings multiple times a day – we call these turnarounds as in an office the team spins their chairs around discusses a topic for a few minutes and then goes back to work. Achieving something as simple as that in a remote setting turned out to be very rare and more complex that I had anticipated. We also follow XP practices and Pair programming which are heavily interactive so again we wanted to avoid the conventional advice for solo work.

Over the last 2 years the Virtual office grew from 1 person to around 120 employees, we have a cross sections of all roles within a software delivery team, and we were working incredibly well. We have come up with a range of effective tools and processes. I was feeling very pleased at how quickly we had grown and how stable things were for an office that was so new. People were happy, productivity was high, turnover so far has been very low.

And then of course we had the impact of Covid-19. This meant that the rest of the organization was asked to work from home. We added 500 more people to a set up that we had designed for around 100 in the course of one weekend with almost no notice. I had the support of an amazing leadership team and an IT group who pulled out all the stops to help. Between us we managed to scale our Virtual Office from just over 100 to 650 in the space of a few days, with very very few hiccups.

That is not to say it was easy but we were able to keep the entire workforce productive based on the lessons we had learned over the previous 18 months.

So what have we learned?

  1. The right tools are important but they are only half the battle
    • Someone compared it to playing chess, you can hand someone the board and pieces but you can’t expect them to play, you can teach them the rules but even then it takes a while to be competent. The same is true with remote working tools. Most of us have them but very few of us know how to use them and even fewer of us use them effectively.
  2. Remote meetings are different, it takes time and effort to make them effective
    • We are deprived of body language and social cues, we need to reinterpret the world based on less information. There are different mechanisms we can use to achieve the same things but we must adapt.
  3. Learn how to configure your audio. YOU are causing pain to your team mates
    • That noisy keyboard, the rustling papers, eating, drinking, singing to yourself are all painful to your co-workers
    • You should probably find a friend you trust to calibrate your microphone with. Position it well and be sure you can be heard clearly. If using a headset be careful that the microphone is not near your nose or too close to your mouth, heavy breathing is not good.
    • Get a good quality headset or microphone. The built in microphones are generally poor quality and pick up all sorts of interference.
  4. Learn how to position your camera. The view up your nose is not a good look
    • I often see people with laptops have them positioned so that the camera is looking up at them, this is a really unflattering look.
    • Other common mistakes are sitting with a window behind you or in a dark room.
  5. Take regular breaks
    • Take a short walk, check in on family. Or take a short while outside or away from the computer. Change position regularly, set a timer to remind you.
  6. Get a comfy chair
    • chances are you will be spending more time snuggling with that chair than with your spouse.  Your back will thank you at the end of a long day!
  7. Be aware of eye strain
    • bright lights can be painful over time and you can turn off the blue light on monitors or turn on the night light mode to be more comfortable.
    • I struggled with this a lot and ended up buying some new light bulbs and some computer glasses to help.
  8. Find a way to differentiate between work and home
    • Shut a door, turn off computer etc. This is really important, it is very easy to get in a situation where there is no clear line between home and work. For our own sanity it is sensible to turn off notifications on your phone and close the laptop. It is far too easy to see a message and get drawn back into work late at night, or to start work before you have even finished your first coffee.
  9. Make time to socialize in meetings
    • Take 5 minutes to chat at the start of a meeting.
    • Since moving to remote work we seem to have developed a guilt at spending time socializing. I hear people apologizing for talking about personal things at the start of a meeting. Those social interactions are a key part of team building and are necessary for a high performing team they are not something to apologize about.
    • Prioritize time for social interactions. I don’t mean scheduled 30 minutes of forced networking, but maybe you could consciously catch up with co-workers when you see them, just making a little extra time being friendly before or after a meeting.
    • Our office has adopted an unofficial 5 minutes past the hour meeting start time. I still come to meetings on the hour and spend that 5 minutes chatting with anyone else that shows up early, this is a great opportunity as there is no implied pressure to get on with the agenda.
  10. Working from home does not need to be solo working
    • If you are doing solo work then hang out in a room with others doing solo work so there is opportunity for human interaction.
    • This is my biggest lesson of all. I think all of the companies that have set up asynchronous working patterns devoid of human interaction will suffer from the lack of collaboration and engagement as time goes on. Scheduled/forced socializing is not the answer.
    • Creating an environment where co-workers can collaborate or simply be in proximity to one another promotes healthy team work. We have casual chats and ad-hoc work discussions. Feedback loops are fast and effective. We feel close to our teammates and feel connected. This feeling of proximity, awareness and connectivity is incredibly valuable.

Summary

For me working from home has been an overwhelmingly positive experience, by encouraging collaboration and interactions throughout the day our teams are happy, engaged and effective. I hear other companies are struggling with disengaged, and lonely employees and I would strongly urge you to consider a more collaborative approach even if the work your employees are doing is solo it doesn’t mean they need to be.

Try Banning Mute in Meetings

The phrase of 2020 has become – “Sorry I was on mute” this has become a little bit of a running joke and I feel sure that nearly all of us have experienced it in almost every meeting.

Sorry I was on mute Button | Zazzle.com

But what would happen if we leaned in to the situation and simply asked people to NOT mute during meetings?

In small meetings (those under 10 people) it is bizarrely powerful. One of the things we lose with the mute button is the little murmurs of approval the laughing at jokes and even the noises of disagreement.

People often worry about the background noises, especially dogs or children but the reality is that in a small group these are much less distracting than you think they are. Unless it is particularly loud it generally doesn’t disrupt the conversation when it is a small group.

It can take a little getting used to but after a while it really improves the engagement in the meetings and for me at least it acts in a way to hold me accountable for paying attention, especially when I know people will hear my typing, the awareness causes me to pay more attention.

But what about just being in the room with others?

So I have taken this a step further and our team has an informal policy that if you are working solo you should default to hanging out in a room (voice call) with anyone else on the team that is also working solo.

This has an incredible impact on the team building impact for a remote team. Spontaneous conversations spark up and people chat as they work. I enjoy just listening to the buzz as others talk and do not find it distracting. We get to know each other more and it seems that just being in close proximity encourages more personal conversations about our histories and personal life. Just by hanging out today I learned about fishing for fun not for food and no-barbed hooks. We had a fascinating discussion about sales tax on cars and a pretty intense discussion on whether government was even needed. How many of your recent remote meetings have resulted in you getting to know your team better?

But background noise is not for everyone and we also have a room for quiet working. Which means the team can hang out nearby and can be pulled in when needed but are able to work quietly if they prefer that.

The lesson for me in this is that when you have set up your audio correctly background noise is much less distracting than you think it is, and that the quiet spaces are opportunities to build relationships and engage with your team.

Try an experiment

I’d encourage you to try it for a week, ban the mute button and try to spend time in the same audio space as your team when solo working and see the impact on your team.

Why do we have physical offices?

Seems an odd question when for over a hundred years this has been the default option, we have never questioned it and often the benefits have seemed so obvious it is rare when they are articulated. But are the benefits clear and are the benefits restricted to a physical office or are there other ways we can achieve the same outcomes?

The benefits

For most people the benefits of offices are universal truths, we accept them unquestioningly. We have seen the benefits first hand and understand them. No one questions the value of proximity to co-workers and many/most leaders have “open door” policies to benefit from that proximity to their employees and the valuable interactions it enables.

If we chose to build a physical office what would we expect?

I asked people to describe why we had a physical office, the responses below sum up the majority of the responses.

  • A single location where all work colleagues can come together
  • We value casual interactions with co-workers
  • Teams are more productive when able to interact in real-time
  • Teams are more productive when they are close to each other
  • Reduced feedback loops, people you need are right there
  • Creates a sense of community
  • Accessibility to leadership
  • Meeting rooms enable people from different teams to interact with each other
  • Team rooms enable teams to be more effective as those needed are all together
  • Shared information – Build information Kanban, Working agreements
  • Visibility and Accountability of employees
  • Location for Sales meetings/meetings with clients
  • Ability to show working arrangements to potential customers|
  • Enhanced recruitment experience
  • Proximity to clients

At what cost

The benefits of a physical office are significant. So much so that we accept the considerable costs as a necessary expense to achieve the outcomes desired.

  • Office buildings are expensive, rent, bills, furniture, support staff, maintenance
  • Time, commuting takes hours for each employee everyday
  • Money, commuting is expensive, parking, food, clothing
  • Geographical limitations to hiring
  • Geographical limitations to growth
  • Flexibility – work is usually relatively inflexible
  • Meeting space is often limited by physical space
  • Growth is limited by physical space
  • Work-life balance.

But how do we maintain all or most of the benefits when remote?

What I have found odd is that since going remote many people have accepted that they have ‘lost‘ all of the benefits of a physical office. They have adopted a stance of mitigation of the loss, often abandoning practices that made them successful. I would like us to take a deep breath and look at the benefits and ask ourselves “can we achieve the same outcomes in this new environment?”. The benefits still hold true, let’s not just accept them as unattainable and look for ways of reaching the same outcomes.

Co-located Teams

I see some underlying themes in the benefits, many relate to the productivity benefits of co-located teams. In software delivery at least it is acknowledged that co-located teams are significantly more productive. The speed of feedback looks is a critical factor in building complex and often ambiguous situations. There is rarely one solution to a software problem and the ability to discuss and pivot quickly is crucial. This benefits significantly from real-time interactions and fast response times getting answers to questions quickly increases productivity.

  • Teams are more productive when able to interact in real-time
  • Teams are more productive when they are close to each other
  • Reduced feedback loops, people you need are right there
  • Team rooms enable teams to be more effective as those needed are all together

Collaboration and co-location of teams is a crucial aspect of an Agile mindset, I believe we should be focusing on tools and processes that enable ongoing interactions and collaboration. We have too long focused on planned video conferences with set start and end times. That is not how most of us are used to working, we want ad-hoc and ongoing interactions with our teams. We want to feel co-located and able to freely interact and communicate with them. This is a significant gap in the market for online collaboration tools.

It is also evident that the current trend is to focus on asynchronous work and flexibility for employees. Companies leading the way with this have a heavy emphasis on 100% flexibility and asynchronous work. All work communication must be in writing and have the expectation of a delayed response. The goal being working around the clock and extreme flexibility for employees.

However, the cracks in this policy are already beginning to show. Flexibility is alluring in the short-term (not to mention the west coast salaries) but the lack of human interactions becomes a strain very quickly and they are modifying their model to include scheduled non-work interactions with colleagues to offset the lack of engagement and need for human interaction. This is hard to make work as it feels forced and artificial unlike ad-hoc natural interactions that occur when you are working in close proximity with each other. I personally favor a highly flexible work environment that balances large amounts of online co-location and collaboration. Our teams have similar working hours with a target of a number of overlapping hours each day where they work in the same virtual spaces having natural interactions. This works much better and is building relationships in a natural manner rather than forcing it.

Sense of community

Engagement is very difficult to measure but is a significant factor in the success of a business, many businesses put a great deal of effort in to their culture and identity and in the desire to have their employees feel they are part of something. To build relationships with co-workers and leadership. We have discovered that the better those relationships are the more successful the business will be.

  • A single location where all work colleagues can come together
  • We value casual interactions with co-workers
  • Creates a sense of community
  • Accessibility to leadership
  • Shared information – Build information Kanban, Working agreements
  • Visibility and Accountability of employees
  • Meeting rooms enable people from different teams to interact with each other

Results from a Gallup survey of US employees showed that more than half of respondents who said they had a work best friend also reported feeling passionate about their job, with a strong connection to their company. Only 10% of people who didn’t have a close friend at work could say the same.

There are numerous studies on this topic and the conclusion is generally that friendships and relationships at work have a direct correlation to productivity, engagement and turnover.
The sense of connectivity to your peers has a strong correlation with mental and physical health as well as productivity.

In my opinion this aspect of work-life has been grossly under appreciated in the transition to remote working. The focus has been on flexibility rather than engagement. I believe this is short-sighted and that in the long run putting effort into encouraging and enabling employee interactions will be far more beneficial than flexibility.

Presence for Customers and Candidates

A physical location provides a destination and a statement to potential customers and employees. It allows visibility of how the business operates. It allows a more significant connection for people.

  • Location for Sales meetings/meetings with clients
  • Ability to show working arrangements to potential customers|
  • Enhanced recruitment experience
  • Proximity to clients

This is perhaps the hardest to see an obvious remote alternative too. Obviously a significant internet presence is essential these days but most sales is about building relationships and establishing trust. This is so much slower and harder from a remote setting. However, it does open opportunities for co-working where companies are able to collaborate together and to see the teams working in real time.

Summary

Having created and managed a remote office for the last two year it has become evident to me that for us to achieve the same outcomes from a remote office as we have in a physical office we need to ask why we do things the way we do. We should seek the appropriate outcomes. In my opinion success in the transition to a remote office is built on four pillars.

  1. The ability for spontaneous interactions. Absolutely minimal barriers to ad-hoc conversations and interactions with your co-workers. And when I say minimal I mean minimal, every click, every text message, every potential second lost is a barrier and impedes the flow of communication and hurts productivity.
  2. A sense of situational awareness. Knowing who in your team is online and available, who is offline where people are and who they are currently interacting with is crucial to enabling the spontaneous interactions and creating the feeling you are part of an energized team.
  3. A sense of proximity or community. Feeling close to your team, the ability to casually interact with them and closely collaborate helps build relationships and creates a sense of engagement. This leads to higher productivity, lower turnover and better mental and physical health.
  4. Finally the ability to interact in small groups, the one constraint that being remote does create is the ability to participate effectively in discussions, multiple small groups is more effective than large groups even in physical offices but being remote this is magnified.

It is my belief that an effective long-term remote office strategy should be built on these pillars. It offers a great balance of flexibility with collaboration and interactions. It is great for both employee and employer. I’d like to see more tools supporting this way of working and more businesses acknowledging the need for interactions.

Is Efficiency the killer of projects?

I have worked in software delivery for over 25 years now and in that time I don’t recall ever hearing of a project being cancelled due to lack of efficiency. By contrast I have seen numerous project cancelled because of misguided decisions in the name of efficiency. The most common is where team decide to build out infrastructure or data layers or business logic that they “know they will need later” and it is more efficient to do them now. The team works really hard but the client sees little or no progress and cancels the project. This sadly is something I have seen far too often.

This thought process is anti-Lean and it is anti-Agile but still it comes up daily. Teams anticipate future work and prepare for it, they over engineer stories or add elements that were not requested, “while I was here I added somethings we will need later”, all the time giving the impression to the customer that progress is slow. The team themselves feel they working hard and are adding value by being efficient. This lack of alignment between team activity and customer priorities and expectations almost always results in customer disappointment and teams feeling underappreciated. Since it is the customer that pays the bills misalignment with them is destructive to a project. That perceived future efficiency is never realized because the project doesn’t last long enough to benefit from it.

So why is it that we see efficiency as such a powerful virtue despite evidence to the contrary?

The sooner begun, the sooner done

proverb

A lot of it stems from misguided definitions of efficiency. From an early age many of us are taught that the sooner something is started the sooner it is finished. Or if you don’t start it, it will never get finished. We have a bulk buying culture and a bulk buy mentality. The belief that over time we will save money or make efficiency gains. What we don’t think about is opportunity cost or what the trade offs are for our actions. These costs in general far out-weigh any efficiency gains.

ArtShine Cash Flow is King in your Art and Design Business - ArtShine

Cashflow is king

82% of small business closures are due to cashflow rather than profitability. It is not that they are not profitable but that they don’t have the cash available immediately often because it is tied up in unsold inventory or materials waiting to be processed. This is essentially the same manifestation of what is happening in software. We are tying up our time and energy in future potential and we find the project gets cancelled before we get to profit from our efforts. Value to customers is like cash is to businesses. It is no good telling a customer we are accumulating value for later when they need and expect the value now.

So the claim that the best way to get something done is to begin is only half right. The best way to get something done is to finish what you started, before starting something else. If we pay more attention to starting than we do to finishing we end up with many started jobs and very few finished jobs. We need to reverse our sense of efficiency to see value in finishing jobs and efficiency in completing work sooner rather than starting more jobs or extending them.

Stop starting, start finishing - Post by Campo on Boldomatic

Stop starting, Start finishing

Whether it be software or manufacturing the efficiency we should be striving for is reducing the number of activities in progress. Be efficient in how many we complete, not how many we start. Starting on something that will not be finished until much later will more often than not create additional work in maintenance and confusion, not to mention the more valuable work that could have been done while you were being ‘efficient.’

Let’s reevaluate our understanding of efficiency and let’s stop starting and start finishing.

Remote work doesn’t have to mean working alone.

I have seen a number of articles recently that refer to the stages of remote work or maturity of your remote team as a linear progression to only one possible Nirvana. The Nirvana in question appears to be 100% independence, 100% asynchronous communication and no need to ever have any work-related human contact at all. Some companies even go so far as to explicitly not allow work related conversations insisting that all are in writing to avoid knowledge silos.

Whilst I understand the reasoning I find myself disagreeing with this conclusion. Yes – Being remote opens up the possibility of hiring from anywhere in the world, which means that there are the potential of round the clock time zones. Yes – being able to work whenever you want around your other commitments and family demands is an amazing benefit. And Yes the inevitable consequence if those are taken to the limits can lead to a conclusion that effective asynchronous written communication as the necessary means of communication. But it is not the only possible outcome.

For some companies especially those embracing full flexibility or round the clock time zones this may be desirable on some level. But I do not see it as the inevitable solution nor a desirable solution for all. Just like in the office there are different solutions depending on the circumstances.

How much flexibility is necessary?

Not all companies will have employees around the world or even want to. Many will already be in a single time-zone or a few closely connected ones so time zones are not an issue. And when it comes to flexibility how much do you really need? Is that flexibility worth trading human contact?
I used to work in an office, including drive time I was committing a 10-11 hour block of time every day. Now I am at home we adopt a core-hour system where we ask people to be available for meetings in a daily 6 hours window. Essentially if there is a team meeting booked in that time period we expect you to make every effort to be there, but this gives a huge amount of flexibility. I have more flexibility than I could possibly need especially in comparison to an office. I have gone from 11 committed hours to 2 or 3 per day with a lot of flexibility around that. Some may want more flexibility than this but if it means giving up human contact that extra flexibility comes with a very high price tag.

If I have sufficient flexibility and I don’t need round the clock time zones, why then would I choose a policy of avoiding human contact? In a pre-covid world it has become a widely accepted truth that co-located cross-functional teams are more effective and more productive. Agile prefers Individuals and interactions over processes and tools, and Customer collaboration over contract negotiation. I’ll happily trade some small loss of flexibility for a highly interactive and effective team.

Our History

Two years ago when I was asked to create an all remote Agile software development office I began with the assumption that this meant effective interactions and extensive collaboration.
The principles behind the manifesto spell out some essentials:

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

None of that supports asynchronous written communication. So you could say that we went against the crowd when creating a remote workforce as we prioritized real-time human-human interactions and rejected, where possible, written interactions.

We should be pioneers in creating remote Agile teams with a focus on co-working and collaboration.

The path less followed

Going against the crowd is always risky, but part of being Agile is that We are uncovering better ways of developing software by doing it and helping others do it. At the time I felt we were in a position to experiment, not with remote work, that was a commitment the company had made, but on how we implemented our remote office. I worked very closely with a like minded colleague and we came up with a plan for Remote Agile Teams. We decided that we would become pioneers in creating an environment for remote Agile teams with a heavy focus on co-working and collaboration.

We were already largely working as external contractors and not in a situation where we were working as closely as we would ideally like with stakeholders. Just like everywhere else, business-side stakeholders are busy and we were often limited to planned meetings and infrequent touch points. It became increasingly apparent that remote working actually gave us more opportunities to work closely with the business side. Perhaps not face to face physically but our interactions were more effective and more frequent than before. This increased interaction has led to far better outcomes. Because we were all remote there were fewer barriers to interactions with clients.

It was liberating to witness business-side representatives reduce their turnaround time on critical features. It was nice to no longer worry about booking our highly sought-after meeting rooms. And lastly, it was reassuring to realize that the focus should not be on face to face but on determining the appropriate form of communication given the constraints. With a newly established and excellent track record, we began reevaluating these principles and felt confident enough in our abilities to embrace the spirit of the Agile principle and even build upon them in a virtual office setting. 

But to do so we needed the right environment, an environment where business stakeholders and delivery teams could effortlessly work closely together daily. Real-time collaboration was key, and we intentionally removed as many barriers as we could to allow for effective communication channels. We relied on training, the right tools, and clear expectations to make this happen.

Is Remote Work compatible with our software delivery practices?

As we follow the Agile principles, we were heavily relying on practices like Pair Programming, Mob Programming and Test-Driven Development. We strongly encourage automated delivery pipelines and team ownership of the code and of the product.  In a remote setting, this posed a challenge as we had to consider how we would ensure effective communication and how to deal with connection lag. 

To be successful we needed tools and environments that enable our teams to continue with pair programming just as they did in the office. In the office, developers would typically share control of a single computer but with two keyboards and two mice attached. Remotely this posed a harder challenge as we also had to factor in remote communication and lag. The ability to share screen control, see the same things, and communicate clearly in real-time became a challenge. It was crucial to find the right tools for this as it was far more complex than simply sharing a screen.

There were other practices that we needed to support remotely such as stand-ups and retrospectives which are closer to meetings but have individual attributes that needed to be maintained in a remote setting.

Proximity, Awareness & Spontaneity

In looking for ways to enable remote work effectively we did a lot of research and experiments. In our research three terms came up again and again. Proximity, Awareness & Spontaneity these are not simply features of a tool, but words that describe feelings people want to have when using a tool. Software to support remote workers like this is not just a collection of functionality but a virtual environment where we are able to recreate human to human interactions. The best tools allow people to engage on an emotional level.  We added breakout rooms as a 4th pillar to round off the expectations we had for a remote environment.

Summary

We created a virtual environment where collaboration and co-working was enabled, supported and effective. Yet, we didn’t follow the ‘standard’ work-from-home model that most remote workers are used to. Our environment can be described as a flexible all day interactive workspace which expects ongoing, frequent, and sometimes sporadic communication. We created a sense of situational awareness of our environment and of our colleagues to allow for spontaneous conversations between our team members and between our teams and our business-side stakeholders. We feel close to our colleagues and have minimal barriers to interactions with them. We have an environment where pairing and other agile practices are not only supported and seamlessly enabled but are effective and productive. 

We are a workplace that routinely over-communicates, extensively collaborates, and empowers team members to quickly discuss a solution and make decisions. We are able to do this throughout the day and often with short-notice or no-notice. We have working agreements that support variations in time zones but also reflect a need for high-frequency interactive collaboration. We have tools and policies that preserve our culture but allow us to grow and evolve with new work techniques. 

In short we are Agile in a remote setting. We believe we are pioneering an alternative to asynchronous working and are hopeful that this is the start of a rapid growing trend.

Two years ago I was asked to set up a remote office with the intent to grow an additional option for our employees and clients. Today we have numerous teams working in this environment, and due to Covid we now have over 500 software delivery team members working from home but still together, we are based all over the USA and in the UK. The patterns we set up for 100 employees scaled seamlessly for the rest of the company So after two years working with remote Agile Teams we can confidently say that not only is it possible to have remote Agile teams, but that they thrive and are exceptionally effective.

Tic Toc – Productivity Experiment

Have you ever noticed that late projects only ever seem to get later?
Why is it that any gains get absorbed and delays get compounded?

builder + plumber

Let’s say I have a mini-project where I have a builder adding a kitchen to a house, he will construct the walls and then I’ll have a plumber come in to install the pipes and fittings. The builder estimates 4 days and the plumber 4 days.

If the builder is done sooner, say after 2 days, that gain is lost as the plumber was expecting 4 days so is not available until the originally planned date. If however the builder takes longer – say 6 days then this impacts on the plumber and at best delays him by 2 days, but more likely he has other commitments so it may result in delays beyond the 2 days ‘lost’ by the builder if he has to reschedule.

The only way to avoid this is for the plumber to build in slack before and after the planned job which is not practical unless he significantly inflates his fees to enable that level of flexibility.

That is a very simple example of a single dependency between two variable events. The majority of systems have chains of dependencies, each compounding this problem for every additional link in the chain.

Just think about your Doctor, they make appointments every 15 minutes throughout the day, if the average appointment lasts 15 minutes then it is likely by the end of the day as any appointment that runs over will delay the next appointment but any time they get ahead the patient hasn’t arrived yet. By the end of the day they may be running a long way behind and relying on your slack time to ensure you get seen. These are just a couple of examples of the Theory of Constraints in action.

Team Activity/Experiment

I’d like to share an activity I have been using in training classes to help people understand the impact of variability, constraints and dependencies on a system – including and especially software delivery. The principles are not limited to software or manufacturing but apply to any system where you are dependent on someone or something. It also shows how improvements in the wrong area do nothing to help your team.

I find learning is best cemented when you can take a group and have them look at a problem in a particular way so that they discover the solution and form their own understanding. No matter how respected the teacher offering solutions is they will never have the same impact as when you discover the answer for yourself. This is why I love teaching in a way that involves experiments.

The Experiment

The activity is best played in groups of 4, this gives everyone a role (and a roll of the dice) and enough opinions to have a debate about the implications.

Each team starts with 4 workstations or 4 stages in a workflow.

Each team starts with a backlog of work (a pile of blocks) and each block must flow through each workstation.

Tic Toc slide 1

In any given iteration, each person in the workflow has the same potential output/productivity and is represented with the roll of a dice.  The dice roll simulates a perfectly balanced system and allows for the variability of work: some tasks are easier or harder than others and some days we are more productive than others, but in this simulation we are all – on average – equally capable, we are perfectly balanced.

We run for 10 iterations. Each iteration is started with the first person will perform their work by rolling the dice, moving blocks, and passing the dice on to the next person. Any unmoved blocks remain in progress until the next round, and so on until each person has completed the work for that iteration. Each person in theory is capable of producing an average of 3.5 units of work and after 10 iterations the system at worst case will produce 10 units at best it will have produced 60.

Over 10 iterations, each workstation has an average capability of 35 units, all workstations have identical potential capability. If everyone worked at average productivity the system should be capable of producing 35 units of work.

Planning based on potential capability

This is very similar to the planning process in Scrum where planning is based on estimated times for all tasks. With planning based on the sum of the duration of all tasks being equal to the amount of time available in the sprint. E.g. 10 days worth of team effort in a 10 day sprint.

In the game, we ask the teams to predict the system output, and challenge any team that predicts a system output of less than 35 to justify why they are expecting their workers to be working at below their average potential.

This can be an interesting debate. Some suggest that people are not as variable as dice, or that stories are not as variable, but this usually results in debate and finally agreement that in fact people are MORE variable: tired, hungry, sick, bad day, good day, vacation, level of experience or familiarity with the job at hand etc. all result in huge variation in the person’s output on any given day. Stories can be split to be a smaller size to reduce variation in theory, but the complexity varies. Some need input from 3rd parties, some will go smoothly while others will hit issues, some take longer depending on who is working on it and so on. We take steps to reduce variation but we cannot eliminate it completely. We rarely know everything, so there will always be some surprises.

This conversation is crucial to understanding the the problem that most of us routinely overlook or choose to ignore despite the massive impact on throughput. We allow this conversation to flow to help people understand the fundamental variability in any system.

By the end of the conversation normally there is consensus that variability is the normal situation and a dice roll is an adequate metaphor, albeit real life is far more volatile.

First Iteration

In the first iteration, the teams will be set up so that each player rolls the dice and passes the appropriate number of blocks to the next player, and then that player rolls and passes, and so on until all players have ‘worked’ for that iteration(cycle).

We then repeat for 9 further iterations(cycles) and observe the outcome.

You can run this experiment for yourself and play along here: Tic Toc Game

In general, the result will be an average output of around two-thirds or a little more of what would be expected – e.g. around 23-27 out of an expected 35.  Sometimes more, sometimes less, as you would expect when introducing variability but the average for the room is typically in the ~25 range.

We ask the teams to explain why they are running at 70% efficiency and what is going wrong. This usually results in one person being identified as being unlucky or consistently rolling low numbers, but generally there is some understanding that there is a reason for it.

At this point you can dive deeper but usually there is sufficient belief that luck is a factor so you may need them to play again for some to accept that it is not luck.

Conclusion

By running the experiment a few times people generally begin to realise that the nature of variability and dependency have a pretty significant impact on one another and that creating a balanced system is actually pretty futile. We can improve the situation by reducing the dependencies, cross training people or giving them more autonomy – one of the principles of agile is to have a team with everyone needed to get the job done – this is because of this situation. Dependencies have far more impact on productivity than most people are willing to accept. The other factor is variability, whilst there is no way to remove variability completely, we can strive for smaller stories. This is one way of limiting variability. When it comes to humans it is even harder to remove variability, but if we strive for a sustainable pace and a good working environment, this reduces variability even if it doesn’t remove it entirely.

Tic Toc – Cumulative Flow diagram

Second Iteration

This experiment shows what will happen with a perfectly balanced system, but what is the impact when you have an unbalanced system or add WiP (Work in Progress) limits to a system? And have you ever wondered what the financial cost of big deployments was, we can experiment to see the how much it costs to have daily deliveries compared to monthly or quarterly deliveries.

In the next iteration we can explore the impact of an unbalanced system, where your system has a bottleneck and how you can deal with it.

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.

First, do no harm.

Medical students are taught early to carefully consider the possible impact of their actions, this often translates to a bias towards inaction. A paradox when many of us consider them as being ‘fixers’.

“Given an existing problem, it may be better not to do something, or even to do nothing, than to risk causing more harm than good.”
This reminds physicians to consider the possible harm that any intervention might do.

The rationale behind this is that the human body is a marvelous piece of engineering and has an astonishing capacity for self-healing. A staggeringly high proportion of injuries, ailments and afflictions will simply fix themselves if we do nothing, and almost all remedies come with some risk of side-effects or unknown complications.

Which is why a doctor will often advise rest of some description, or suggest that you monitor and come back in a week. Or they will prescribe a low dose of a low risk remedy to buy time for you to heal, this gives you confidence they have acted and the time for you to heal.

Physicians are therefore faced with the certain knowledge that doing nothing will in most cases result in the problem resolving itself and the certain knowledge that any remedy bears some risk of harm. And yet their chosen profession is to help, they chose the profession because they are motivated to ‘act’ to help people. Helping by inaction is excruciatingly difficult for people with a desire or bias to act, their desire to act very often overrides their desire to help. This is compounded by patients that expect action even when no action would be better.

For a physician the real skill is the ability to evaluate which situations from the multitude presented truly require intervention and then diagnosing the correct intervention.

Management

A similar phenomenon occurs in management. As an organisation typically we structure teams to be largely autonomous (or have delegated authority), we hire individuals who are capable of getting the job done without regular interference from management.

The rationale behind this is that a human body self-organizing team is a marvelous piece of engineering and has an astonishing capacity for self-healing improvement. A staggeringly high proportion of injuries, ailments and afflictions problems the team will simply fix themselves if we do nothing, and almost all remedies interventions come with some risk of side-effects or unknown complications.

So our starting position should be non-interference, if you hired the right people and they are structured effectively they should be able to resolve most situations themselves. Intervention should be an abnormal action not your go to response.

The problem is that we are humans: managers generally become managers because they have a bias for action and because they care (either about the people or the work or both). They also suffer the most horrible of curses, they are curious.

When an employee comes to you with a problem or you observe something that sparks an interest we as curious fixers have an overwhelming urge to jump in. We want the details, we want to help, whilst the person is describing the problem we are evaluating and preparing a response, an intervention of some kind. We are so interested in a situation we forget to ask whether it is in the interest of the individual or team for us to be involved.
We forget that we lack the same level of information, or context or situational awareness. We substitute this for our experience and opinion. Don’t get me wrong we hire managers for their experience and opinion, but like any tool it must be used judiciously.

I see this happen over and over, especially in a matrix organisation, a variety of managers become aware of a problem, often trivial and want to ‘help’ but the reality is that the responsible party – either the team or the responsible leader is already capable of resolving the issue and is already acting, but now they must also to respond to your advice, they must keep you informed and as the situation escalates the number of people to inform and respond to grow and becomes a problem of it’s own. The lack of context may often result in bad advice that the team feels compelled to follow because of the assumed authority of the manager giving the advice.

Æthelred the Unræd
This chap is Ethelred the Unready, king of the English (Not England), the poor man has gone through history with this title. But in this context Unready is somewhat unfair pseudonym for him. The Anglo-Saxon noun unræd means "bad advice" or possibly "evil-council" it is not a reflection of him being unprepared. He was badly advised, he came to the throne at 12 and suffered from interference from his political advisers.   The bad advice he received has led to a reputation for over 1000 years.   

The true gift of a leader/manager is the ability to listen and evaluate when it is beneficial to act and when it is better to let the situation resolve itself in an acceptable fashion. And that there is the stumbling block suffered by many inexperienced managers, they see a situation and possibly even a potential solution and they ‘know’ they could handle the situation better. They would handle it differently and want to step in. This inability to delegate and to trust others is the hardest part of management and the part where most fail.

Just like physicians, the true skill of a manger is knowing when to intervene and the strength of character to sit on the sidelines and watch when your intervention would be unnecessary.

Agile and self organized/self managed teams

So what does this have to do with Agile Coaching? First you could very easily replace the word Manager with Coach in the last section and heed that advice. Teams in most situations could and should be able to resolve situations themselves. However, I am going to take a slightly controversial stance on this and suggest that in Agile communities we have taken that advice a little too far.

In many ways Agile has created a community that shuns medicine. We have heard that 95% of health issues resolve themselves and we have interpreted this as a belief that physicians are therefore completely unnecessary. Not only unnecessary but should be chased from the land with pitch forks. In essence we have become zealously anti-management.

I have been in a number of agile workshops where we assess the role of a manager and conclude that most of the responsibilities of a manager can and possibly should be performed by the team. #NoManagers This is a really great exercise and is very empowering for the team and will generally give them the confidence to step up and take ownership. The downside is that whilst in theory the responsibilities of managers can be delegated to the team it is not always possible to delegate big picture awareness, experience and capability. These tend to get dropped on the floor as they are only valuable when things go wrong.

Even Scrum Masters seem to be being shunned now in favour of more remote Agile Coaches or in many cases the belief that because SOME teams are capable of autonomy and have the necessary experience and understanding of Agile that they can function without support, that this somehow translates to ALL teams should function without ANY support. Companies will abandon Coaches, Scrum Masters or leaders of any kind and expect even relatively junior teams to make effective decisions.

In those 5% of cases where the team hits a situation they cannot handle they are by definition lacking the knowledge or experience or support needed to resolve it. We have moved from a situation of too much unnecessary intervention to a totally hands-off situation where teams are left to flounder, with no one willing or able to intervene. In some cases those that do step-in to assist are challenged as being anti-agile for undermining the team’s independence.

One of the key elements of a management or support role is the natural distance from the team, the ability to distance oneself and see the bigger picture, something that a team member can rarely do.

As an example I recently worked with a very capable and experienced team, they were working hard and getting the job done. The problem was they were not delivering value by the customer’s standards (not overtly articulated by the customer). Through a variety of small and seemingly insignificant events the situation had evolved. Early on there were some obstacles relating to a production environment that at the time and with the information available the team chose to postpone, choosing to remain productive(busy), later more obstacles arose and again the team didn’t want to slow down so chose a path that enabled greater utilization(rather than value delivery). The result was a very happy and busy team, they were getting a lot of work done. The team was unaware there was a problem until the customer grew frustrated at the perceived lack of value being delivered. The team would have eventually resolved this issue but the cost to the customer would have been considerable.

The Quest for Balance

This is a typical tale of a team optimizing for itself, there needs to be someone with an eye on the bigger picture and an emphasis on the entire system. It is hard to assume that every team has this, when it is a rare skill. Of all the responsibilities of a traditional manager this is the hardest for a team to replicate. The ability to see the system is the primary reason we hire managers/coaches/delivery leads/product owners/project managers, in my opinion the key skill to look for in those roles is the ability to visualise the big picture and to know when to act on this knowledge.

This is not a claim that teams cannot self organize or that managers are necessary in all cases. This is a request for balance and awareness of the bigger picture. Previously I talked about the greatest skill of a physician or a manager being the ability to discern when to act and having the strength of character to do nothing when it is unnecessary. The flip-side is true for teams, you cannot handle every situation without support, the ability to know your limitations and when to ask for help is a significant skill and highly underrated. But equally the willingness to listen to advice from those with a better view of the entire system is also crucial.

Yes the team might be able to resolve a situation eventually, but at what cost and who is footing the bill? The cost here is one of those ‘Big Picture’ areas that is often underrated by those who are abstracted from that. Self-organization is very powerful, but understanding when a problem is one that should be left for a team to resolve and when someone with a better understanding of the big picture should step in, is one of the hardest questions to answer.

Generally I like to believe inaction is best, trust that we have hired the best people and that we have set them up for success. But also being aware that self-organization is not a silver bullet and it comes with a cost that may not be appropriate to pay in all situations. Learning is costly and we do not learn from all failures. Having people prepared and skilled enough to act is crucial, knowing when to act comes with experience and not acting requires a huge amount of self-discipline.

By nature I am insatiably curious, I have an opinion on everything and I have a strong bias for action. Of all things not intervening is one of my personal challenges. This post is as much a letter to myself as anything else. It is a reminder to trust and to observe rather than prematurely act.

Advice on splitting stories

One of the most common reasons we reject people interviewing for coaching or product ownership related roles is an inability to grasp the purpose and value in splitting stories effectively, especially lacking an understanding of vertical slicing.

This is also a commonly requested topic for me at the meetup or speaking engagements. Yet it is a topic I have struggled to effectively explain. The conversation often ends up as a narrow technical example on certain techniques, or difficult stories or becomes too abstract for people to apply. In short it is a large and complex topic.

But this video sums up the notion of story splitting and in particular vertical slicing and the ‘why’ behind the method so perfectly that I felt I had to share it.

“Successful problem solving requires finding the right solution to the right problem. We fail more often because we solve the wrong problem than because we get the wrong solution to the right problem.”

Russell Ackoff

Dr Ackoff sums up the issue with the analogy of the parts of a car, if you assess the purpose of a car to get you to a destination then an engine alone is worthless, even the best designed and most efficient engine cannot get you to your destination. Until it is connected to the minimal set of features to achieve the user’s purpose it is useless and remains useless.

Building any feature that does not work end to end adds no value, and building any feature that does not support the purpose of the user also adds no value. But more crucially it is often the interaction between layers or between components that is the most complex aspect of any development, be it a car or software. and the notion that we can build an engine, and a gearbox and fit them together later and expect them to work seamlessly is laughable. But I hear it all the time in software design.

A system must have an aim. Without an aim, there is no system.

W. Edwards Deming

We’ll build the database first then add the other layers, or we’ll work on an API layer 3-6 months in advance of the front end. It is as if we assume that the integration is the easy bit and worse is the assumption that we have anticipated every need of the user (and omitted everything they don’t need) before we design and build the interface, and before we ask for any feedback. And yet as software designers; planners; and project managers we repeat this error over and over, never learning from the pain of not using vertical slicing for splitting stories.

I believe our fundamental attribution error is the focus on the blocks of functionality (the components of the car) rather than the interactions, and rather than focusing on the purpose of the tool and user feedback we plan for efficiency of the workforce. The result is an optimized workforce and an inefficient workflow. We create a sub-par product that has efficient working components but do not effectively work together, and generally this results turf wars over interfaces that do not match the use cases and last ditch efforts to fit square pegs in round holes.

We can learn so much from Dr Ackoff, software alone is not the system, software is a tool, it becomes a system only when it is in use. The only way we can know if the software is efficient is by putting working software in front of a user and for them to use it and give feedback. So the only good way to split a story is in such a way that you are able to get feedback from the user that helps shape the design or to assist in making decisions.

If a story cannot lead to feedback or use, then it has no value, it becomes inventory or work in progress, it is a liability rather than an asset. That Database or API layer that is built with nothing utilizing it is not benefiting you, it is waste, it is an over engineered liability and the pain comes when you integrate it with other components. This extends to unused data fields or unused end points, “we know we will need them later” is a poor excuse for creating additional WiP (work in progress).

Learning is not compulsory… neither is survival

W. Edwards Deming

We as Agile practitioners can learn so much from Dr Deming and Dr Ackoff we are building systems, and the development process itself is a system, if we applied a little more systems thinking I believe we could be far more effective.

But as Deming said “Learning is not compulsory… neither is survival ”