The Risks and Benefits of Agile Practices in Distributed Organisations
This is an edited transcript of the talk I gave at the Empowering Agile Greece Conference on 19.01.2021
In 2020, the question of Remote Work suddenly became pressing for a lot of organisations. While some companies (mostly in the tech and startup industries) already championed the question of how to successfully work together while not sharing the same physical location, for others, this proved to be the challenge of the year. And it looks like it will also be the challenge for the years to come.
On the other hand, a lot of things that were previously thought to be impossible suddenly became a reality. Take, for example, the genre of industry conferences. It would have been unthinkable before 2020 that most if not all conferences don't take place in a physical space, but are virtual events.
Yet, here we are. And it works. It's different, but it works.
But apart from that, we also found out that a lot of other things really are difficult in this new "Work from Home" world: For most of us, this sudden shift to work from home really put a spotlight to everything that is difficult when it comes to work and organisations.
For Agile this is not different.
Basically, Agile just got a lot harder.
But you could say now: Why care? With vaccines available (or at least: available soon) this whole Covid-19 thing will blow over sooner or later, and then we can all go back to normal.
I don't think you can.
Depending on who and how you ask, between 13% and 53% of people would want to keep working remotely.
And 88% of people who are currently working from home say that they do not want to go back to an office-only culture, and half of them would flat-out refuse.
Whatever numbers you want to trust, one thing is clear, and that is that the Monday/Friday 9-5 office job for knowledge workers is dead.
So we all have to learn how to deal with an ad least hybrid, if not completely remote work force. And one thing I learned about Remote Work is that it doesn't mix well with On-Premise Work. Those hybrid models where parts of the team work in the same location while others are remote have too many flaws and problems. If one person is remote, technically, all persons are remote. Otherwise, you have a mix of bandwidth between people that causes more harm than good.
That doesn't mean that the office doesn't have its place, and people will never return to the office, but its role will be radically different, and it will be used less frequently, and for very specific tasks.
Remote and Distributed are two different things
There’s a key distinction between working remotely and working in a distributed organisation: You can work remotely from your home, doing your job. But when you collaborate with others, who also work remotely, you are in fact a distributed organisation. “Remote” needs a “center” you’re remote from to make sense. But what if there is no center any more?
And the key question we’re all facing is: How can we collaborate when we don’t share the same space?
“Same space” is something of a continuum here: From literally sharing the same space, to sharing the same time, to sharing neither.
There's a lot to say about Agile in remote settings and distributed organisations, but I want to focus on one particular thing:
The first Agile Value, why it's so hard to get right in distributed environments, and what we can do to mitigate the Bad and amplify the Good.
Individuals and Interactions over Processes and Tools
I think this value is at the heart of Agile. The first step in working together along agile principles is to get people to talk to each other and start working together. Instead of next to each other.
I'm confident that all the frameworks and methodologies we've developed for Agile still work, and we don't need to talk about how to adapt the core of those frameworks (some mechanics need some tweaking, though). It's more about the changes we need to make around those frameworks.
The radical change in how we work together that took place during the Covid-19 pandemic caught a lot of us by surprise, and ill-prepared. The initial (and natural) reaction to this change was to transpose our office culture into the virtual realm: Literally transferring everything we did in the office 1:1 into our new, distributed setting. A fitting description for that is "office skeuomorphism": Making our virtual space look like our office space.
I guess that by now, most companies have tried that out, and have mixed feelings about it.
The danger in that is that we tend to over-process and over-tool, and in the process eliminate interactions, and therefore reduce collaboration.
So, what is the Risk when working with Agile Principles in a Distributed Organisation?
The Risk is that we fall back into some sort of Agile Theatre, where we pretend that we’re working agile, but instead just follow our procedures.
We emulate Agile how we used to do it, hoping that we'll be getting the same results.
Does that work? No.
Instead, we need to critically look at what actually did change, and how we deal with that very specific changes and the challenges they create. Bonus points for us if we also look at what benefits we can get from those changes, what things get easier or more rewarding in this new setting.
For me, there are a couple of things that are at the core of how we work together, and I want to briefly discuss how they changed:
Rituals are our ways to meet and create togetherness as a group, but also the way we convey information and meaning.
How are we doing that in our office environment? What are the rituals that do that for us? And are those working well in a distributed environment?
Now is great time to question the reasons why your rituals exist, and if there is a better way to reach these goals.
An example: A typical ritual for groups of any sizes is a staff or team meeting, or an "All Hands" meeting typical for startups, or Townhalls for larger organisations.
What is the reason for holding these meetings? Conveying information? Maybe a posting on an internal message board or blog would do a better job for this? Creating togetherness? Is sitting around listening to the CEO talking about the current state of the company really the best format for creating bonds?
For most leaders, moving into the direction of distributed organisation was not a deliberate decision. It was driven by external factors, most notably the current pandemic. That means that most of them were pretty unprepared when the shift came. And the big question is: Is the role of leaders different in a distributed organisation?
The answer is: Yes.
In an office environment you can practically lead as close as you like to. Regardless of wether it's sensible or wanted, you can do it. In a distributed setting, leading with a command-and-control attitude is simply no longer as possible. As Darren Murph, the Head of Remote at Gitlab, put it: A leaders job in a remote setup is being an "unblocker".
You make sure that your contributers can do their work and create. By giving them advice when they ask you for it, or by removing problems they cannot remove themselves. To be successful in this role, leaders must position themselves as mentors and coaches. They need to be available for their contributors when they need them, and not check in on their team members ever so often to see "how it's going".
In office environments, collaboration typically takes place as a form of ad-hoc collaboration. You drop by someones desk, as them a question, have a coffee together or go for a quick walk. You can ask questions big and small, and interactions are typically barrier-free.
In a distributed environment that is defined by software tools, this is no longer possible. Instead of having this kind of low-barrier, spontaneous exchange, you need to setup a Zoom meeting, find a spot in calendars where everyone is available, a bit of a back and forth if that meeting is really necessary, and everything else such a formal event entails.
And what we're seeing is that people actually do that. Every small interaction suddenly becomes a 25-minute Zoom call (because 25 minutes is the default for most organisations).
And as Cyril Parkinson so famously said: "Work expands so as to fill the Time available for its Completion." If your meeting is scheduled for 25 minutes, you can bet that it takes 25 minutes. At least. Even if what you're talking about could be solved in 2.
To combat that, one thing you can do is bundle those many smaller meetings into fewer, but more substantial meetings. I bet you can even leave the 25 minute timebox, but try to cover more ground in them.
Also, there's the inherent danger in such an environment that the quiet members of a group don't contribute in group calls and are no longer heard. It's vital that they are addressed and heard!
If you're moving from ad-hoc to purposeful communication, you'll inadvertedly introduce lag: When you ask for feedback when it's convenient for the other person, instead of asking for it immediately, you have to deal with the fact that you're waiting for someone else.
Use this time to work on a different project, until you reach a point where you're waiting for someone else on that project. Then, move back to the first or on to the third, depending on wether your first project is unblocked. I'm not advocating multi-tasking here. On the contrary, I don't like multi-tasking at all. I'm advocating multi-projecting, were you're having a couple of things in the pipeline to minimize downtime.
And if you do find yourself in the situation of having some downtime, go for a coffee. Seriously.
Oral and Written Cultures
Office culture is pretty much oral, especially if the tribe is small. By that, I mean that knowledge is stored in heads, and transfered by talking, mostly in a 1:1 situation. This has a couple of implications: For one, this type of knowledge transfer does not scale. Second, brains are lousy storage containers, and information kept in them is prone to loss, or distortion. Third, it is very repetetive, because the same people tell the same things over and over again. And finally, it is a process that works only synchronously, meaning that one person is talking, and the other one is listening, both at the same time.
Text chats in Direct Messages are a fringe case, but mostly the limitations of oral culture apply to them as well.
On the other hand, written culture, where information is stored and transferred in written format, scales indefinitely, can be preserved over time, and needs to be created only once, while it can be consumed many times. It is also asynchronous, meaning that creation and consumption of information do not have to take place at the same time.
While oral culture is in principle independent from physical space, written culture is independent from space and time.
With written culture, you can move to asynchronous communication, which is very advantageous in distributed organisations.
But just moving everything from spoken word to written text is not enough. You would probably re-create the fragmentation of knowledge sharing in a written text medium. Create a Single Source of Truth (most orgs call that a "Handbook" or similar), and make sure it is accessible and searchable for everyone. Create all your knowledge in this medium. All of it. Even if it seems overdone right now. You'll thank me later.
Every place has its culture. Usually, we learn about it by picking up cues. How do people look like when they are working? How many are behind screens, how many are sitting in front of a whiteboard? Is the coffee maker orphaned, or are groups of people hanging out around it? Do people talk shop a lot, are they taking about things unrelated to their work?
When it comes to how a job is to be done, we learn by watching our colleagues and team members.
In a distributed organisation, this is simply not possible. Our interactions are always active, and deliberate, for better or worse. When it comes to understanding a place, this is not always and advantage. You simply cannot passively absorb the culture of a place while in a video call, or while reading text messages.
Humans don't work like that. Because of that, you have to be very explicit and very specific about your culture, your values and how things are done around here. Especially with new team members, and culture needs to be a large part of their onboarding.
For leaders, this means living your values and culture by example.
The way transparency is created in distributed organisations changes radically compared to an office-centric culture. The reason for that is that the style of leadership changes. Instead of checking in on your contributors and having them report their progress to you, let teams work in the open. Kanban Boards and Product backlogs work miracously for this, as do Scrum Sprint Reviews. If you're already practicing Scrum, you're at least half way there.
Distributed organisations require self-organisation. And self-organisation requires a different kind of goal setting. Make sure that your goals are outcome-oriented, and do not create a long list of output.
And another very important consideration: Transparency requires trust. There is no way people will be open and transparent about anything if they don't trust each other, or don't trust you. This also ties in with the way your organisation is communicating: The more conversations are not in the open, the less transparency, the less trust.
You need to be deliberate
These things don't get right by and on themselves. Your organisation doesn't automatically transform into a distributed org. Your team doesn't miraculously adapt and transform into a distributed power-house. You need to be very specific and deliberate about those changes. Leaders must be keen to experiment, to acknowledge their ignorance, and their willingness to learn. We are all in this together, and it's a new situation for all of us. Worst thing now would be to pretend we know what we're doing. There are organisations out there that do know that, and we can learn a lot from them, but we should be very careful proclaiming that we're one of them.
You need to acknowledge emotions
Change is always emotional. Always. And this is a big change. So expect accordingly sized emotions.
Not everyone is super-stoked on working in a self-organised, autonomous, self-defined way. A lot of people are afraid right now. For their future, their jobs, their health, the health of their families. Wether their skills are relevant anymore. What will happen to their workplace.
Reach out to them. Acknowledge those feelings. They are real, and important. We are facing a challenging situation. And a lot of people are looking for guardrails. Try to provide them with some. Either by your own leadership, or by creating structures that support and help everyone in the transition (ideally, both).
What happens when we get it right
Here's the interesting thing: While it is true that Agile gets much more difficult in distributed environments, it's also true that if we put some effort in it, it can be much more effective.
Why is that so?
What we get when we try to adapt to this new reality of distributed collaboration, we also remove a lot of organisational anti-patterns that hold back the effectiveness of agile practices.
What we get when we sucessfully adapt to this new, distributed world, is an organisation that encourages autonomy, self-organisation and outcome-driven action. All the things that we want to see in Agile teams and Agile organisations.
We support our goal of becoming or being an Agile Organisation by being a distributed organisation.
I'm not trying to say that an office-centric culture couldn't do that. All I'm saying is that distributed orgs need the same kind of dexterity as agile teams, and being distributed and being agile actually can be beneficial to each other.
I am saying, though, that you cannot run a distributed org in a Command & Control style of leadership if you want to innovate.
And I'm saying that if you do it right, you will end up with a workplace that is considerable more fun, more productive, and more humand than punching in at the office every morning at 9.