What are 3 big AI Shifts in the midst 2026?

AI is leaving the “wow” phase and entering the “prove it” phase. Many companies are about to realize their strategy was built for demos, not reality. In other words, AI is growing up. It’s time to move on from the hype toward the hard tradeoffs. What are 3 big AI shifts?

• Magic to Money 
• Demos to Deployment 
• Capabilities to Consequences

For the past few years, AI has lived in the realm of spectacle—impressive demos, viral moments, and “did you see what it can do?” reactions. That phase is ending. What’s replacing it is more grounded, more valuable, and a lot less comfortable. 

AI is shifting from magic to money, demos to deployment, and capabilities to consequences. Let’s examine these more fully.

Magic to Money

The novelty is wearing off. Organizations are no longer impressed that AI can generate content, write code, or analyze data. People are asking whether it actually drives revenue, reduces cost, or creates a defensible advantage. This is where many AI initiatives encounter friction: what initially appears magical, struggles when tied to real business metrics, messy data, and existing workflows. A current challenge is proving consistent, measurable ROI, not just isolated wins and talk.

Demos to Deployment

We’ve all seen the polished demos. But deploying AI into production is a different game entirely. Integrations, governance, reliability, edge cases, and user adoption quickly surface. The gap between “it works in a demo” and “it works every day in real life” is where most efforts stall. The winners are no longer the ones with the flashiest models, but rather those who can operationalize them at scale. A current challenge of getting to “real life” is bridging the last mile from prototype to dependable, repeatable execution.

Capabilities to Consequences

As AI capabilities grow, so do concerns about accuracy, bias, job displacement, environmental cost, security, and trust. Leaders are increasingly forced to weigh not just what AI can do, but what it should do and what risks they’re willing to accept. The conversation is shifting from innovation to responsibility, often faster than organizations are prepared for. A current challenge is how to manage risk and accountability without slowing innovation to a crawl.

What shifts are you seeing, and what challenges are you facing in getting to the full usage of AI?

Risk of AI Sameness

Everyone is racing to adopt AI tools.  Most people are using AI to create “speed”.  Faster emails. Faster proposals. Faster code. Faster content. And yes, faster is good.  But here’s the quiet risk no one is talking about: if everyone in your company uses the same AI the same way, you may slowly start sounding exactly alike.

Are you ignoring “AI sameness” risk? Without intention, standard AI tools can homogenize your messaging, flattening distinct perspectives into one generic voice. The danger isn’t bad output. It’s average output at scale. AI isn’t going to replace your team. It’s going to standardize them, but not in a good way.

When everyone uses the same tools, trained on the same data, prompted in the same way, you don’t get divergence, you get convergence. Everyone will sound the same, with the same sentence structure and tone, and with the same “polished but generic” voice. Then there is the further danger that over time, unique thinking gets flattened into safe, average, AI-shaped output. Not because your people aren’t smart, but because the tool defaults to the statistical middle.

AI should amplify your edge, not sand it down. AI should sharpen your thinking, make it more opinionated, and more differentiated. If you’re not intentional about how your teams use it, it can lead to this sameness.  What can you do to avoid this sameness?

• Craft your own perspective before prompting AI.  As it relates to the topic, what do you actually believe? What do most people get wrong about this? What would you argue in a debate?
• Use AI to provide you with a draft, not the deliverable. Within that context, establish one strong opinion. Provide one specific example from your world. Craft your own voice so that sentences sound unmistakably like you.
• Add Friction to the output. AI will often be a people pleaser, so challenge your output. Ask what’s missing. Determine if it feels too safe. Consider if it sounds too predictable? If it reads smoothly but doesn’t make you think, that’s a warning sign.

AI naturally drifts toward the statistical middle. Avoiding sameness requires intentionally looking for differences. It must include injecting strong beliefs, specific context, and human judgment layered on top.  And honestly? The companies that figure this out won’t just use AI faster. They’ll use it to amplify their uniqueness.

AI Coding: Shifting the Developer Role

