BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Product Development in Distributed Teams

Product Development in Distributed Teams

Bookmarks

Key Takeaways

  • Learn how to perform various activities related to product development in distributed teams.
  • Understand the questions to figure out challenges due to the distribution in your product development.
  • Understand the basic virtues of developing products with remote teams.
  • Learn numerous online tools for user research, product visioning, story mapping, backlog refinements and planning sessions.      
  • Practical examples and cases of distributed product management.

 

Distributed teams are the norm for many organisations today. Companies are global, communications technologies allow people to live away from the "office" location and many of the new workforce are nomads. Becoming a high-performing team is possible in a distributed group, it just takes more effort to overcome the inherent challenges of distance. 

This is the first in a series of articles which explores the impact of cultural differences on distributed teams - "Distributed Agile - how to work with teams across the globe". You can subscribe to receive notifications via RSS.

 

Recent proliferation in globalisation led to distributed business models. All over the world, we see people are working in distributed models and it is evident that distributed teams face challenges in their day to day activities.

On the one hand, the foundation of agile implementation is collocated teams.

“Collocation is key”

As an agile coach, I always ask my teams to be collocated because

Face-to-face communication is better than other types of communication.

Even though most people will acknowledge the wisdom that collocated work is easier, reality is oftentimes different. Companies distribute their offices and partners globally and people running projects need to find ways to collaborate remotely.

I've started developing a distributed agile framework together with 3 others: Hugo Messer, John Okoro, and Arjan Franzen.

We're still in the inception phase. Our belief is that we should open source a big part of the framework. The framework we have developed consists of 8 'bubbles':

  1. Culture
  2. Organization
  3. Product
  4. Team
  5. Architecture
  6. Engineering Practices
  7. Communication
  8. Tools

Each of the bubbles has 3 elements:

  • Questions: a set of questions that organisations can use to assess their current state
  • Virtues: behaviours that foster distributed collaboration
  • Practices: things that have worked, shared by practitioners

In the previous article, Hugo Messer and John Okoro wrote about Organisation and Culture. In this article, I am going to explore the bubble: “Product”.

Product

What is a product and how to define it? There are many definitions given by various people; teams can use any definition to define their product. Mike Cohn, Agile Alliance and Scrum Alliance founding member, consultant, book author and founder of Mountain Goat Software defines a product as:

A product is something (physical or not) that is created through a process and that provides benefits to a market.

Product development is not only defining the product right but also developing in the right direction. To better understand whether you are managing your product development successfully with your distributed teams, ask the following questions to yourself and your team members:

Questions

  • Are team members in all locations aligned on product vision with business?
  • Is everyone aligned on the definition of product?
  • Are all team members part of product visioning, roadmap creation, and backlog refinement workshops?
  • Is the product visions and roadmap visible to everyone, anywhere?
  • Do all team members directly work with business and users?
  • Do we have team distribution in a manner of having multiple cross-functional collocated teams?

Virtues

To effectively manage products, we have developed a set of virtues. Based on these virtues, a distributed culture that fosters collaboration can evolve.

  • Enable all team members to communicate with users
  • Product transparency: roadmaps, visions, goals are visible to everyone
  • Think from users perspective

One of the biggest challenges we see in distributed teams is the distance to users of the software. In traditional models, the project manager is the interface between stakeholders and users and translates requirements to teams. In agile, our philosophy is bringing stakeholders, users, product owners and teams together regularly. As Henrik Kniberg, Agile Coach at Spotify and Lego, author and Co-owner at Crisp AB, explains in his famous 'Agile product ownership in a nutshell' video, collaboration ideally looks like this:

But distance doesn't help there. As a result of geographical and time zone differences, product owners often get back in the role of project manager. They communicate with the users and the team as the 'in between' person. We believe that enabling all team members to regularly communicate with users via whatever means there are, is crucial.

Remote team members lack the energy of a head office. They can't attend lunch breaks, Friday night beers and coffee chatter. They also won't see your product roadmaps, vision, strategy, etc if they're physical. Although obvious, we have seen too many remote teams who are completely in the dark about the product they are building. Product transparency means we should use online tools, wikis, whiteboards, cloud drawing tools to share the energy of a product with all our distributed team members. It also means it's valuable to gather with all distributed team members regularly to update and revise all the product documentation.

In order for development teams to build great products, they need to truly understand what they are building for whom. They need to build products with the user's perspective in mind. Remote teams often 'just build features' (invented by someone else far away). Product managers can make a conscious effort to get their remote teams energized for their product and users. Teams can use workshops, frameworks (e.g. lean startup), interactions and tools to get a better understanding of who uses their product, how and why.

Practices

There are many practices which organisations can use to overcome the product development challenges in distributed teams. I am explaining some based on my experience working with the teams on the ground:

Stimulate empathy for the product

Empathy is an important virtue for making distributed teams function productively. I have developed an empathy plan for distributed teams a couple of years ago. In the context of culture, I have described the use in our article 'Managing Cultural Differences in Your Distributed Team'. The plan is meant to stimulate empathy at 4 levels. In the context of the product, we want teams to be fanatics, to be excited about the software they create. Startups and (new) products succeed if their teams are thinking day and night about their products, their users and improvements. Product owners can stimulate this 'empathy for the product' by running their product like a startup. Team members who clearly see the vision and roadmap of their product and regularly interact with the users get more motivated. Let them interview users, let them go out into the street to observe how the software is used, let them attend meetups or conferences where their users come. If (part) of the team is remote, it's even more important to consciously stimulate product empathy, because the remote team members miss the action of the head office. A small travel budget plus strong video and audio conferencing tools can do the trick. Users can hop on a short Skype call, they'll probably even find it interesting to talk to a foreign team.

