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.

The benefits of Divergent and Convergent Thinking

Divergent thinking embraces an approach that promotes collaboration to generate ideas and numerous solutions with no censoring of ideas.  Once an allocated timebox to share and discuss ideas and options is concluded, divergent thinking is paired with convergent thinking which are approaches to more quickly come to consensus. This is illustrated below.

A traditional divergent technique is brainstorming which focuses you on generating ideas in an unstructured manner.  But due to the fast pace of most companies, we are quick to shutdown brainstorming by criticizing the options of others (including our own). Because of this, I recommend 15 minutes of silence for all brainstorming activities to ensure all ideas get a chance to be revealed prior to any discussion,

People generate their ideas with no discussion so no one’s ideas are dismissed by those more assertive or intimidating. As you may guess, often the quiet team members (aka, introverts) have some of the best ideas and a divergent “quiet” period allows the talented introverts to get their ideas on the table.  The key to divergent thinking is that there is absolutely no censorship of the ideas or solutions coming forth.  All ideas are valuable. 

Once the divergent time-box is concluded, it is time to commence with convergent thinking.  Convergent thinking is an approach to systematically limiting your options and focus on one direction. From divergent thinking, there are often more ideas and possible solutions than can be handled. 

In convergence, various techniques can be applied to bring together ideas.  This may include looking for affinities where common themes may arise from some of the ideas.  It can also include red-dot voting, a non-confrontational prioritization technique where people quietly place their dots on what they think are the top ideas for solving the problem.  Ideas with the top number of dots are discussed until a top option is selected.    

The value of divergent thinking cannot be underscored.  Spending as little as a few hours of collaborative brainstorming coming up with ideas is a drop in the bucket of the thousands of hours spend in building a solution.  The tiny investment is worth ensuring that many options are made available. 

Also, the divergent and convergent pairing can occur in a continuous manner.  For every customer need expressed in a user story, in the beginning of an iteration or sprint, divergent thinking can be used in sprint planning to consider options prior to jumping into the sprint where you build the customer need. When the next iterative or sprint begins, we move back to divergent thinking to consider options for the next step of user stories prior to embarking on the sprint.    

It is also very important to be explicit about whether you are in a divergent or convergent thinking mode. Some people naturally gravitate toward divergence while others gravitate toward convergence.  It can reduce issues in interpersonal relationships to explicitly state whether you are in a divergent or convergent mode so that it is clear whether you are soliciting options or closing down options.  

Finally, when you have an organization that is constantly pushing you to move forward, convergence is stressed whether consciously or unconsciously and this is a detriment to innovation and being open to numerous possible solutions.  It may take an organization to explicitly initiated divergent thinking to achieve more innovation and ideas.  

Leading with Agile Principles!

What does it mean to be Agile? It starts with aligning with Agile values and principles. In this short guide, I provide insight into the 12 Agile principles look like in action. The goal is to identify what evidence would look likes to determine if there is alignment with these principles, if a culture change may be occurring, and to prove the assertion that you are indeed Agile. 

Let’s take a closer look at each of the Agile principles and what they might look like in action (each in their own one-page article).

• 1st Agile Principle:  Satisfying Customer with Valuable Software
• 2nd Agile Principle: Welcome Change to Requirements
• 3rd Agile Principle: Frequent Delivery
• 4th Agile Principle: Business and Development Work Together
• 5th Agile Principle: Motivated Individuals who are Trusted
• 6th Agile Principle: Face-to-Face Conversation
• 7th Agile Principle: Working Software as Measure of Progress
• 8th Agile Principle: Sustainable Pace
• 9th Agile Principle: Technical Excellence
• 10th Agile Principle: Simplicity
• 11th Agile Principle: Self-Organizing Teams
• 12th Agile Principle: Reflection for Improvement

It is up to you to determine what supporting evidence looks like when a company believes in each of the Agile Principles. It is worth experimenting with this as it will help you better understand and embrace the Agile principles and put them into action in your organization. Good luck on your Agile journey!

What does the 12th Agile Principle (Reflection for Improvement) look like in Action?

What does it mean to be agile? It starts with aligning with Agile values and principles. In this article, I expand on the twelfth principle to better understand it. More importantly, I attempt to identify evidence of what this principle looks like in action. Let’s take a deeper dive into this principle. 

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Reflecting on the need for improvement is critical to the adaptive framework and the Agile mindset. Although what has occurred cannot be undone, reflecting on it can lead to action that will prevent the issue from recurring. With this in mind, the team should apply a periodic retrospective to reflect on the previous improvements and become more effective in the future. 

Remember, the team is self-organizing, so they own the practices, techniques, rituals, and behaviors. A key to real improvement is that team members are willing to let their guard down and be open and honest with each other. Otherwise, only the more superficial areas are discussed. Also, retrospectives should be private and closed sessions so “dirty laundry” can be discussed. The Scrum Master may act as the facilitator so that it is kept professional to identify actions for improvement. Another key is that the team commits to support continuous improvement. 