Coding with AI is producing code at a faster rate than ever and accelerating the release of production increments. The code can be generated in minutes and feels good because of how quickly it is created. This begs the question, what does the software developer do now?  It changes where the developer’s focus goes. 

While AI is generating the code, it doesn’t own the code.  The developer remains accountable for it, which means they must review the code deeply enough to understand how it works, why it works, and where it could fail. Also, they must focus on verification activities surrounding the code. This article is based on some experimentation with AI and ensuring the developer has a good understanding of the code changes. 

Think of AI as a Junior Engineer, and it is your job to raise them up. It can produce a lot of code quickly, and it can be confidently wrong when doing so. It has no sense of risk, context, or consequences.  Think of the verification as the handoff where ownership transfers to a human. It is still your job to ensure a verified and quality outcome. This should take a majority of engineering time or later on, logical gaps leading to failures in services, data, and infrastructure. How does the Developer responsibility shift?

• Review code written for understanding.  Ask the AI tool to explain to you what this code does, line by line. Ensure it's not vague and be sure it aligns with what you are thinking. Ask what the expected outputs and outcomes would be. Then ask what would break the code. Finally, ask AI why this approach was chosen over alternatives. A useful litmus test is if you wouldn’t feel comfortable maintaining this code for the next year, you don’t understand it well enough
• Ensure that the code was version-controlled properly and in the correct branch. This includes checking for potential issues before merging it into the main codebase.
• Step up Code Reviews.  This means to peer-check code for quality and adherence to standards.  The Developer should share coding standards with the AI tool to ensure it aligns with standards. If coding standards are missing, then they must be written and then added to the AI tool’s vector of information.   
• Spend time sharing responsibilities with Testing to ensure all verification activities are completed.  This should include appropriate testing: Unit Testing (e.g., testing individual components or functions in isolation), Integration Testing (e.g., testing how different components work together), System Testing (e.g., testing the system as a whole for speed, scalability, and stability), and more. 

AI reduces typing time. It does not absolve you of the responsibility and judgment for a product well built! AI changes where time is spent, not whether time is spent. While we will spend less time coding, we are still accountable to spend time verifying and understanding the code that has been generated to ensure it meets the needs of the outcomes we are looking for.  

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

What does the 8th Agile Principle (Sustainable Pace) 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 eighth 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.  

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. The concept of sustainable pace has been quantified by Kent Beck, who recommends working no more than 40 hours a week and never working overtime for more than one week at a time (not consecutively). When you maintain a reasonable pace, you can sustain a constant pace indefinitely. Studies have shown that when you consistently work more than 40 hours a week, overtime produces lower-quality software and reduces productivity.

Another driver for sustainable pace is the concept of social responsibility: the obligation to benefit the people as a whole and maintain a work/life balance. Another key to a strong Agile team is the notion that no one succeeds unless everyone succeeds. This promotes team spirit, whereby members collaborate and help each other out so that no one or two people are burdened with extra work while others have free time. To do this, each team member should gain secondary skills so they can ramp up quickly and support other work should there be a bottleneck. Even building tertiary skills are a consideration. A side effect of sustainable pace is that it often leads to improved team morale. Folks do not feel burned out and come to work with fresh minds, which can lead to innovative and creative ideas. Now that we better understand the principle, what actions exhibit working software as the measure of progress?

• Each member of the team works only 40 hours a week and never overtime for more than one week. 
• Velocity may be used as a measure to define the number of story-points a team can complete in an iteration or sprint to help maintain a sustainable pace. 
• Management trusts the team’s sizing of the work and team’s velocity without question. 
• Management does not force the team to work longer hours or initiate death marches. 
• All team members have secondary skill sets and pitch-in with other team members when needed. 
• Team members willingly engage in meaningful and relevant problems or opportunities exhibiting creativity and critical thinking. 

It is up to you to determine what supporting evidence looks like when a company believes in sustainable development for employees in order 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 “Sustainable Pace”?

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

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

What do the first 6 Agile Principles look like in Action?

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 first 6 Agile principles in an attempt 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 first 6 Agile principles and what they might 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 

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. Good luck on your Agile journey!

