Introduction

Agile delivery is based on trust; “Individuals and interactions over processes and tools” and “Working software over comprehensive documentation” are two of the core values, often misinterpreted as a replacement of traditional ‘rigid’ governance. Initially, a challenge to the success of Lean Six Sigma, Agile, intentionally or not, didn’t provide specific metrics, seen as a sign of risk-averse organisations. However, in the quest for higher performance, and without clear and specific Agile metrics, organizations often turn to metrics from Lean Six Sigma—such as cycle time, throughput, defect rates, and process efficiency—to measure the success of Agile projects. These metrics seem objective and actionable, promising to optimize the flow of work. However, a deep ethical debate simmers beneath the surface: Are we measuring what truly matters? Are we rewarding teams for activity, or for genuine customer value? This blog post explores the ethical dilemma of measuring output versus measuring value in Agile environments, from an ethical perspective.

Challenges

The core challenge lies in the tension between what is easy to measure and what is truly meaningful. Lean Six Sigma metrics—cycle time, throughput, defect rates, and process efficiency—offer quantitative data that can be tracked and improved. In Agile projects, these metrics frequently become KPIs. In the true Agile mindset, the intent is to foster transparency and continuous improvement. However, many Agile practitioners argue that such metrics are against the Agile principles and risk shifting team focus from customer outcomes to productivity statistics.

For example, a team may prioritize closing more tickets or delivering more story points each sprint, believing that these numbers reflect success. But what if those tickets represent features that customers don’t use, or story points accrue for technical tasks disconnected from business value? As Ron Jeffries, one of the authors of the Agile Manifesto, has cautioned, “Delivering more stories faster does not ensure delivering more value.”. Moreover, there are teams assigning story points to defects and adding them to ‘velocity’. Sizing defects is useful only for planning and for calculating the percentage of rework, another Lean Six Sigma metric, but not to improve the team’s ‘performance’

Teams can, intentionally or not, game the system—maximizing throughput and activity without a corresponding increase in value delivered. The Agile Practice Guide and PMBOK both highlight the danger of “vanity metrics” that reward teams for busywork rather than outcomes.

This brings us to an ethical crossroads. According to the PMI Code of Ethics and Professional Conduct, project practitioners are obligated to act with responsibility, respect, fairness, and honesty. Is it fair or honest to reward a team for high throughput if their work has little impact on customer satisfaction? ISO 31000, the international standard for risk management, reminds us that risk is not just a matter of likelihood and impact but also of values and perceptions. If measurement systems promote the wrong behaviours, they introduce ethical risk into the organization.

Recommendations

How can teams and organizations resolve this ethical tension? The answer lies in re-balancing what we measure. Activity metrics have their place—they help identify bottlenecks and waste. However, they must be complemented by value-based metrics that reflect customer outcomes and business impact.

Here are five recommendations for ethically sound measurement:

1. Prioritize Outcome Metrics: Include metrics such as customer satisfaction, feature adoption, Net Promoter Score (NPS), and business impact. These offer a direct line to customer value.
2. Use Activity Metrics as Diagnostic Tools, Not Rewards: Cycle time and throughput help teams identify inefficiencies, but they should not be the sole basis for recognition or incentives.
3. Align Metrics with Agile Principles: As the Agile Manifesto states, the highest priority is “to satisfy the customer through early and continuous delivery of valuable software.” Measurement systems should reinforce this, not undermine it.
4. Encourage Transparency and Integrity: Make metric goals and their rationale clear to all stakeholders. Use data to foster honest conversations about improvement, not as a weapon.
5. Review Metrics Regularly: Collaborate with teams and customers to ensure that what you’re measuring remains relevant and ethical as business needs evolve.

The PMBOK and Agile Practice Guide both advocate for a balanced approach to measurement, highlighting the importance of systems thinking, optimizing for the whole, not just the parts.

The Bottom Line

The ethical debate over measuring output versus value is not a theoretical exercise. It has real consequences for team behaviour, customer satisfaction, and organizational integrity. Rewarding teams solely for higher output can unintentionally incentivize waste, undermine Agile principles, and erode trust. Lean Six Sigma metrics are powerful when applied judiciously, but organizations must ensure their measurement systems are ethically aligned to deliver meaningful value to customers.

Questions for reflection:

1. How does your organization balance output metrics with value-based outcomes in Agile projects?
2. Have you ever seen (or experienced) negative behaviours arising from an overemphasis on productivity metrics?
3. What ethical guidelines should leaders use when designing measurement systems for Agile teams?

Introduction

Challenges

The Allure of Metrics

Masking Unresolved Risks

