Importance of treating Relationships as First Class Entities

I have been helping companies implement agile for over a dozen years.  I love agile because it aligns with the evolutionary and incremental manner in which change occurs in nature.  As in nature, people’s needs change continuously and it is best when an incremental and evolutionary system is used to support this continuous change. In my early years, I focused more on communications via television, photography, and film, as it was fascinating to capture the importance of character development and the relationships being built. As I moved into mindset and methods, I realized how Agile values and principles and the practices that support them focus on not just the changing needs of customers but the importance of the relationship between team members and customers and amongst team members themselves. 

During one of my engagements, I was introduced to a fascinating model called Matrix Leadership by Amina Knowlan and Jody Gold. During the education they were delivering that was focused on giving and receiving feedback, I realized that the thing between two people, a.k.a., relationship, is a first class entity.  In other words, it is a real thing that must be built and nurtured.  In a programming world, a first-class entity is a data type you can freely assign to variables such as Scalars, Arrays, and Hashes to help build out the language. 

In the human world, relationships should be thought of as first-class-entity with variables such as respect, honesty, trust, commitment, forgiveness, expectations, and empathy that can define, strengthen, and build out the relationship. There are elements that impact the way a relationship works such as experience together (aka, past) and dynamics of your relationship to those around you (e.g., influences).  These variables structurally represent various channels (or strings) that live within a relationship between two people that can either strengthen or weaken a relationship.  If one does not exercise the relationship or speak honesty, the channels of a relationship can become brittle and break when tested.   

I used to think relationships were the by-product of personalities applied to goals and are often thought of as invisible and nebulous entities.  But relationships are more like channels through which information, energy, and resources can move between people.  The strength and capacity of these relationship channels enable or inhibit the creation of value on teams as surely as the width, depth, and condition of canals enable or inhibit the movement of goods by ship.  

In an Agile world, to fulfill our goal to get our best ideas to customers faster, we have to learn faster and implement better together.  Most organizations experience meaningful gains during their first two or three years of agile implementation.   The early and iterative feedback achieved by delivering value to customers faster lets us build feature sets and user interfaces that align with current needs, instead of adhering to imperfect plans made long ago.  But after we’ve followed the agile model for a while, we run into the same people-problems that bedevil collective understanding, intelligence, and action everywhere.  Eventually, there are fewer process problems, and more relationship problems.

Understanding that relationships are first class entities has allowed my teams to take early, incremental, and iterative actions on ourselves as a system so that we can work together as effectively as possible.  Because we offer feedback not only about our tasks, but also about the impact that our behaviors have on one another, there is more trust, psychological safety, commitment to outcomes and each other, than I’ve ever known.  Next time you look at your friend, attempt to visualize the relationship entity.  What do you see in the space between you?

------------
We hope you enjoyed Part 1 of the Relationship series. Consider reading Part 2 and 3:  
- (Part 2) Strengthening the Relational Infrastructure to Build High-Performing Teams
- (Part 3) Woven Together - A Practice to build Authentic Connection and Psychological Safety 
------------

What really is an MVP in an Agile World?

There is often a bit of misunderstanding of what is an MVP (Minimum Viable Product) in an Agile context (and I contend in any context).  MVPs are meant to provide the minimal functionality or feature set that will be useful to customers.  However, to attempt to define the minimal set up front means that you know what the customer wants from the start.  How often do you know what the customer wants at the beginning?

Instead, think of an MVP as an opportunity to learn what the customer wants, loves, and needs.  It should neither be fixed nor should you be certain of what it is.  Instead it should be considered an evolving concept from which you learn what the customer wants over time based on continuous feedback.  What mindset shifts might you have to make in order to adapt to what an MVP is in an Agile world? 

The first Agile mindset shift is the MVP is a draft.  Defining an final MVP upfront is akin to big-up-front planning and claiming certainty.  Instead, you hypothesize what the minimal set of features might be as a draft, and then have a mindset and practices where you validate your assumptions and hypothesis.  You start with an adaptable idea of what might be minimal and valuable to the customer. The moment you attempt to succinctly define the set of features, you are doing a disservice to your customer. 

The second Agile mindset shift is that customer feedback is key to evolving the MVP.  It is an opportunity to learn what the customer wants, loves, and needs.  If you want your MVP to align closely to customer value, you must include continuous customer feedback loops when working on an MVP.  These can take the form of customer demos or hands-on sessions.  Customer feedback can start as early as when you are hypothesizing what is an MVP and must be part of evolving the MVP to gain a strong inspect-and-adapt mindset with the inspect coming from the customer.  Eric Reis writes that an MVP “allows a team to collect the maximum amount of validated learning about customers with the least effort.”  Customer feedback is the cornerstone to validated learning and establishing an MVP. 