PS - Stay tuned for articles that provide insight into the next 6 Agile principles.

What does the 7th Agile Principle (Working software is the measure of progress) 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 seventh principle to better understand what it means. More importantly, I attempt to identify what evidence looks like to determine if there is alignment to the principle and if a culture change may be occurring. Let’s take a deeper dive into this principle.  

Working software is the primary measure of progress. From an agile perspective, working software is the best measure of progress. Working software must be produced at the end of each time-boxed period (sprint). You may use other measures to help gauge progress, such as Sprint Burndown, but they should be minor in relation to the criterion of working software. 

The reason for this new thinking on measures is that when you follow a waterfall process, you may be 50 percent through the project schedule and have no working software. From a customer perspective, you haven’t accomplished anything. Although there may be internal benefits to gathering requirements, preparing a plan, and doing design and development work, an external paying customer only values the actual working software. You don’t get credit for in-progress stuff, only the working software. 

This is why, at the end of each time-boxed period, working software is delivered and validated with the customer during the demo. In addition, working software must meet "done criteria" to ensure high quality of the result. Now that we better understand the principle, what actions exhibit working software as the measure of progress?

• There is a measure that tracks progress associated with working software (e.g., features, functionality, etc.) that is available in UAT and production.
• Sprint Reviews are conducted to demonstrate the working software and gain customer feedback.
• There are measures associated with customer usage and customer satisfaction of working software. 
• There is a measure (i.e., Sprint Burndown) that tracks teamwork done and work remaining. 
• Done criteria are established that reflect engineering standards that are applied to user stories to determine if the work is done. 

It is up to you to determine what supporting evidence looks like when a company believes that Working software is the measure of progress and the advantages it brings. 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 “Working software is the measure of progress”?

-----

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: http://cmforagile.blogspot.com/2024/05/what-does-6th-agile-principle-face-to.html

What does the 6th Agile Principle (Face-to-Face Conversation) look like in Action?

 Many want to go Agile or claim to be Agile. The question is, will you align with the Agile values and principles? In this article, I expand on the sixth principle to better understand what it means and attempt to identify what evidence looks like to determine if a culture change may be occurring. What is this principle?  

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Agile puts a premium on face-to-face communication. Because of the nonverbal cues built into communication, there is a benefit of harvesting visual cues during interpersonal interactions. Face-to-face discussion improves the overall communication experience and understanding. From an Agile perspective, a team (about seven people +/-) should be as collocated as reasonable or use technology to emulate face-to-face interaction as much as possible. 

With communication comes the importance of listening. Listening means hearing and understanding what the other is saying and what they are not saying (hence the importance of nonverbal cues). Face-to-face also helps with understanding silence. Is silence due to a lack of understanding, not being engaged, or other reasons? Face-to-face nonverbal cues can help probe the reason. Another aspect of collaboration is being assertive. Quietly listening does not lead to building ideas. Therefore, communication is a balance between being a collaborative speaker and a respectful listener. With this in mind, what tangible actions exhibit promoting face-to-face communication? 

• A team is collocated or, if not, then when meeting, the cameras are on.
• Teams are kept small (about seven +/-).
• Conference rooms or team rooms are available for face-to-face conversation.
• Technologies are used to emulate face-to-face discussion whenever collocation is not possible.
• Whiteboards in the collocated team room or technologies used to emulate whiteboards as means to visualize, brainstorm, and collaborate on topics.
• Listening and collaboration skills are emphasized.

It is up to you to determine what supporting evidence looks like when a company believes in face-to-face communication and the advantages it brings. 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 face-to-face conversations?

------

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

What does the 5th Agile Principle (Motivated Individuals who are Trusted) look like in Action?

Many want to go Agile or claim to be Agile. The question is, will you align with the Agile values and principles? In this article, I expand on the fifth principle to better understand what it means and attempt to identify what evidence looks like to determine if a culture change may be occurring. What is this principle?  

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Agile recognizes providing employees with ownership of their work can increase engagement, productivity, and happiness. There are strategies to get employees engaged, continually educated, and building on their strengths. Management values employee opinions, appreciates them, and trusts that they can get the work done. 

