Beware of AI BS (aka, Hallucinations)!

User beware! Did you know that your AI query is subject to hallucinations?  What is an AI hallucination? When AI inadvertently generates false or misleading information that seems plausible but is not rooted in reality. It is trying to give you an answer. These are errors in AI outputs that arise from flawed reasoning or inaccurate training data, typically not from malicious intent. 

For example, a language model like ChatGPT might generate an article with fake references or make up scientific facts because it is just predicting what should come next based on patterns in data. In fact, when I asked “what was the duck wearing when it won the Boston Marathon?”, it said that “the duck was wearing a quacking pair of sneakers and a feather-light singlet when it flapped its way to victory!”

This should not be confused with people deliberately using AI tools to create misinformation, typically to manipulate public opinion or cause harm. AI itself may be used to generate highly realistic but fake content, such as fabricated news articles, doctored images, or videos. For example, AI may be used to create Deepfake videos to manipulate someone's face and voice to make them appear to say something they never did. 

Turning back to actual AI hallucinations, what are the risks where it inadvertently poses several serious dangers? Generally, creating and sharing hallucination misinformation can spread quickly, particularly in news, health, legal, or political contexts.  Users who trust AI outputs may unknowingly share false information, amplifying its reach. What are more specific dangers?

• Generating legal and medical judgments or diagnoses. AI-generated hallucinations in legal documents, medical advice, or financial reports can lead to harmful or even illegal outcomes. This can damage reputations or result in malpractice.
• Misinterpreting security and safety threats. In cybersecurity or military applications, a hallucinated misinterpretation of data in critical systems (e.g., aviation or nuclear control) could trigger wrong decisions with high-stakes consequences.
• Spreading stereotypes and reinforcing bias. Hallucinated outputs might reflect or invent stereotypes or discriminatory patterns that reinforce social biases. This can be especially harmful in generative content involving race, gender, religion, or culture.
• Damaging reputations and polluting research. Fake references or fabricated studies can pollute scientific research, especially if unnoticed in peer review or student submissions. AI hallucinations in education can mislead learners or promote academic dishonesty.

After enough hallucinations are shared and spread, repeated exposure to hallucinated content undermines trust in AI tools and technology in general. Ultimately, if enough misinformation occurs, there will be an erosion of trust and hesitancy to adopt AI. The important thing is be aware that AI tools will inadvertently generate false or misleading information. Don’t accept answers at first blush. Instead, verify the answers, verify the references, fact-check the outputs, and ask AI to double-check its results.

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

Strengthening the Relationship Infrastructure to Build High-Performing Teams

By Jody Gold with Mario Moreira

Teams, not individuals, are the essential building blocks of sense-making and action-taking in organizations.  Research, theory, and experience tell us that great teams depend as much on the relationships between the people, as the people themselves.

When I was younger, I spent years practicing leadership development the way most consultants do. We focused on strengthening the skills of individuals and hoped that teams would automatically improve as a result. We probably knew that relationships are the connective tissues that hold teams together, but we didn’t provide the mindsets, maps, or tools for people on teams to take care of the entire network of relationships themselves. Improving the skills of individuals is like lifting weights without strengthening and stretching the ligaments and tendons that connect them.

Matrix Leadership provides the mindset, maps, and methodology needed to build the capacities teams need to perform as interconnected, coordinated, adaptive wholes. It’s the ‘how’ of how we think and act like we’re in it together.  This is true whether the ‘it’ is diversity and inclusion, building resilient communities, or succeeding in complex and chaotic business environments. 

The heartbeat of our approach is building the relationship infrastructure that is the most important contributor to and predictor of a high-performing team.  Economic activity and value creation can only happen when working infrastructure (roads, bridges, tunnels; power grids; telecommunication; the Internet, etc.) support them. Might relationship infrastructure be equally important?

Research from MIT[i] and Google[ii] show that the pattern and quality of interactions within teams contributes more significantly to high-performance than the personalities, experience, skills, and individual intelligence of team members combined. In the image above, a blue line between two people represents a relationship, the first-class entities that Mario Moreira writes about in his recent article. Wider lines illustrate more interactions, more capacity, and deeper relationships.  The entire network of connections within a team comprises the relationship infrastructure. 

Developing the capacity for team members to speak to each other—in the open—is an indicator of a healthy relationship infrastructure.  It replaces the common norms of talking offline, not engaging, or scapegoating.  We call this speaking “in the eyes and ears of the whole”—a capacity that creates the foundation for many other high-functioning behaviors, including delivering effective feedback.