Teams may use root-cause analysis techniques such as Ishikawa (fishbone) diagrams to identify the cause of specific issues. In addition, Agile applies an empirical approach whereby data can be used to identify areas for improvement and help in decision-making based on observation and experimentation. However, it is for the team to make the commitment to adapt and improve. What actions exhibit reflection for improvement? 

• Team retrospectives are scheduled periodically to identify and prioritize areas for improvement. 
• The team is open and honest so that real improvement can be made.
• Root cause analysis is used to determine what real actions will result in actual improvements.  
• The team commits to implementing improvement actions. 
• Retrospective actions are tracked, and progress is discussed in the retrospective session. 
• The results of the improvement actions are discussed to determine if the actions had the desired improvements. 

Do you believe in reflection for improvement and the activities that empower a team to improve? It is up to you to determine what supporting evidence looks like when a company believes in reflection for improvement. It is worth experimenting with this, as it will help you better understand and embrace the Agile principles. The ultimate question is, do you believe in the benefits of “Reflection for Improvement?”

---------

Learn more about what other Agile Principles look like in action:

• 1st Agile Principle (Satisfying Customer with Valuable Software) 
• 2nd Agile Principle (Welcome Change to Requirements) 
• 3rd Agile Principle (Frequent Delivery) 
• 4th Agile Principle (Business and Development Work Together) 
• 5th Agile Principle (Motivated Individuals who are Trusted) 
• 6th Agile Principle (Face-to-Face Conversation) 
• 7th Agile Principle (Working Software as Measure of Progress) 
• 8th Agile Principle (Sustainable Pace) 
• 9th Agile Principle (Technical Excellence) 
• 10th Agile Principle (Simplicity) 
• 11th Agile Principle (Self-Organizing Teams) 

What does the 11th Agile Principle (Self-Organizing Teams) look like in Action?

What does it mean to be agile? It starts with aligning with Agile values and principles. In this article, I expand on the eleventh principle to better understand it's meaning. More importantly, I attempt to identify evidence to determine if there is alignment with the principle and if a culture change may be occurring. Let’s take a deeper dive into this principle. 

The best architectures, requirements, and designs emerge from self-organizing teams.  Self-organizing teams have a combination of greater ownership and responsibility to achieve a common goal of building valuable software and reducing dependency on management. The team has the authority to self-organize and make decisions regarding architecture, requirements, and design as they evolve the product. The team needs to be cross-functional so that they have the skills and talent to make the decisions to develop the product. 

A self-organized team moves away from the command-and-control hierarchy in which one person assigns the work. Instead, a self-organizing structure is one in which everyone participates in decision-making and proactively volunteers for work from the backlog. This is easier said than done. Therefore, before considering Agile, an assessment of the openness of the culture helps gauge the starting point. 

Having self-organizing teams also means thinking beyond the individual, since singular thinking can constrain collaboration and the team mindset. The focus should be on instilling team spirit: “You only succeed if the team succeeds.” Rewards should be team-based to drive the concept home. 

Teamwork also means hierarchy—such as title, levels, grades, heroes, and egos—needs to be removed as barriers to team success. Instead, promote equality among roles. Treating everyone on the team as equals leads to more engaged members. Nonetheless, team members should respect the fact that some people have more experience and skills in certain areas and others can gain from this experience. What actions exhibit self-organizing teams?

• The team makes decisions about its work, specifically regarding architecture, requirements, design, and sizing or estimating. 
• Cross-functional teams include the right mix of skills among developers, testers, technical writers, UX designers, the PO, and the Scrum Master. 
• There is no hierarchy on the team, although levels of skills and experience are respected. 
• Rewards are given at the team level. 
• Team members pull work from the backlog at their own initiative, rather than being assigned to it by their manager. 
• Management reduces command and control and provides boundaries of authority. 
• Management articulates goals to help the team focus their work so that teams can make their own decisions. 

Do you believe in self-organizing teams who have authority to make their own decisions, manage their own work, and are rewarded as a team? It is up to you to determine what supporting evidence looks like when a company believes in self-organizing teams. It is worth experimenting with this as it will help you better understand and embrace the Agile principles. The ultimate question is, do you believe in the benefits of “Self-organizing teams”?

--------

Learn more about what other Agile Principles look like in action:

• 1st Agile Principle (Satisfying Customer with Valuable Software)
• 2nd Agile Principle (Welcome Change to Requirements) 
• 3rd Agile Principle (Frequent Delivery) 
• 4th Agile Principle (Business and Development Work Together)
• 5th Agile Principle (Motivated Individuals who are Trusted)
• 6th Agile Principle (Face-to-Face Conversation) 
• 7th Agile Principle (Working Software as Measure of Progress) 
• 8th Agile Principle (Sustainable Pace) 
• 9th Agile Principle (Technical Excellence) 
• 10th Agile Principle (Simplicity) 

What does the 10th Agile Principle (Simplicity) look like in Action?

What does it mean to be agile? It starts with aligning with Agile values and principles. In this article, I expand on the tenth principle to better understand what it means. More importantly, I attempt to identify evidence to determine if there is alignment with the principle and if a culture change may occur. Let’s take a deeper dive into this principle. 