With communication comes the importance of listening. Listening means hearing and understanding what the other is saying and what they are not saying (hence the importance of nonverbal cues). Face-to-face also helps with understanding silence. Is silence due to a lack of understanding, not being engaged, or other reasons? Face-to-face nonverbal cues can help probe the reason. Another aspect of collaboration is being assertive. Quietly listening does not lead to building ideas. Therefore, communication is a balance between being a collaborative speaker and a respectful listener. With this in mind, what tangible actions exhibit promoting face-to-face communication?

• Teams have the ability to make decisions, such as how to complete and size their own work.
• Management trusts team decisions and minimizes command and control.
• Teams are kept whole and members are treated like people, not fungible resources.
• Management provides transparency in decision making.
• Management provides organizational goals such as employee engagement. 
• The PO provides release and sprint goals.
• Team members demonstrate their working software during sprint reviews.
• The Scrum Master provides a servant–leader approach.

It is up to you to determine what supporting evidence looks like when a company believes in motivating individuals and trusting them to get the job done. 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 that business and development should work continuously together as a team?

------

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

What does the 4th Agile Principle (Business and Development Work Together) look like in Action?

Many want to go Agile or claim to be Agile. The question is, are you and will you align with the Agile values and principles? In this article, I expand on the fourth principle to better understand what it means and attempt to identify what evidence looks like to determine if a culture change may be occurring. What is this principle?  

Business people and developers must work together daily throughout the project. Agile attempts to bring an understanding of business value to the development team and the technical choices and challenges to the business side. To do this, it attempts to integrate business and development as one team. In traditional approaches, there is often little interaction between the business (e.g., product management, sales, and marketing) and development (aka, cross-functional technical team). On the business side, this may be the Product Manager or Business Owner. Scrum introduces the Product Owner (PO) role and XP introduces the Customer role as the bridge between the customer and the development team. These roles allow for a closer embodiment of the business and development team spirit and avoid fiefdoms and throwing work “over the wall” from one group to another with little interaction. 

The intent is to make a sincere effort to build a collaborative and amicable yet productive relationship between business and development. Development benefits from a better understanding of what the customer finds valuable. The business side benefits because development will ask for details that the business may not have thought about. In both cases, the result is a product that more closely aligns with what the customer finds valuable. What actions and evidence exhibit business people and developers working together?

• An established and productive relationship between business/customers and development
• A dedicated business owner who works continuously with the development team. 
• Development comprises a cross-functional team with developers, testers, technical writers, designers, and so on. 
• The business owner with the development team work together during iterative planning to build a mutual understanding of the requirements of what to build. 
• The development team demos the working product to the business owner and customers to gain feedback to better align with customer value. 
• The development team can reach out to the business owner whenever needed throughout the project lifecycle.   

It is up to you to determine what supporting evidence will highlight that continuous integration, build, test, and frequent delivery is occurring. 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 that business and development should work continuously together as a team?

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

To learn more about what the Agile Principles look like in Action, consider reading:

• 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

What does the 3rd Agile Principle (Frequent Delivery) look like in Action?

Many want to go Agile or claim to be Agile. The question is, are you and will you align with the Agile values and principles? In this article, I expand on the third principle to better understand what it means and attempt to identify what evidence looks like to determine if a culture change may be occurring. What is this principle?  

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale is the third Agile principle. This principle promotes the ability that when customers believe there is value in what is built, it can be immediately delivered. Identifying the elusive customer value means you can release it when the customer wants it. If it is delivered too early, the customer may not be ready for it; if it is too late, the market opportunity is missed. 

Agile thinking includes a fluid world, where changes are continuous welcome, and teams have the capability of releasing frequently. This ability to frequently release, highlights the importance of having processes and infrastructure to help with continuous integration, build, and test. This ability assumes a level of automation that needs to be in place. Automated testing increases the possibility of testing the functionality as is reasonable, including the capability of performing non-functional testing such as performance testing, load testing, and more. 

