I have been very fond of Scrum and a strong advocate for it since my first introduction to it about 12 years ago. But in recent years I have not been exposed to it so much, my current organization favors more of a Kanban approach to software delivery.
However, this last few months I have been working with a new client who is using Scrum. I was invited to join their Scrum training this last week. And Oh my! As I was listening this quote sprang to mind.
“It was the best of times, it was the worst of times, it was the age of wisdom, it was the age of foolishness, it was the epoch of belief, it was the epoch of incredulity, it was the season of light, it was the season of darkness, it was the spring of hope, it was the winter of despair.”
Charles Dickens
This is where I get confused. I would appreciate comments from my friends in the Scrum community to help me rationalize whether I have drifted from the Scrum mindset or if I simply got exposed to an example of a dogmatic interpretation of Scrum.
The Daily Scrum
The trainer was talking about the Daily Scrum and how to keep it short. She suggested that – paraphrasing a little “the product owner being there was not only optional, but undesirable. The Product Owner being there encourages questions and conversation. Conversation and questions are bad, and a reflection that the Sprint planning was not comprehensive enough. If there is ambiguity in a story or the need for a question we should learn to get better at our planning.”
I was a little in shock. My advice is generally the complete opposite, that conversation is good, it is desirable and should be encouraged. I encourage the PO to be with the team all the time for questions. I will often encourage teams which have good interactions with the Product Owner to reduce the detail in stories and rely on the conversation more, for me it is the outcome that matters and not perfect planning. Over the years I have correlated the amount of text on the story card to inversely be a measure of the maturity of the team. (assuming they are producing value)
I was dying to jump in and disagree, but this was someone else’s training and I was there as a guest. But I did begin to question whether what was being said was a misinterpretation or have I misinterpreted and my move away from Scrum has resulted in practices which conflict with the Scrum philosophy.
The agile mindset
On the flip side and the other side of that quote I began with… I was on the training with the Product Owner from the team I am currently working with and I was astonished at how quickly he has grasped an agile mindset and how comfortably he has taken to thinking in an agile way. It took me a lot of time and effort to achieve the comfort level he is at. We have been planning an MVP and he has been simply brilliant, the conversation is about balancing value and necessity and it is impressive how easy it has been to navigate the usual pitfalls. Sometimes you get really lucky with your team, and the job is so much easier when there is an agile mindset at play.
I’d love to hear your thoughts on the Scrum question, let me know…
‘Community’ along with ‘engagement’ are two terms frequently thrown around by leaders as being important, critical, even crucial, and yet rarely do you get any sense of what the terms mean to them, or indeed to us.
We know they are important, but I do not get the impression that there is a sense of why, or how either can be achieved or how much effort is required for a healthy community to flourish.
I would like to propose that “Community is the overlapping and reinforcing groupings of people who form the foundation of an employee’s experience. These overlapping and intersecting communities enable higher levels of trust and a sense of belonging, which ultimately leads to higher morale and productivity.”
However, my observations are that uncoordinated and haphazard activities with no clear purpose are largely ineffective and in many cases work against the very community and engagement we are trying to achieve.
Without consideration to the underlying structure or the desired outcome, the activities can be fun, but large anonymous events or small interactions with people you are unlikely to work with in the future can be unfulfilling and draining. Both provide extremely limited value to the company or will lead to ongoing feelings of community.
Similarly, tools like Slack offer fantastic opportunities to interact but lack coordination or deliberate inclusivity and become more powerful when used as supplemental to other more targeted actions to build community. This type of interaction can reinforce community, but it is often intimidating as a means for creating the initial base level community especially when the numbers in the channel are high. More deliberate activities are better used as a catalyst to connectivity with Slack used as a venue for reinforcement.
“Employees leave bad managers, and stay for good friends”
We often hear “employees leave bad managers, and stay for good friends” This reflects the fundamental importance of the relationships with your managers and your co-workers. If we fail to address these two elements, the other aspects of a job become far less important to employee engagement. The result is higher turnover and low morale issues.
Turning relationships into a community
Most of us fall into a variety of tribes or smaller intersecting and overlapping groups. Some are organizational, some are shared interests, and some are proximity.
Prior to the pandemic and the move to remote work, proximity was one of the most powerful sources of community. Getting coffee, hallway conversations, small talk while waiting for meetings to start, lunch, even the elevator, these were all opportunities to interact and feel connected. Those interactions alone are not enough to build a community. But when paired with a secondary connection those bonds become stronger. Say you were on a team together for a while or you were both on the same training course, you watch the same TV show, or you both play football. When you add a 2nd or 3rd or 4th connection you become closer still.
Many of us crave those interactions and connections, we want to recognize others and be recognized ourselves. But how does that help from a business standpoint?
In business we have learned that teams that trust each other are more effective, teams who feel comfortable getting involved and speaking up are more productive, those relationships and connections create a base level of comfort and trust which enables more effective participation. Those friendships are not incidental to effective teams, they are a crucial part of becoming effective teams. Research also shows that having ‘friends’ at work is a significant factor in reducing turnover.
We do not need to be best buddies with everyone we work with but if we can overcome a sense of anonymity and start to feel we know others and are known by others. That is often enough to turn people from being a group to being a team.
It becomes more powerful too, when the manager, or other leadership are part of those tribes. Having a connection to your leaders builds that same level of trust with them, and the feeling that your manager knows you personally can be a powerful team building factor.
From a business perspective the key is to make those relationships force magnifiers. Create opportunities for overlapping and intersecting communities. Spend time getting to know your teammates and managers. Build relationships across roles or departments especially when you are likely to interact with them. Each additional connection with a coworker reduces that anonymity and helps employees feel more connected to the organization.
There are also subtle ways to build a sense of belonging and association, branded clothing is a badge of participation and when others wear the same you feel connected. Shared in-jokes and shared experiences all add to that sense of connection. The key is to incrementally build on the relationships in the communities where the benefit concentrates the impact rather than dilutes it.
Dunbar’s Number
“The people you would not feel embarrassed about joining uninvited for a drink if you happened to bump into them in a bar.”
Robin Dunbar
There comes a point when the community becomes so large that even with multiple connection points individuals feel that they are on the periphery or are anonymous in the crowd. Robin Dunbar (A British anthropologist) described this feeling as “People you would not feel embarrassed about joining uninvited for a drink if you happened to bump into them in a bar.” If we gloss over the British predilection for bars and think of it in terms of any groups which you would feel comfortable joining at a work event – uninvited. Dunbar suggests that for most people there is a pragmatic limit of 150 people we can feel connected to, and beyond that number feelings of disconnection and anonymity become common.
The lesson from this is to structure your teams or tribes into groups of 150 or less, with as many opportunities for reinforcing feedback loops and connection points. Structure work; events; activities; communication; and interactions to be as much as practical within groups of that size. This enables people to feel a powerful sense of connection, community, and engagement with that core group. That sense of security for being a member of a core group can give people the confidence to network beyond the group. But if you try to structure a community with a much larger group the result will be a lower sense of community and connection ironically with fewer people who feel comfortable engaging in conversations or activities. In this situation less is truly more.
Summary - Community is the core of employee engagement.
Structure work communities in groups of 150 or fewer.
Make time for social interaction – if remote be more deliberate about it.
Remote interactions are about 75% less effective than in person so expect to spend 4 times as much time on icebreakers and getting to know people than when in person to make up for the lost “incidental” interactions.
Activities should be organized with a view to ever decreasing concentric circles, the goal is more meaningful connections and more frequent interactions at each layer of the circles with the strongest connections with your immediate core team and your manager at the center.
If you limit the interactions at the core team, then you create silos – change becomes harder and the impact of restructuring and re-teaming can be overwhelming to some.
If you go too broad, then anonymity ensues with people not feeling at the center of anything.
More varied connection points build stronger relationships. Stronger relationships result in lower turnover and consequently more productive and happier teams. This is the ultimate win-win scenario.
The ability to have ad-hoc spontaneous interactions with co-workers is invaluable. In physical spaces understanding this led to the end of offices and teams being co-located. Just imagine going back to a physical office where everyone had an individual office and you could only talk to co-workers if you had made an appointment in advance. What would that do to productivity? Yet when we are remote that is exactly the guidance many of us are given when we are restricted to using Webex or Zoom for interactions with co-workers.
The good news is that most people have adapted to remote work very well and companies have found they have survived the Covid crisis without a major loss of productivity.
However, many are still struggling with a few very common problems. Generally we have become familiar with a few tools for communication such as Webex, Zoom and Microsoft Teams. These are all excellent tools but they are designed for planned meetings not for the work that goes on between meetings. I found thinking of them as a physical meeting room which needs to be booked in advance helped me relate to why there were so many challenges surrounding this and why we struggle to communicate things which would have been so simple in a physical environment.
1 – Slow feedback loops
This is perhaps the most common and most harmful to productivity and can really be put down to human nature. Think of the most frequent interactions you had with your co-workers. “Can you tell me where to find the expense forms”, “You said you wanted this to be green, which specific green do you mean?”, Most of us when in an office would have many quick interactions with co-workers, often in the form of asking someone nearby in the form of a very quick interaction. What this translates to in many remote settings is one of four outcomes
1. We wait, it isn’t worth a meeting for one question so we make a note and when we get to an already planned meeting we ask.
2. We wait until we have enough questions to justify calling a meeting. Naturally it would be rude to send a meeting request without sufficient notice so we delay, likely 24 hours or more. and You can’t have a meeting for less than 30 minutes so we fill that time with stuff.
3. We delay – We try to figure it out ourselves, in the case of new or inexperienced employees this could lead to feeling stuck until someone notices or not doing something critical.
4. We guess and potentially do the wrong thing and do not discover it is wrong until much later in the process which ends up delaying and costing more.
In all cases this results in delays, the communication cycles are slower and hugely costly, in almost all professions delays are expensive, the longer the delay the more expensive it becomes. Any reduction in those feedback loops is hugely valuable to productivity. We instinctively understand this when co-located but when remote our fear of interrupting someone outweighs our desire to get a fast response and our chosen tools add friction to the machine.
The right tools enable spontaneous interactions and encourage free communication, some features to look for:
See who is in a meeting prior to joining
View whether people are busy (talking etc.)
Pull others/invite others to join conversation
Turnarounds – Pull entire team together
Free transition between multiple breakout rooms
2 – Lack of team awareness
At the most fundamental level this covers practical considerations such as: I need to ask Sally a question, is she in a meeting, is she even in the office, is she busy. In a physical office I can look up and see a chair is empty or that she is talking to someone. I know immediately whether she is available or not and I know when she comes back.
But this also covers more subtle interactions: In a physical office I may observe that James is showing a preference to work on his own and has limited interactions, is there a problem, is he shy does he need support? All things that managers and co-workers notice when physically co-located but are often absent when remote.
Similarly there is the absence of data that is actually valuable. If you have a large team you may not notice someone is missing, but in a physical office if Jane doesn’t come to work we notice an empty seat and are concerned so we check that she is okay.
Team awareness is so important to effective team interactions, becoming comfortable with your co-workers leads to more effective communication, less barriers to getting things done and feeling more engaged and part of something more.
This is easily solved with the right tools and a mindset of being part of a team. Features to look for in the right tool:
Live information of who is online
Always on throughout the day
Live information of who is offline
3 – No sense of community or engagement
When coming in to a physical office you are immersed in the hustle and bustle of office life the background noise the comings and goings the sense of being part of a larger community. Even if you come in and put your head down and work you still feel a sense of being part of something bigger. At home this feeling is simply not there, if there is noise it is the neighbor mowing their lawn or children playing, dogs barking of noises that making you feel part of your home community. In a physical office you would see people and often interact with them even if your work does not require it you build relationships with work colleagues and with others you see in the office.
Zoom and Webex put the focus on people in the meeting, this lack of broader awareness is in my opinion detrimental to a community feel. In our office we use a tool which gives a greater sense of awareness, we can see others in the office and see them moving around and interacting with each other.
I encourage new hires in the office to shift their mindset a little and going to work is NOT going to your workstation in your house going to work is when you login to the virtual office, this mental shift moves you from working at home to working in a virtual office with others and (I believe) creates a sense of being part of a broader community.
This type of tool also gives visibility to those beyond your immediate team, I may spot Joe who I worked with on a previous team and can drop in a say hi to them, in essence it removes a lot of barriers and in many situations is able to recreate those watercooler moments and opportunities to stay engaged with co-workers
Features to look for in the right tools
All employees in one tool and visible to each other
4 – Zoom fatigue
This has been a hot topic over the last year and we have become aware that being on camera is draining and that whilst it is possible to turn off the video in a Webex or Zoom meeting the interface makes is very obvious that you have and that gives a different type of pressure. What these tools fail to address is that not all interactions are face to face “look me in the eye” conversations. Imagine that you and I are collaborating on a spreadsheet preparing a budget. We are both focused on the work, the data. If we were in an office we would be sat side by side looking at the work we would not be looking at each other. In our company we do a lot of pair programming where two people work together pretty much all day on the same computer if this were using video it would be exhausting not to mention the bandwidth consumption. We prefer to default to audio only for this type of conversation and switch to video when it is appropriate.
Using Webex and Zoom pushes you towards video and dominates your desktop. We are finding the right balance between video when it helps, and audio when video is a hinderance. This type of deliberate choice has really helped us be much more comfortable with remote working and it is far less draining.
Features to look for in the right tools:
Ability to focus on your work rather than being dominated by a communication tool.
Awareness of others rather than intrusion
Not all interactions are face to face “look me in the eye” conversations.
5 – Mentoring junior staff
I have heard a number of times that we need to go back to a physical office because we are unable to support and mentor junior staff. The issues stated seem to be similar to some of the other points. New employees need to ask questions and get support and would not know who to ask, they need regular interactions with co-workers, they need someone to reach out to, we need to be able to keep an eye on their welfare and see that they are settling in and so on.
When hearing this I do not hear anything which is not an issue in a physical office already, so this is a bit bizarre, I think what people mean is that they have found a way to address these concerns in a physical office. I don’t see anything here that could not be solved by challenging a couple of assumptions. The attitude displays some linear thinking that the only interactions are via tools like Webex and Zoom and that adjusting to communicating remotely is a learning curve and takes effort. What this thinking doesn’t account for is that being a junior in an office is already a learning curve, they are learning to communicate and interact, digesting the culture and politics, this learning curve exists already and for someone new being remote is a factor but it is not as much of a challenge as it is for those of us that have spent a career in an office and are now adjusting to being remote.
We solve this very much how we would in an office, ne staff are supported, they have people they can reach out to or shadow, and their support structure are encouraged to be supportive and available. Being remote is not a barrier to this type of interaction but a supportive mindset and appropriate tools are beneficial to making this effective.
If you are handing someone a laptop and say “call your manager if you have a problem” then I can see how you find this to be a challenge to mentor junior staff, but with a little thought and using the right tools being remote is not limited to more experienced staff.
Features to look for in the right tools:
Many of the features mentioned above are appropriate here, but with an added awareness by those supporting that remote work amplifies feelings of insecurity so more care is needed.
A well-oiled machine
When describing a high-performing team we often use the analogy of a well-oiled machine and I feel this highly appropriate when we consider the oil to be anything that reduces the friction in communication. The less friction we have the more effective the team becomes.
All of the struggles I described above are the result of barriers to communication, friction in the machine, the oil is in 3 parts:
1) having a mindset of effective communication – primary of which is a desire for tight feedback loops, no unnecessary delays if I have a question I ask it immediately any delay is counter productive conversely a willingness to respond promptly. If this is a challenge for you this can be relating the virtual office to a physical office and saying what would I do in a physical office and if it was acceptable there it should be acceptable here. Would I ask the person next to me, would I knock on a door etc.
2) Having the right tools, tools that enable spontaneous interactions with minimal barriers really help. Tools that provide situational awareness promote better communication and reduce friction.
3) Being deliberate in your actions and decisions. Thinking about why you do something and what is the outcome you are looking for. Many things happen naturally when physically co-located and when remote we have to consciously make an effort
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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?
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.
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.
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.
John Yorke 