Woven Together - A Practice to Build Authentic Connection and Psychological Safety

By Jody Gold with Mario Moreira

The game is changing. Hierarchies are flattening out. Companies are re-organizing to profit from the agility and collective intelligence of smart, flexible teams.  The concept of “leadership” itself is changing—from individual leadership that devises strategy and drives troops into battle, to relational leadership that catalyzes the creativity and commitment of all team members.

The good news is that there are constructive frameworks from the isolation, frustration, and disengagement that reduce collective learning and performance, to fully engaged, highly coordinated, innovative and agile teams that increase learning and performance. Matrix Leadership is one such framework that helps you successfully navigate this transformation.

Woven Together is an early practice and part of Matrix Leadership that helps strengthen the fabric of your team. Icebreakers and team-building exercises are often fun but their value fades.  Woven Together builds authentic connection, curiosity, and care among team members that last. People who’ve worked on teams together for years often rarely know about each other as people.  They may not know that John has a baby girl, and fills up with love when he talks about her getting her first tooth, or that Jennifer gets lit up by the smells, sounds, and tastes of street food when she is in another country. 

Woven Together raises energy in the room and can be used as a stand-alone activity.  It’s also a tangible introduction to core concepts like seeing relationships as first class entities that Mario Moreira describes in his article (part 1 of this series) and the entire network of relationships within a team as the relationship infrastructure that Jody Gold describes in part 2 of the series.  You can practice Woven Together with your team, right now.

Set-up

The ingredients include your team, a ball of yarn, 20-30 minutes depending on the size of your team, and enough space to stand in a comfortable circle.

Determine if each person in the circle will say just their name or their name, role, years in role, years at company, years doing agile.  This will depend on how well the facilitator and team members know each other.

You are person A.  You will explain the activity and model the two most important components: 1) forming a connection with one person—person B - and speaking to that person only, instead of scanning from person to person as we’ve all learned to do, and 2) telling person B 'something that light you up' in a way that is genuine and concise.

Steps 

1. Person A wraps the end of yarn around a forefinger and loosens enough yard equal to the distance between person A and B.  Person A throws the ball of yarn to B.  A speaks directly and only to B.
2. Person A says their Name.  Person B says their Name. 
3. Person A shares, “Something that lights me up is…”
4. B responds in a few words to complete the connection, “Cool. Thanks for telling me that. I want to know more about that. Etc.”
5. Person B chooses person C.  Repeat steps 1-5 (figure 1)
6. C chooses D and repeats steps 1-5.  Iterate until all people steps 1-5 and the ball of yarn is back at A  (figure 2).
7. After the yarn is back at person A, ask people to share what the experience was like and how things feel different now than before the activity.  

Final Thoughts

If Woven Together is used to introduce other practices, you may invite observations about the structure itself and its capacities.  Participants will name many characteristics of distributed leadership before they’ve learned about them formally.

Woven Together almost runs itself.  It’s amazing how much authentic connection, trust, and psychological safety arise from sharing ‘What Lights You Up.’  As the one leading the activity, be prepared for someone to say that speaking to only one person feels rude, exclusive, or uncomfortable.  Of course it may—scanning from person to person is a deep cultural norm.  Others may describe a sense of ease staying in connection with one person, like talking one-on-one with a friend.

Woven Together is also a good way for everyone to hear everyone else’s name a couple of times, and to quickly know who’s in what role and for how long, and/or how long they’ve been on the team or in the company.  It’s a great activity for a new team, a team whose membership has changed, or a new cross-functional project.

You have everything you need right now to turn thirty minutes into gold.  If you would like more information, consider contacting Jody Gold to discuss Woven Together or to learn more about how to equip teams to think, decide, and act as effectively as they can together.  

---------------
Read Part 1 & 2 of the Relationship series:
- (Part 1) Importance of treating Relationships as First Class Entities 
- (Part 2) Strengthening the Relationship Infrastructure to Build High-Performing Teams

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.          

Building an AI and Agile Culture of Learning

Does your AI and Agile education begin and end with barely a touch of training?  A number of colleagues have told me that in their companies, training ranged from 1 hour to 1 day.  With this limited training, they were expected to implement and master the topic.  AI nor Agile isn’t simply a process or skill that can be memorized and applied. It is a culture shift. Will this suffice for a transformation toward AI and Agile?