What actions exhibit frequent delivery?  

• An established and positive relationship with customers
• Iterative framework with Sprint Reviews to incorporate feedback quickly 
• A release capability to incrementally and rapidly deploy software 
• Continuous integration supported by a merging process and configuration management system 
• A continuous build process supported by an automated build management system 
• Test automation infrastructure that can support continuous testing  

It is up to you to determine what supporting evidence will highlight that continuous integration, build, test, and frequent delivery is occurring. It is worth experimenting with this as it will help you better understand and embrace the Agile principles. The ultimate question, do you really believe in the principle that focuses on frequent delivery?

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

To learn more about what the Agile Principles look like in Action, consider reading:

• 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

What does the 2nd Agile Principle (Welcome Change to Requirements) look like in Action?

Many want to go Agile or claim to be Agile. The question is, are you and will you really align with the Agile values and principles?  To better understand what this means, I dissected the Principles to better discover the intentions behind them and what behaviors they entail. In this article, I expand on the second Principle to better understand what it means and to attempt to model how to marshal supporting evidence that a culture change may be occurring.  

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage is the second Agile principle. From an Agile perspective, you embrace change to increase the chances of delivering value to the customer. You embrace change because you understand that change is necessary as customer needs, market conditions, and general demand change over time. 

Welcoming change implies several qualities. The first is that there is a positive attitude toward change from the team and management. The second is that while change ideas are admitted, they are methodically prioritized based on customer value along with existing requirements. The third is that there is a process that allows prioritized changes to flow without obstruction.

What actions may exhibit “welcoming change to requirements”? Some evidence includes:  

• The PO continually engages with the customer to identify new requirements or changes to existing requirements. 
• A methodical review of the change idea occurs to determine the priority amongst the existing requirements.
• No person or process restricts incoming change ideas. 
• The backlog is continually refined and reprioritized. 
• Increment Planning and/or Sprint Planning is applied to introduce the newly prioritized requirements. 
• Continuous customer engagement via customer visits and sprint reviews are applied. 

It is up to you to determine what supporting evidence will highlight that a culture change is occurring. It is worth experimenting with this as it will help you better understand and embrace the Agile principles. The ultimate question, if you really believe in this principle is, do you welcome change?

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

To learn about what evidence might look like to support the 1st Agile Principle (aka, Satisfying Customer with Valuable Software), consider reading: https://cmforagile.blogspot.com/2023/09/many-want-to-go-agile-or-claim-to-be.html

What does the 1st Agile Principle (Satisfying Customer with Valuable Software) look like in Action?

Many want to go Agile or claim to be Agile. The question is, are you and will you really align with the Agile values and principles?  To better understand what this means, I dissected the Principles to better discover the intentions behind them and what behaviors they entail. In this article, I expand on the first Principle and attempt to model how to marshal supporting evidence that a culture change may be occurring.  

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software is the first Agile principle.  Satisfying the customer means delivering valuable software in a timely manner (that is, in the market window) for a reasonable cost. Continually striving to meet elusive customer value is important. Ultimately, the key measure of value for customers is an increase in sales and the continued loyalty of existing customers. 

How do you know that you are moving in the right direction of building value? It starts with understanding your customers: who they are and what motivates them. Their profiles include such information as their challenges, their vision for your product, and their buying trends. 

Delivering value continues with an effective sprint review process where the customer gains an opportunity to review and provide feedback on working software. If customers can sense that their input is valued during the demos, their satisfaction can increase. This is particularly true if the customers see that their feedback from the last demo has been incorporated in the working software of the current version. 

In addition, it is beneficial to use the Business Owner/Product Owner (PO) as the delegated voice of the customer to solicit acceptance criteria on what the customer would expect when they see a particular requirement or feature in action. You may also conduct periodic customer surveys to gauge their level of satisfaction with the product or solution. 

What actions exhibit “satisfying customer with valuable software”? 