Simplicity—the art of maximizing the amount of work not done—is essential. Striving to eliminate unnecessary work is the goal. This should include identifying the minimum number of features needed for a customer release (MVP) to be successful. It should include reducing non-value-added work that team members are asked to do. It may involve reducing unnecessary steps of a process to deploy a release. 

To simplify, you need to proactively remove the seven wastes in software development as defined by Mary and Tom Poppendiek in their book Lean Software Development: An Agile Toolkit. This includes eliminating partially done work, extra features, the need to relearn, hand-offs, task switching, delays, and bugs. 

Agile thinking focuses on short iterations and small increments. This way you can fail fast, learn, eliminate waste, and then succeed more quickly. You may also right-size your documentation with a focus on documenting decisions and why you made them. What actions exhibit simplicity? 

• There is continuous focus on staying lean and removing waste via retrospectives. 
• During demonstrations, customers are asked not only what they need but what they don’t need. 
• The Product Owner applies continuous prioritization via the backlog with a focus on minimum viable product (MVP). 
• Documentation is right-sized and includes key decisions and their rationales. 

Do you believe in simplicity, removing waste, and continuously prioritizing requirements based on customer value? It is up to you to determine what supporting evidence looks like. It is worth experimenting with this as it will help you better understand and embrace the Agile principles. The ultimate question is, do you believe in the benefits of “Simplicity”? 

---------

Learn more about what other Agile Principles look like in action:

• 1st Agile Principle (Satisfying Customer with Valuable Software) 
• 2nd Agile Principle (Welcome Change to Requirements) 
• 3rd Agile Principle (Frequent Delivery) 
• 4th Agile Principle (Business and Development Work Together)
• 5th Agile Principle (Motivated Individuals who are Trusted) 
• 6th Agile Principle (Face-to-Face Conversation) 
• 7th Agile Principle (Working Software as Measure of Progress) 
• 8th Agile Principle (Sustainable Pace) 
• 9th Agile Principle (Technical Excellence) 

What does the 9th Agile Principle (Technical Excellence) look like in Action?

What does it mean to be agile? It starts with aligning with Agile values and principles. In this article, I expand on the ninth principle to better understand what it means. More importantly, I attempt to identify evidence to determine if there is alignment with the principle and if a culture change may be occurring. Let’s take a deeper dive into this principle. 

Continuous attention to technical excellence and good design enhances agility. To strive for technical excellence, you need team members who have knowledge and experience to produce sound architecture, good design, and quality software. It is important to have the capability of making the best technical decisions balancing design, usability, and maintainability. Such capability requires a seasoned and professional team. In Agile, employees should want to do the work in the context of career learning and growth. 

To strive for technical excellence, effective done criteria should be established that include engineering standards in design, UX, development, technical writing, configuration management, building, and testing. Achieving quality may include implementing various XP practices, such as continuous integration and build, coding standards, pair programming, refactoring, simple design, and test-driven development, which are applied to improve the technical excellence of a product. In addition, the use of retrospectives helps the team reflect on opportunities to build their skills and further achieve technical excellence. What actions exhibit technical excellence? 

• Team members motivate each other toward technical excellence, including collaborating on and agreeing to technical practices for the team. 
• Team members are applying continuous integration and build, coding standards, pair programming, simple design, refactoring, code reviews, and test-driven development. 
• Team members apply done criteria that include engineering disciplines needed to deliver a quality product. 
• Team members employ learning plans that include a focus on technical excellence that are actively managed. 

Do you believe in applying technical practices that promote technical excellence and provide technical educational opportunities for employees? It is up to you to determine what supporting evidence looks like when a company believes in sustainable development for employees to maintain a constant pace indefinitely. It is worth experimenting with this as it will help you better understand and embrace the Agile principles. The ultimate question is, do you believe in the benefits of “Technical Excellence”?

------

Learn more about what other Agile Principles look like in action:

• 1st Agile Principle (Satisfying Customer with Valuable Software) at: https://cmforagile.blogspot.com/2023/09/many-want-to-go-agile-or-claim-to-be.html
• 2nd Agile Principle (Welcome Change to Requirements) at: https://cmforagile.blogspot.com/2024/01/do-you-have-evidence-to-support-2nd.html
• 3rd Agile Principle (Frequent Delivery) at: https://cmforagile.blogspot.com/2024/02/what-does-3rd-agile-principle-frequent.html
• 4th Agile Principle (Business and Development Work Together) at: https://cmforagile.blogspot.com/2024/03/what-does-4th-agile-principles-business.html
• 5th Agile Principle (Motivated Individuals who are Trusted) at: http://cmforagile.blogspot.com/2024/04/what-does-5th-agile-principle-motivated.html
• 6th Agile Principle (Face-to-Face Conversation) at: https://cmforagile.blogspot.com/2024/05/what-does-6th-agile-principle-face-to.html
• 7th Agile Principle (Working Software as Measure of Progress) at: https://cmforagile.blogspot.com/2024/06/what-does-7th-agile-principle-working.html
• 8th Agile Principle (Sustainable Pace) at: https://cmforagile.blogspot.com/2024/07/what-does-8th-agile-principle.html