Seven ways to keep a team engaged to produce valuable software

Let’s make MVP mean Most Valuable Product with your virtual team! 

Arts Interstices is very happy to welcome Mary Brodie, Agile UX Expert, as guest blogger in follow up to Self-Inventory for Distributed Teams. In this post she has tackles the first principle of the Agile Manifesto and what it means for virtual teams. Elinor Slomba and Mary Brodie share their perspectives on supporting great Agile cultures across distance in Sococo’s webinar series, based on our distributed culture self-inventory.

Agile Manifesto Principle 1:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

The first principle of the Agile manifesto seems pretty straightforward, except for the part about valuable software, especially with a virtual team. It’s difficult enough to define what’s valuable to a customer when the team is in the same location – how do you do that when there is a team across the country or around the world?

The word “value” and its cousin “worth” are probably some of the most subjective words in the English language. And their formal definitions don’t help clarify their meaning:

Value: the regard that something is held to deserve; the importance, worth, or usefulness of something.

Worth: the value equivalent to that of someone or something under consideration; the level at which someone or something deserves to be valued or rated.

Given how they both define themselves using the other word, understanding them is difficult. Additionally, value and worth are typically associated with costs and money, which is one possible measurement of them, but it’s becoming clear we need additional considerations to understand what’s valuable to a customer.

Especially when we have open source and free software options available.

Defining value and worth is an industry-wide problem – there aren’t many best practices for determining what’s is valuable. Even a Harvard Business Review article highlights how value and worth are no longer related to only money, but like the industry, it doesn’t really outline how customers determine what’s valuable.

However, that HBR definition does point out that customers will find a way to meet their needs by purchasing your product offering, your competitor’s offering, or by making it themselves. The latter two are part of what creates reference value, or the closest perceived substitute. And cost isn’t necessarily a factor when value is defined by need and use, especially with open source software options.

And in the days of open source, there is often a reference value of zero, which has significantly disrupted pricing dynamics.  The take away here is that you must get inside your customer’s head and understand what they see as the reference value.

–Phil Montgomery, How does a Customer Determine Product Value

So how do you get into your customer’s head?

This brings us back to the traditional questions we ask when first creating a product, whether we are in a virtual team or on-site together:

• Who are we building this for?
• What problems are we solving?
• How are we making the users’ lives more convenient?
• When’s the best time to deliver this? Deliver faster and you are first to market, which could offer customers a different perception of the direction where your product is going; deliver better and you may dominate because you exceeded expectations.
• Do customers have confidence that the team can deliver? And trust that what they will deliver will be what they want?
• Does the team understand the value to the customer?

Here are 7 ways to answer these questions and keep your virtual team engaged to make valuable software:

1. Some might call this the “traditional” approach. Product owners will create a presentation deck that clearly outlines the value proposition of the product, the iteration, and the features. They will also outline who the target customers are, include personas, their goals, and bring the team into the vision, asking for their perspectives and ensure that the team understands the revenue goals and price/costs.

Most times, this will be presented to the team at once so everyone understands what they are working towards.

But that’s an ideal case and not true for all teams.

2. Have the team describe the product’s value without using the words “value or worth.”

In this game, encourage the team to talk about what value the product gives customers and what it’s worth to them – without using those words. Let them brainstorm to more fully understand what they are building and why it matters. Some innovative perspectives may come from the discussion – as well as new features to add.

3. Hold the team accountable to metrics they have defined to ensure that the team is creating valuable software.

How does the team know that they are meeting the mark? Metrics that are too granular may not show incremental results or the results of a single feature on its own (with no context), but not getting specific enough may illustrate general trends that doesn’t point to any specific result whatsoever. You need to find balance and determine what will indicate a customer’s behavioral shift occurred.

Look for metrics that are broad enough to show improvement, and narrow enough to show improvement due to a particular feature or function being added.

And this is necessary for a virtual team – there needs to be unbiased consensus that they are working towards the right goals. This will help them make independent, yet united, decisions each day, knowing they are working towards the same goal and the same measurement of it.

I was working on team with 5 developers, all working from home at different times of day. We all had our priorities and stories and understood the goal of the sprint, or so we thought. One of the team finished early and thought he would be helping by picking up new stories. However, it was work that the client didn’t need for that sprint – he would have been better off helping the other team members than starting new work. Luckily, he didn’t get a bunch done before the team noticed what he was doing (thank you version control!) and we met to refocus priorities. Talk about a near miss for getting derailed!

4. Build consensus that the team is working to provide the customer the right value

The team needs to feel as if they are part of the business, and the best way to do that is to be sure that they understand their contributions to the customers. If the team has a sense of accomplishment and sees progress, they will be more engaged and invested than a team that is just doing a job to meet corporate goals.

Prioritization meetings will help facilitate discussions about product goals, what’s in the iteration, the target audience, and what they want to do. Be sure your entire virtual team is involved, contributing to the conversation and providing their perspective – don’t let anyone hide behind the veil of a conference call.

Once the team understands the customer’s perspective and the need for urgency to deliver, they will collaborate to deliver results.

5. Use visuals for reference

We can discuss goals and personas all day, but until someone writes it down and we all agree on what we see, everyone will have a different image of the goals in their head. This is key to virtual teams. It’s like Plato’s ideal dog or ideal tree. When we think about a dog, we all think about a different type of dog – a Great Dane, a Pekinese, etc. It may be generally a dog, but it’s not the same dog.

And this can make a difference when creating software. If the team has slightly divergent views on what’s being built, or only see part of the story, you won’t successfully build a product. There will be no consensus, no unifying driver for the team to achieve a goal.

6. If you can’t have focus groups, get to know customers in other virtual ways

Everyone on the team should spend some time getting to know the customers – either by witnessing virtual or recorded usability testing sessions, reading product reviews, or listening to customer service calls. Some of these customer feedback methods could be used metrics (higher ratings, fewer phone calls). This will give everyone on the team insight into the value the software gives the customer – or the value the customer wants to get from it.

And you don’t need to be in person with a customer to do this – you can do this on your own away from the team. But be sure to share what you learned with the team so everyone is aligned and they can work together to make valuable product.

7. Build trust. If your team doesn’t trust each other – how will customers trust that they will build the right software?

Trust builds confidence, and without confidence to get the work done and deliver on-time, how will your team tackle the most challenging problems to achieve your goals? Let’s add to the challenge a multi-located team. They need to be able to trust each other, know that each team member has the other person’s back. And if the team doesn’t trust each other, how will other people trust the team?   

One of the best ways to build trust is built into Agile approaches – retrospectives (for virtual teams, try Retrium to help you out). Although they can be sometimes perceived as unnecessary, I love retrospectives because they make sure everyone is getting it all out there for discussion. If there was some weirdness in the previous iteration, the team works through it.  Sometimes we take open and honest communication for granted (I know I do often), but we shouldn’t. It’s key to building trust and a solid relationship with your teammates.

Beyond the retrospectives, try team building exercises and games to help your virtual team build rapport. Alternatively, work with the team to develop a virtual communication style and make sure that there are tools available to support that. Some teams work better with video, some voice only, some need chat, some require written documents. Slack works well for some groups; others need Skype or other tools. But the approach is unique to your team.

How we define value as a concept is a moving target; but which features and functions a software provides is valuable to a customer, isn’t one. Further, we need to build tightly bonded teams that are focused on creating valuable software for customers – especially when virtual. Being virtual encourages us to be more specific in our communication with each other, relying on visuals and setting target metrics to keep our focus on the final goals. Without those elements in place, achieving the first principle of the Agile Manifesto is almost impossible to do.