• The PO works to understand customer value, constantly prioritizes and refines the backlog, and discusses customer needs with the team. 
• The PO creates customer profiles to recognize motivations. 
• The backlog is your single source of requirements (aka, value). 
• The Customer vision reflects how you wish to engage your customers. 
• Business Strategy focuses on delighting the customer. 
• Customers are an integral part of Reviews to provide feedback and validate value. 
• Acceptance criteria are been captured and met for each user story. 
• Customer satisfaction surveys are periodically conducted. 
• Customer revenue metrics are captured and reviewed.  

It is up to you to determine what supporting evidence will highlight that a culture change is occurring. It is worth experimenting with as it will help you better understand and embrace the Agile principles. The final question, if you really believe in this principle, do you believe in continuous customer engagement, adapting requirements, and validation as a means of building valuable software to satisfy the customer? 

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

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

• 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: https://cmforagile.blogspot.com/2024/04/what-does-5th-agile-principle-motivated.html

Importance of Agile Readiness for a Transformation

To be a successful farmer, one must first know the nature of the soil.  —Xenophon, Oeconomicus 

Have you ever been in a daily stand-up where everyone was reporting status to the one person they thought was the leader or where most didn’t know why they were doing a stand-up every day or ever? This highlights a lack of readying the mind for what a daily stand-up is and why we are doing it.  A lack of readiness can stall or halt an Agile transformation because people aren’t in the right frame of mind for transitioning to Agile.

Readiness starts the moment when the question, “Is Agile right for me?” is asked. Readiness activities can help you better determine if Agile is right for you. Agile readiness is akin to conditioning and fertilizing the soil before growing the seeds. It is good to take a realistic look at the conditions of the fields, equipment, and people. Conditioning the mind with an understanding of Agile principles improves the ability to adopt Agile in a way that leads to truly being Agile. Strengthening the soil helps improve the physical qualities of the soil, especially in its ability to provide nutrition for plants. They can make poor soil more usable and rebuild soil that has been damaged by improper management.

This is exactly what readiness activities can do. Examine the condition of the environment where Agile is being considered. Understand and educate people on the Agile values and principles and the business benefits that can be gained. Gauge the buy-in from leaders and the willingness and capability of teams. Determine if openness or command-and-control behaviors are being exhibited (explicitly or implicitly). Understanding this context provides valuable insight into ways to adapt and move forward.  What we learn, can help shape the agile implementation according to the condition and context of an organization.

You do not need to complete all readiness activities to begin implementing, but I have learned that if you begin implementing Agile, you quickly realize that you will need to address these areas, so it is better to be proactive. With this in mind, an iterative approach may be used. Here are high-level readiness activities that you may consider. As always, feel free to adapt this list of activities if it benefits you.

• Establish a common understanding of Agile.
• Construct and share the drivers for an Agile organizational change.
• Provide Agile mindset education based on Agile values and principles. Then determine subsequent educational needs.
• Add “Customers and Employees Matter” to the company vision and share this with employees.
• Gauge levels of executive and stakeholder buy-in.
• Establish an overall strategy and backlog for the agile transformation.
• Determine team willingness and capability.
• Identify allies, champions, and subject matter experts (SMEs) and resources.
• Identify and establish agile roles and organization.
• Establish agile frameworks and practices that may be used. (A flexible framework, as each team is different.)
• Craft measures of success to include value, flow, and quality metrics.
• Establish done criteria, user story framework, and sizing techniques.

A benefit of readiness activities is that you can adapt the transformation approach based on what you learn. Another advantage is that if you find that there are challenges in an area, you can address and improve the situation. For example, you may find that there is not a clear driver for moving to Agile. This can initiate discussions on the business benefits of Agile, motivational factors behind the move, and what it takes to be Agile.

Consider Agile readiness activities as the first increment in your transformation. The outcome of Agile readiness and what you’ve learned can help you better plan the next iteration. Finally, I recommend that once you embark on these activities, you initiate periodic check-ins to gauge progress, mitigate roadblocks (such as risks and issues), and adapt along the way.