Education is an investment in your people.  A shift in culture requires an incremental learning approach that spans time.  What works in one company doesn’t work in another. A learning culture should be an intrinsic part of your transformation that includes skills, roles, process, culture and behavior education with room to experience and experiment.

A transformation requires a shift toward a continuous learning culture which will give you wings to soar!  You need a combination of training, mentoring, coaching, experimenting, reflecting, and giving back. These education elements can help you become a learning enterprise.  Let's take a closer look at each:

Training is applied when an enterprise wants to build employee skills, educate employees in their role, or roll out a process. It is often event driven and a one-way transfer of knowledge. What was learned can be undone when you move back into your existing culture.

Coaching helps a team put the knowledge into action and lays the groundwork for transforming the culture. Coaching provides a two-way communication process so that questions can be asked along the way. A coach can help you course-correct and promote right behaviors for the culture you want.

Mentoring focuses on relationships and building confidence and self-awareness. The mentee invests time by proposing topics to be discussed with the mentor in the relationship. In this two-way communication, deep learning can occur.

Experimenting focuses on trying out the new skills, roles, and mindset in a real world setting.  This allows first-hand knowledge of what you’ve learned and allows for a better understanding of Agile.

Reflecting focuses on taking the time to consider what you learned whether it is a skill, process, role, or culture, and determine what you can do better and what else you need on your learning journey. 

Giving back occurs when the employee has gained enough knowledge, skills, experience, to start giving back to their community to make the learning circle complete. Helping others highlight a feeling of ownership to the transformation and the learning journey.

It takes a repertoire of educational elements to achieve a culture shift and becoming a Learning enterprise. When you have people willing to give back is when the learning enterprise has become full circle and your enterprise can soar.

-------------------

For more Agile related Learning and Education articles, consider reading:

• Agile Education Engine - Bringing power to your Agile Transformation - http://cmforagile.blogspot.com/2014/11/agile-education-engine-bringing-power.html
• There is no Success of Fail, only Learn - http://cmforagile.blogspot.com/2015/12/there-is-no-success-or-fail-only-learn.html
• How a Self-organizing Agile Education Vision can help your Agile Transformation - http://cmforagile.blogspot.com/2014/02/how-self-organizing-education-vision.html

There is no Success or Fail, only Learn

I have been in discussions both in-person and on twitter with colleagues on whether we should use the word “fail” or “learn”.  This was in context to projects (aka, releases, increments).  Did they failed or did we instead learn.  I also realized that the term “fail” is somewhat subjective (e.g., did the whole project fail or just parts of it?).  The overwhelming agreement was that “what did we learn” was a better way to discuss the findings or results. This lends itself to a shift in mindset, to a continuous learning environment that recognizes that there is value even in the negative feedback.   We can learn from that feedback and adapt for better results in the future. 

Then it occurred to me, the term “success” was also a bit subjective.  I recall reading a Standish Group Study where those projects that were “deemed” successful, 45% of the features were never used.  Another 19% was rarely used.  This meant that projects deemed successful built 64% never or rarely used features.  That seems to be a very loose definition of what “success” looks like.  In addition, how many projects are deemed successful because it met the scheduled deliver date yet few customers upgraded to it or bought it?  Is there a benefit to use the term “learn” in place of success?

While it may sound feel like the terms success or fail are the way to traditionally judge a project, release, product, or service, we lose sight of the most important result of the work, the feedback and what we learned from that feedback.   This learning helps us adapt to achieve better results.  If you are working in an Agile context where there are short increments of work, there is the benefit of continuous learning where you can continuously adapt for better business results.

I would suggest in the modern lexicon of work, when a project, release, or increment of work is done, it is much more important to ask what was learned instead of classifying it as a success or failure.  This strengthens the mindset within the organization that there is a value in feedback and the most important thing is what did we learn.  It also emphasizes a discovery mindset where what we think a customer wants is really a hypothesis that must be explored.  It is in the learning that can help us lead to better business results in the future.  So next time people talk about a project as a success or failure, instead turn the discussion around and ask “What did we learn”?