The Consequences of Performance Theatre

Organizational Pressures

Recommendations

Foster a Culture of Psychological Safety

Redefine Success Metrics

Make Risks Visible and Actionable

Encourage Reflective Practices

Leadership Accountability

The Bottom Line

Questions for the Reader

1. Have you ever witnessed or participated in performance theatre in your Agile team? What were the warning signs?
2. How does your team currently handle unresolved risks, and what could be improved?
3. What changes would you recommend to encourage greater accountability and transparency in your organisation?

Introduction

Agile communities are no strangers to conversations about team dynamics, culture, and ethics. Tuckman’s ‘ladder” of group development, published in 1965, is a core topic in Agile training courses.  As Tuckman indicated, all these phases are necessary and inevitable in order for a team to grow, face up to challenges, tackle problems, find solutions, plan work, and deliver results. These inevitable phases are critical to team growth and development. An Agile enterprise must create the support culture and processes for teams and individuals, including one of the most important prerequisites: psychological safety.  Psychological safety—the shared belief that the team is safe for interpersonal risk-taking—has become a cornerstone of high-performing teams. When combined with robust team ethics, psychological safety forms the backbone of trust, transparency, and innovation within Agile environments.

Documents such as the PMI Code of Ethics and Professional Conduct, the Agile Practice Guide, ISO 31000, and the PMBOK all underscore the importance of ethical conduct, respect, and open communication. These principles not only shape how teams interact but also influence the ability to deliver value in fast-paced, complex projects.

This blog post explores the relationship between psychological safety and team ethics, the challenges faced by Agile teams, and recommendations to overcome them.

Challenges

The Myth of Respectful Treatment

Respectful treatment is often touted as a given in Agile teams. However, the reality is that even well-intentioned teams can slip into patterns of microaggressions, exclusion, or unintentional disrespect. The PMI Code of Ethics places respect at its core, defining it as “our duty to show a high regard for ourselves, others, and the resources entrusted to us.” Yet, Agile practitioners report that respect can be compromised under high pressure, tight deadlines, or when dealing with strong personalities.

Blame Cultures and Fear of Failure

A culture of blame is the antithesis of psychological safety. The Agile Practice Guide points out that when mistakes are met with finger-pointing rather than learning, teams become risk-averse and innovation stalls. In organizations where blame is common, team members often conceal problems, avoid experimenting, and withhold valuable feedback. This undermines both project outcomes and individual well-being.

Speaking Up: Risk and Retaliation

ISO 31000 highlights the importance of risk communication, yet many Agile teams struggle to speak up about risks, issues, or unethical behaviours. The fear of retaliation, ridicule, or being labelled a troublemaker can silence even the most conscientious team members. This silence can allow ethical breaches, technical debt, or project risks to fester until they become critical.

Handling Toxic Stakeholders

Dealing with toxic stakeholders—whether they are clients, managers, or team members—presents a significant challenge. On Agile forums there are many posts about the detrimental impact of toxic behaviours, such as manipulation, bullying, or undermining team decisions. Agile teams must navigate these situations delicately, balancing the need for stakeholder engagement with the imperative to protect team well-being and uphold ethical standards.

Recommendations

Embed Ethical Principles in Team Norms

Draw on the PMI Code of Ethics and the Agile Practice Guide to establish explicit team norms around respect, responsibility, fairness, and honesty. Make these principles visible—post them in the team area, reference them in retrospectives, and revisit them regularly.

Foster Psychological Safety Deliberately

Almost 3 decades ago, when Extreme Programming was developed, Ron Jeffries advocated for creating environments where it is safe to ask questions, challenge assumptions, and admit mistakes. Leaders, including Scrum Masters, can model vulnerability by admitting their own errors and inviting feedback. Regular check-ins, anonymous feedback channels, and psychological safety assessments can help track progress and uncover hidden issues.

Replace Blame with Curiosity

Use blameless retrospectives, post-mortems, and root cause analyses to transform failures into learning opportunities. Instead of asking “Who is at fault?” ask “What can we learn?” This shift in language and mindset is supported by PMBOK and ISO 31000, which encourage continuous improvement and knowledge sharing.

Empower Speaking Up—Safely

Create clear, confidential pathways for reporting concerns about risks or unethical behaviour. Train team members in assertive communication and active listening. Hold regular risk workshops, as recommended by ISO 31000, to normalize open discussion about uncertainties and potential threats.

Address Toxic Stakeholders Proactively

Equip the team with conflict resolution skills and clear escalation processes. Engage leaders and HR when necessary to address toxic behaviours. Be transparent about boundaries and team values, making it clear that toxic conduct will not be tolerated, in line with the PMI’s fairness and respect principles.