So who really determines what is the MVP?  If you think the answer is you, your management, or your team, then maybe its time to Reduce your certainty and Ready your mind with the Agile mindset, discovery mindset, and Feedback loops. The right answer is the customer determines what is the MVP in Agile.  The more closely you align with customers throughout the effort, the more likely you will have an MVP that is considered valuable to the customer.          

Four Anti-Patterns impacting Customer Value

Value is in the eye of the beholder.  Smart people will say that the beholder is the customer. While in most companies there will be a similar saying to the “customer is king”, some have lost their way and have somehow forgotten the importance of customer and their feedback.  The result is organizational anti-patterns that impede successfully getting to customer value. There are a number of anti-patterns on why this occurs and below are four: 

• Known as Pretend Certainty anti-pattern, this is believing that you can pretend to know with certainty what the customer wants upfront.  The danger: the consequence of limiting options and being blind to customer feedback to shape product direction.  
• Known as No Room at the Innovation Inn anti-pattern, this is focusing primarily on driving efficiencies through cost cutting and high resource utilization.  The danger: the unintended consequence of a lesser focus on the customer with little room to innovate and adapt. 
• Known as Sub-Optimizing for Comfort anti-pattern, this is sub-optimizing for the comfort of having a well-established plan and set of well-defined processes.  The danger: the consequence of restricting change at the expense of adapting to customer needs.  
• Known as The Few and the Missing anti-pattern, this is engaging few to represent the whole.  The danger: the consequence of understanding customer pool, ignoring potential customers, and missing customer feedback to shape product direction. 

When you are a start up, you realize the importance of being customer value driven because if customers don’t buy the product, then your start-up goes under. Because of this and their small size, most start-ups will stay very close to the customer or potential customer.  When companies become larger, there is a greater chance these anti-patterns appear.  More process and more controls are often put into place and unfortunately this leads to restricting change.  A company may sub-optimize for their own processes and plans that distances them from their customers.  

The question is, do you see any of these anti-patterns within your organization that impact your ability to achieve customer value?  Avoid the poor “aim of the anti-pattern’.  Instead, engage with your customers and use their feedback to help you hit the customer value target!

For more information on the topic of Customer Value, consider reading the following articles:

• Dangers of Certainty in Realizing Customer Value
• How an Agile Customer Feedback Vision can lead to Customer Value

Dangers of Certainty in Realizing Customer Value

Don Quixote was certain he saw Giants instead of windmills. In this epic story, he believed he knew the answers and saw what he wanted to see.  Unfortunately in many organizations, there is this same phenomenon, a need to act as if we are certain.  In fact, the higher up you go in an organization, the compulsion of acting with certainty becomes greater and greater.  Statements like “That’s why we pay you the big bucks” are used to imply that the higher in an organization, the more you are expected to just “know”. 

Some think they must act with “pretend certainty” for the benefit of their career.  Others have convinced themselves of “arrogant certainty” where they believe they know the answer or solution but don’t (or can’t) provide any solid basis for this certainty. Unfortunately this arrogance can be interpreted as confidence that can be dangerous to the success of a company.  Nassim Nicolas Taleb refers to “epistemic arrogance” that highlights the difference between what someone actually knows and how much he thinks he knows. The excess implies arrogance. 

What has allowed certainty within companies to thrive is that there is a distance between the upfront certainty and the time it takes to get to the final outcome.  There lacks accountability between certainty at the beginning and the actual results at the end.  Often times the difference is explained away by the incompetence of others who didn’t build or implement the solution correctly.

Of course, the truth is somewhere in between. The concept of certainty is actually dangerous to an enterprise since it removes the opportunity of acknowledging the options and allowing the enterprise to apply a discovery mindset approach toward real customer value via customer feedback loops and more.

We also want to avoid the inverse that is remaining in uncertainty due to analysis paralysis.  A way to avoid this is to apply work in an incremental framework with customer feedback loops to enable more effective and timely decision-making. Customer feedback will provide us with the evidence for making better decisions. Applying an incremental mindset will enable us to make smaller bets that are easier to make and allow us to adapt sooner. 

A healthier and more realistic approach is to have leaders who understand that uncertainty is actually a smart starting position and then apply processes that support gaining certainty. It is, therefore, incumbent upon us to have an approach that admits to limited information and uncertainty, and then applies a discovery process toward customer value. In the end, the beaten and battered Don Quixote forswears all the chivalric false certainty he followed so fervently.  Is it time for management to give up the certainty mindset they think they have and instead replace it with a discovery mindset as a better path to customer success?