Agile uses early and iterative feedback about products so developers can generate more valuable and higher quality products faster. Matrix Leadership uses early and iterative feedback to optimize the relationships that high-performing teams depend on.  Feedback about relationships is the most direct way to build trust, psychological safety, and resilience so teams can turn their energy into results instead of friction. 

Both Agile and Matrix Leadership bring feedback into the open where it can do the most good.  When entire teams understand their shared challenges, they are better able to collectively solve them.  In addition to improved feedback, a healthy relationship infrastructure supports other behaviors including increased ownership and accountability; collaboration and innovation; engagement and satisfaction; and leadership that is distributed, flexible, and emergent.

Relationships are first class entities, real things that can be built, maintained, and repaired.  Yet it’s the entire web of relationships, the relational infrastructure, within the best teams that enable them to out-think, out-perform, and out-happy the others. 

Thanks Mario for inviting me to expand these concepts with you. 

----------------------------------------
We hope you enjoyed Part 2 of the Relationship series. Consider reading Part 1 & 3 
- (Part 1) Importance of treating Relationships as First Class Entities 
- (Part 3) Woven Together - A Practice to build Authentic Connection and Psychological Safety 

---

[i] Pentland, Alex S. (2012, April). The New Science of Building Great Teams. Retrieved from https://hbr.org/2012/04/the-new-science-of-building-great-teams

[ii] Duhigg, Charles. (2016, Feb. 25). What Google Learned from its Quest to Build the Perfect Team.  Retrieved from https://www.nytimes.com/2016/02/28/magazine/what-google-learned-from-its-quest-to-build-the-perfect-team.html

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 
------------

How do you reward within an Agile Team culture?

The primary notion of rewards within an Agile culture is that the team shares the success or failure of the work they are doing.   The driving principle is that unless we all succeed, none of us succeed.  There are advantages for rewarding at the team level.  Rewarding by team promotes the Agile team culture.  Team rewards promote and encourage team members to help each other out.  Trust is built when individuals must come together to share information and collaborate. This can work well except that it leaves no room for individual focus and can leave some top performers feeling underwhelmed.  So the question is, is it so simple to say that we “only” reward as a team?

It is true that some team members will align with the Agile culture quicker than others.  Also, some team members will, in fact, contribute more than other team members.  And maybe sometimes, it is important to acknowledge exemplary work when it occurs.   However, individual rewards can lead to unhealthy competition.  Past leaders who have been constantly rewarded for being the superstar will have a hard time with a team reward approach.  Under-performers may find it easier to lay low in an Agile team and just do the minimum.  By providing more reward to some team members could lead to a feeling of jealousy and resentment.   This is problematic in not only an Agile culture but any culture.  

Ultimately, you do have to remember that you get the behavior you reward.  If you give reward at the individual level, you will get a level of competitive behavior and a willingness to place personal achievement over team accomplishment.  If you reward at the team level, you will get a level collaborative behavior that places team accomplishments over personal achievement.

Team Reward Approach

Within an Agile context, rewards should be supportive of the team culture.  The question is, what does a reasonable reward structure look like?  First it is important to acknowledge that answer isn’t straightforward.  It depends on your context and situation.  As a suggestion, consider starting by making at least 50% of the reward based on team collaboration and success.  Then over time increase the team reward part to make it a major part of the rewards, and still leave a small percentage available to acknowledge individual growth, exemplary work, and more adaptive alignment to an Agile culture. 

Not all Rewards are Created Equal

What is meant by reward?  Not all rewards are created equal and a reward for one person can mean something difference from one person than another.  To some employees, reward means money in the form of a merit increase or bonus.  For others it can mean advancement and more responsibility.  Yet for others it’s the ability to have freedom to work on what they want.  As part of self-organizing teams, you can have Team members recognize each other.   For example, during a Sprint retrospective (if this is being applied), the first part of this event can be where team members recognize each other for their help, assistance, helping the team drive forward, complete stories, and more.  

Team Reward must Live within a Team Culture

Maybe the answer is not as simple as instituting one type of reward system or other.   Maybe this can only work unless it fits within a broader context of focusing on the culture.  For Team rewards to be effective, a company’s culture must embrace the team concept.  Maybe it has to first start with understanding people’s natural tendency toward an Agile culture and team environment.  Maybe there has to be an understanding of people’s willingness to adapt and align with Agile.  If individuals and/or management are not really willing to adapt, they may not be able to handle a team-based reward system.  In order to handle the competitiveness, potential jealousy, and other harmful attributes, the best scenario is when team members understand and believe in the Agile values and principles and in particular, the principle of self-empowered teams.  Ultimately, the reward system that best suits your needs can be driven by an Agile principles but it should be adapted over time as your organization adapts to the Agile team culture.   