Align with Global Standards

Leverage frameworks like ISO 31000 (Risk Management), the PMBOK Guide, and the Agile Practice Guide to ensure that team practices align with international best practices for ethics, risk, and stakeholder management.

The Bottom Line

High-performing Agile teams do not emerge by accident. They are intentionally built on a foundation of psychological safety and strong ethical values. Respectful treatment, learning from failure, open communication about risks, and effective handling of toxic stakeholders are not just “nice-to-haves”—they are essential components of sustainable project success.

By embedding the PMI’s ethical principles and utilizing proven standards such as ISO 31000, organizations create environments where teams can thrive, innovate, and deliver lasting value.

Questions for Readers

1. How does your organisation and the senior management actively foster psychological safety and ethical behaviour?
2. What strategies have worked (or failed) when addressing blame cultures or toxic stakeholders in your experience?
3. In what ways can Agile teams better align their practices with established ethical and risk management standards?

Introduction

Like Agile, Artificial Intelligence (AI) is no longer seen as a concept limited to software development. Artificial Intelligence has become a defining force in product innovation across industries. As Agile delivery cycles accelerate the introduction of AI-powered features, organizations face a critical question: Can Agile teams govern AI risks effectively within short delivery cycles? The challenges are complex, touching on bias, explainability, accountability, and human oversight. As this debate takes centre stage in many professional forums, references such as the PMI Code of Ethics and Professional Conduct, the Agile Practice Guide, ISO 31000, and the PMBOK provide valuable perspectives on delivering responsible AI products.

This blog post aims to spark thoughtful discussion and practical action on one of today’s most critical technology challenges.

Challenges

Bias in Machine Learning Models

AI models are only as fair as the data and assumptions they are built on. Biases—historical, societal, or technical—can be inadvertently embedded in models, leading to unfair or discriminatory outcomes. Ensuring fairness is not a one-off task; it requires continuous attention to data quality, model design, and real-world impacts. However, Agile sprints prioritize delivering working increments rapidly, often leaving insufficient time for comprehensive bias audits or fairness tests. Adaptive systems require continuous learning and adjustment, but Agile teams may lack the bandwidth for deep dives into bias within each sprint.

Explainability Versus Innovation

AI’s power often stems from complex, opaque algorithms—especially deep learning models. While these models can drive rapid innovation, they are notoriously difficult to explain. The Agile Practice Guide encourages iteration and experimentation, but when stakeholders demand clarity on how AI makes decisions, Agile teams can struggle to balance transparency with speed. This tension is especially acute in regulated industries, where explainability is not just desirable but often mandatory. The PMI Code of Ethics underscores responsibility and honesty, making it ethically necessary to provide understandable explanations for AI-driven outcomes.

Accountability for AI Decisions

When an AI system makes a decision—such as denying a loan or flagging fraudulent activity—who is accountable? Agile frameworks support empowered, cross-functional teams, but the distributed nature of responsibility can blur lines of ownership. ISO 31000 and PMBOK emphasize the importance of risk management and clear accountability, yet Agile teams may focus on delivering features rather than establishing structures for post-release monitoring or escalation. The rush to “get to done” can sideline the deeper question of who answers for AI’s impact in the wild.

Human Oversight Requirements

The need for human-in-the-loop processes is well-documented, particularly for high-stakes AI applications. However, Agile’s emphasis on automation and continuous delivery may inadvertently reduce opportunities for meaningful human review. Everyone agrees on the importance of oversight to catch errors, biases, or unintended consequences before they affect users. Yet, as teams deliver features within a sprint, the time for thorough, cross-disciplinary review is often squeezed, creating risks that may not emerge until after deployment.

Recommendations for Agile Teams

Integrate Risk Management Early and Often:

Reference ISO 31000 and PMBOK to embed risk assessments into backlog refinement and sprint planning. Make risk mitigation a shared responsibility across roles.

Allocate Dedicated Time for Ethical Evaluation:

Ensure each sprint includes scheduled activities for reviewing fairness, bias, and explainability. Use checklists inspired by the PMI Code of Ethics to guide discussions.

Foster Multidisciplinary Collaboration:

Involve ethicists, domain experts, and impacted stakeholders in sprint reviews and retrospectives. Their perspectives can surface risks overlooked by developers alone.

Document Decision-Making Processes:

Maintain transparent records of design choices, especially around model selection, data sources, and trade-offs between explainability and performance. This supports accountability and future audits.

Implement Continuous Monitoring:

Don’t stop at deployment. Set up post-release reviews and monitoring to catch biases, errors, or harmful impacts that emerge in production.

