Can a remote product designer achieve true agility?
Some background on me
My working methods were developed in and for balanced, co-located agile teams. I always took full advantage of being in the same room as the people I’m solving product design problems with. I advocated for and used physical artefacts over digital. Walls were covered in story cards, user journies, information radiators and cross-functional conversations were happening everywhere.
I’ve now been working as a totally remote product designer for almost 2 years. I live two hours north of Sydney, Australia in a small beachside surfing town on the Central Coast. The company I work primarily work with is based on the other side of Pacific Ocean in Santa Monica, California, USA.
I’m a Product Manager and also Head up Product Design. (Yes, I’m doing two roles at the moment)
My last role was based in Singapore working with an innovation, agile and software consulting company called Neo Innovation (Neo have since been acquired by Pivotal Labs). We also had offices in New York and San Fransisco.
As a product design and management consultant so I got the chance to work on a range of problems in different industries.
I’ve worked with many different teams of different sizes which all sat at varying levels on the ‘agility’ spectrum.
I came from a co-located, balanced agile team in Singapore consulting other companies on agile and design principles and processes to being remotely embedded in a new team as a Product Manager and Designer within a startup experiencing hyper-growth.
In this article, I’m going to articulate some thinking I have done on the topic of Distributed vs Remote teams and some of the challenges and learnings I have had the last few years adjusting.
What is ‘True Agility’?
Let us unpack the title of this article and my original question: “Can a remote product designer achieve true Agility?”
If we leave aside ‘Agility’ in terms of software and think about the true meaning of the word ‘agile’. The most suitable opposing word is ‘rigid’.
Organisations fit somewhere along an ‘Agility’ scale between being ‘Rigid’ and ‘True Agile’.
Some synonyms I associate with the word ‘Agile’ are:
In the context of software – ‘Agile’ is a set of guiding principles to deliver value through software better. ‘Agile’ is now used in many other industries other than software. I’m sure you’re well aware of the ‘Agile Manifesto’ so I won’t quote that here.
There are many processes and tools which help facilitate being ‘agile’ and hold true to the Agile Manifesto principles.
These are all part of what I call ‘The Agile Toolbox’. We can and should use these tools with varying intensity and frequency depending on the problem at hand.
‘Agile’ is not just for the people who write code, it is for everyone.
Many people still think in terms of finite projects with deadlines, departments and process stages with a different type of activity happening at each stage until finally everything is released all at once.
Here is an example you’re probably familiar with.
Design and Development happen separately. Your design team goes away and does design things until they have a solution. You create some mockups and requirements and hand-off to your development team.
Development happens, design and scope changes, deadlines are missed, people scramble, you release something that should not be released or your release nothing at all.
Sound familiar? This is a ‘Waterfall’ methodology. I’m not saying this doesn’t work. It works great if you know absolutely EVERYTHING about the problem space and solution before starting work. This seldom happens.
Any role or department involved in delivering value must be thought of as part of a ‘Value Delivery team’. They need to be working together all of the time.
As a remote product designer, It is imperative I work closely with the people who understand the things I don’t and have different outlooks on the problem space.
These people include:
- Internal teams
- Business people
Design and Development are symbiotic when it comes to software delivery. One can not exist without the other. Design is iterative and evolves just like code. Granted, design can an should happen ahead of development to some extent but ideally, designers and developers should be on the problem together.
A major (if not the main) part of a designers role is to take overlapping views, conflicting ideas, assumption and goals from these varying roles and bring clarity to the problem being solved. Designers no longer are the solo magic makers sitting in the corner with their headphones on. They are the glue that binds cross-functional teams together. They are the facilitators which bring different viewpoints to the problem space and form a hypothesis using EVERYONE’s input.
Delivering iterative perpetual value needs a balance of different people with cognitive diversity and behavioural attributes working together.
Their different thinking styles will compliment each other. This diversity gives us access to the entire problem-solving toolbox. Avoiding the concept of ‘Maslow’s Hammer’.
If the only tool you have is a hammer, you’d treat everything as if it were a nail.
Agile is a balance of the right mindset, the right team and the right tools to iteratively solve a problem.
This is a utopian way to look at this topic and pretty obvious considering how high-level it is. We have already established ‘agile’ teams vary in maturity and diversity. So, what is the “right” mindset and the “right” team?
What makes a high-performing agile team?
There are hundreds of team performance frameworks out there. So I’ve drilled down and simplified what I believe are are three core principles which make up a high-performing and balanced team.
This applies to ANY team in any industry. Lets drilldown to how this applies to a distributed remote agile team.
In order for a distributed team or remote product designer to be successful, companies (and teams within them) must create clear processes and tools that support each of these principles. Within a co-located team these principles happen organically if your team if functioning well.
These happen in the form of micro-interactions and basic human connection on a subconscious, psychological level.
Natural conversation, hanging by the water cooler, drinks after work. All these things enable you to connect on a more personal level with your colleagues. You gain a deeper understanding of the way they think. You’ll be aware of things like their personal strengths, weaknesses, anxieties. When they’re having a good day, bad day… When to interrupt and when to listen.
This mutual human understanding of each other is hard to replicate when remote working.
A remote product designer or team needs to work much harder at this. These micro-moments can happen organically but with much less intensity and frequency. The conversation becomes overly structured and context is lost.
This is where we need to rely on more tools and structured processes to enable this team balance.
I previously mentioned the ‘Agile Manifesto’. So what about the first principle? “Individuals and interactions over processes and tools.”
This is part of the reason why a distributed team or remote product designer may have issues reaching “true agility”.
Lets look back to the three general principles of a high performing team but rephrase slightly to:
- Remote Communication
- Remote Coordination
- Remote Culture.
Doesn’t quite have the same impact does it? When we add remote workers to the mix here these principles become much harder to follow. Lets highlight a few challenges which come with this.
- The ‘Can you hear me’ effect
- Upfront documentation
- Lost context
- Overly structure conversations
- Lost Spontaneity
- One way information flow
- Vision alignment and understanding
- Individual rapport
To answer my original question in the title of this article. “Can a remote product designer achieve true agility?”. My answer is ‘It Depends’. ‘Agile’ is not about daily standups, scrums and sprints. It is about creating a team which can uphold the three core principles ‘Communication’, Coordination’ and ‘Culture’. All the ‘Agile’ related terms you hear are simply to support these principles.
A distributed team may need to work a little hard at this but there is no reason they can not achieve the same level of agility as a co-located team.
This article has evolved from a ‘Tech Talk’ I did at the Pivotal Labs Sydney office. Co-located to remote – Can a distributed team achieve true agility?