Who makes the Best ScrumMaster?

As teams consider adopting Agile, one of the most important decisions they can make is who will be the ScrumMaster. Because the ScrumMaster is the promoter of Agile values and principals as well as the coach for ensuring the Scrum is being practiced effectively, it is critical that this role be filled with someone who is dedicated to implementing the Agile mindset.

A good ScrumMaster must have the ability to be an effective Servant-Leader. If is important to understand that a servant-leader takes a facilitative approach and does not apply command-and-control. Some key attributes include:

• Building a trusting environment where problems can be raised without fear of blame, retribution, or being judged, with an emphasis of healing and problem solving.
• Facilitating getting the work done without coercion, assigning, or dictating the work.
• Ensuring the implementation of healthy Agile Scrum practices and values are followed on the project.
• Removing roadblocks or find the right level of personnel to remove the roadblock.

In the book “Practicing Servant-Leadership" by Larry Spears and Michele Lawrence, they share attributes for servant leadership. Some attributes include: listening, empathy, healing, awareness, persuasion, and foresight. Anyone who becomes a ScrumMaster should consider taking ScrumMaster training to help them understand their role and the activities they will facilitate. So the question arises, is there a traditional project role that plays the ScrumMaster the best?

Project Manager as ScrumMaster?
The seemingly obvious traditional role to play a ScrumMaster is the Project Manager. However, from my experience, there are pros with having a Project Manager become the ScrumMaster. On the positive side, the Project Manager has experience in being part of the team, so they may already have a trusting relationship with the team. Some Project Managers have built facilitative skills to lead work in a non-directive yet influential manner. And many already have the skills and the insight into an organization to appropriately remove roadblocks. On the negative side, Project Managers typically do not have technical experience into the product and cannot materially participate in technical discussions or provide meaningful technical insight. Also, some Project Managers had success utilizing command-and-control attributes and the more traditional Project Management practices which will not work well (and can be destructive) in an Agile environment. It can also be hard for some Project Managers to eliminate the traditional Project Management mindset of detailed project planning.

Functional Manager as ScrumMaster?
Quite possibly the most problematic role to play the ScrumMaster is someone who is a Functional Manager (aka, line manager, technical manager, etc.). Anyone playing a role where they have successfully directed people must make concerted efforts in removing their command-and-control behavior. On the positive side, they may have some technical experience into the product so can provide meaningful technical insight. They may already have the skills and the insight into appropriately navigating the organization and the ability to remove roadblocks. On the negative side, because they have been a manager of a team, so they may have issues with the team trusting them as a peer since they have been used to being judged by managers. A Functional Manager may have been successfully utilizing command-and-control attributes. However, this will not work well (and can be destructive) in an Agile environment. They must strive to remove their directive attributes and instead build facilitative skills. They must not assign work but instead enable and support team to become self-empowered. These are significant challenges.

Technical Lead as ScrumMaster?
Quite possibly one of the better traditional roles to play the ScrumMaster is someone who is a Technical Lead (QA Lead, Development Lead, etc.). By “lead”, I do not mean a manager or someone who has direct reports, but instead someone who is considered a lead by his peers. This person has a balance of leadership skills while wanting to get the work done. They typically have no interest in directing people. On the positive side, they have technical experience into the product and their specific field (development, QA, technical writing, etc.) so can appropriately aid the work (without direction or coercion and provide meaningful insight). They have experience at being part of the team, so may already have a trusting relationship with the rest of their peers. Because a lead does not have functional management responsibilities, they typically had to build their facilitative skills to lead work in a non-directive yet influential manner. On the negative side, they may not yet have the skills or the insight into an organization to appropriately remove external facing roadblocks.

Ultimately, the best answer to the question of what role best plays the ScrumMaster is not really a particular role, but instead which person best exemplifies the combination of the attributes of servant leadership, understands the Agile values and principles, embraces continuous learning, has a grasp of the technical aspects of the product under development, and can help remove roadblocks. In your organization, are there traditional roles that more often play the ScrumMaster role or best align with the servant leader attributes? If so, what is that role?  If not a role what attributes best exemplify a ScrumMaster in your organization?

----------------------------------------------------------------------------------------------------
PS - if you liked this article, consider reading "Who makes the Best Product Owner".