Empower Human Oversight:

Build mechanisms for humans to intervene or override AI decisions, especially in critical contexts. Ensure these processes are well-communicated and accessible.

The Bottom Line

AI’s promise, opportunities, and risks are magnified by the speed of Agile delivery. While Agile teams are well-positioned to respond to change and incorporate feedback, governing AI risks demands intentional, systemic approaches that extend beyond the sprint. By weaving ethical considerations into every stage, teams can deliver AI-powered products responsibly, even under tight timelines. The challenge is ongoing, but the path forward is clear: ethics and agility must go hand in hand.

Questions for reflection:

1. How does your team address ethical risks in AI projects within short delivery cycles?
2. Have you encountered situations where speed conflicted with fairness or transparency? How did you resolve the tension?
3. What additional practices or frameworks would you recommend for Agile teams delivering AI features?

Introduction

In the last couple of decades, Agile frameworks have changed the way organisations deliver products and services, bringing a new perspective to the lean focus on maximizing customer value. In theory, this focus ensures that teams build what matters most to those who pay for, use, or depend on a product. But as technology pervades more aspects of daily life, a pressing ethical question emerges: Should teams optimize only for customer value? When the needs and desires of customers conflict with the well-being of employees, communities, or society at large, how should teams respond? And who gets to decide what constitutes ‘value’?

The Ethical Challenges

Defining Value: More Than Just the Customer

Frameworks like Scrum emphasize delivering customer value above all else. Paraphrasing Albert Einstein, as project managers, we should focus not on achieving financial success but on delivering value to society. “Be creative, but make sure that what you create is not a curse for mankind”. Customer value is not always synonymous with social good. In some cases, optimizing for one group can actively harm another.

When Value Delivery Harms the Public Good

Several real-world examples illustrate how this tension plays out:

• Surveillance Features: A government client requests capabilities for tracking citizens in the name of security. While this delivers customer value, it raises serious privacy and human rights concerns.
• Engagement and Addictive Design: Product owners ask for features that increase user engagement—sometimes by encouraging addictive behaviours. While this boosts KPIs, it may harm users’ mental health.
• Cost-Saving Initiatives: Organizations may request automation or layoffs to save costs, delivering value to the business but negatively impacting employee livelihoods.

Who Decides What Value Is?

The PMI Code of Ethics and Professional Conduct urges practitioners to balance responsibility to clients with responsibility to the public. Agile frameworks often leave the definition of value to the “customer” or product owner, but this approach can ignore wider consequences. Agility must go together with adaptability and ethical awareness, especially in complex, interconnected environments.

Ethical Considerations vs. Customer Requirements

Should ethical considerations outrank customer requirements? According to the PMBOK Guide and Risk Management standard ISO 31000, risks to stakeholders—including the public—must be managed alongside project objectives. The Agile Practice Guide recommends that teams “consider the impact of decisions on all affected parties,” not just end users or paying customers.

Recommendations

Broaden the Definition of Value:

• Teams should actively seek input from stakeholders beyond the customer: employees, users, regulators, and the public.
• Use stakeholder mapping to identify who is affected by product decisions.

Build Ethics into Agile Processes:

• Incorporate ethical checkpoints into backlog refinement, sprint reviews, and retrospectives.
• Use models like PMI’s Code of Ethics as a framework for decision-making.

Empower Team Members to Raise Concerns:

• Create a culture where team members can voice ethical concerns without fear of reprisal.
• Leverage the wisdom of diverse team members to identify risks that may not be obvious.

Make Ethical Trade-offs Explicit:

• When faced with conflicting values, document the trade-offs and rationale behind decisions.
• Use tools such as impact mapping and risk registers to make these trade-offs visible.

Engage in Ongoing Learning:

• Stay informed about evolving norms and regulations (e.g., data privacy laws, labour standards).
• Learn from case studies on professional forums, research sites and guidance from industry leaders.

The Bottom Line

Delivering customer value is a core tenet of Agile and project management frameworks, but it must not be pursued in isolation. Practitioners are increasingly called to weigh the interests of customers against the broader public good. As the PMI Code of Ethics emphasizes, our duty is to act responsibly, respect the dignity of those affected, and ensure our actions do not cause harm—even when it means saying “no” to a customer requirement. Ultimately, the most sustainable value is that which benefits everyone: the customer, the team, and society at large.

Questions for reflection

1. How should a team balance customer value and public good when they come into conflict?
2. Who should define what counts as “value” in your projects?
3. Can you recall a situation where delivering customer value had unintended negative consequences? What would you do differently?