User research in distributed environment

A product's success depends on our understanding of user needs. If teams build a product without knowing their customers, it could be dangerous for the business.

To build a shared understanding of the user problems there is no substitute to inviting everybody from the team to the sessions. Witnessing users struggle with the product will motivate people to go and fix it immediately.

I particularly like Christian Rohrer’s summary (outlined in the table below), which lays out a 3-dimensional decision-making framework and provides notes about the position in the product development cycle.

If the team is distributed, you can easily run User Research activities remotely. Conduct remote usability tests through video calls. You can record the action in the screen using Quicktime, while still seeing the reaction on your user’ face. Use tools like ethnio.com or usertesting.com for recruiting users and put your products in the hands of customers as soon as possible. Run tree tests, card sorting, surveys, and more with Optimal Workshop.

Remote teams can also setup Atlab - Atlassian's online user research lab that is used to conduct interviews and usability tests with customers and non-customers. This creates empathy for users, and arms design team with insights to make the products more usable and useful.

For gathering data teams can use online surveys, for instance, SharePoint survey, discussion board, and social listening. For the past few years, the Internet has been used by many companies in conducting all sorts of user research for understanding customer needs. The online survey has been a faster way of collecting data from the respondents as compared to other survey methods such as paper-and-pencil method and personal interviews.

Below is the example of online survey for a travel company. It consists of questions to find out travelers' vacation planning behaviour.

                            

Product visioning workshops with the whole (distributed) team

In the beginning of the product development, the team together with business creates the product vision in a workshop. It is very important to include all the team members in the product visioning exercise from all the locations, otherwise, people would never be able to understand the purpose of the product.

The very first choice of the business should be to ask people to fly to a central location for this exercise. If some people can not join, they should be included through some other means.

Many teams do not invite their mates from other locations because they like to use sticky notes on walls to conclude vision and not having everyone in the same room could create problems in using physical boards. In these scenarios, I recommend using online boards like Realtime Board with video conferencing for better collaboration among remote teams.

If teams are using simple techniques like Elevator Pitch or Business Model Canvas, in every location people can create their own version and share pictures of the final version to everyone. Then on video conferencing discuss all versions and converge to one.

A few years back, when I was building a new product, we started with a distributed team right from the beginning. One of the first things we did was creating a business model canvas together with our distributed team. In this team, we were all distributed (two working from home in Holland, four in India and one in Turkey). Each team member prepared by watching some videos about the business model canvas. Everyone made some notes for himself about the contents of each block in the canvas. I facilitated the session, which took us about 3 hours. In the session, I tried to go through the canvas block by block, eliciting ideas from all our team members. The result was a business model canvas, which gave everyone a deep understanding of the product we thought we should build (we changed a couple of times). I believe this is a strong start for any team; let the whole team join the ideation phase, so they understand the idea, the market, the cash flow, instead of just 'features'. Here's what the canvas looked like, built in canvanizer:

Online User Story Mapping

Usually, teams use user story maps for release planning. A user story map arranges user stories into a useful model to help understand the functionality of the system, identify holes and omissions in your backlog, and effectively plan holistic releases that deliver value to users and business with each release.

The user story mapping workshops are very collaborative and engaging. The team needs everyone's input to make sure all types of features are added to the backlog.

Remote teams can use online tools, for instance, StoriesOnBoard for creating story maps. I mostly use this tool with my distributed teams and it is as effective as using a physical story map with collocated teams. Below is the example of a story map created by using StoriesOnBoard online tool.

Regular backlog refinement and planning sessions with the whole team

Whoever is part of product development should participate in backlog refinement along with business liaison. During backlog refinement meetings, teams usually discuss the below areas:

  • Understand user stories
  • Order product backlog
  • Split big user stories into smaller user stories
  • Write acceptance criteria
  • Estimate

Through the list, it is very clear that the whole team is required to participate in the discussion regardless of their location.

To smoothly run refinement meetings in distributed teams, similar to the product visioning exercise, teams can use video conferencing with online boards. On top of that, teams can also use online product backlog management tools, for instance, Jira, Version One, Trello etc.

Similarly, teams should do planning with the whole team by using the same online tools.

Apart from the above-mentioned practices, teams should focus on the below important activities:

  • User feedback communication rhythm: invite users in the demos and encourage the whole team communicate with them. Alternatively, record videos of users giving feedback and using the product and share that with all teams.
  • Use tools like confluence to have a complete overview of all artefacts related to your product, for example, vision , goals, roadmap, personas, marketing collaterals.
  • Find out the comfortable time slots for product reviews and planning ceremonies.
  • Scrum Master should make sure high bandwidth communication happens between the development team and business representatives.

Please share how you are developing your products with distributed teams.

About the Authors

Savita Pahuja has expertise in Scrum, Lean, kanbanareas and other visual discovery methods. She started her journey in IT industry as a developer and contributed the organization in agile adoption. Then she moved into agile world as a consultant and trainer. Since then she has been working with different clients for agile adoption and giving trainings on scrum and kanban.

Hugo Messer has been building and managing teams around the world for over 10 years. His passion is to enable people that are spread across cultures, geography and time zones to cooperate. He's the owner of Bridge Global, a global software powerhouse and ekipa.co, the education platform for distributed teams.

 

Distributed teams are the norm for many organisations today. Companies are global, communications technologies allow people to live away from the "office" location and many of the new workforce are nomads. Becoming a high-performing team is possible in a distributed group, it just takes more effort to overcome the inherent challenges of distance. 

This is the first in a series of articles which explores the impact of cultural differences on distributed teams - "Distributed Agile - how to work with teams across the globe". You can subscribe to receive notifications via RSS.

Rate this Article

Adoption
Style

BT