The Agile Enterprise

Introduction

One of the most persistent misconceptions about Agile methodologies is that "Agile means no documentation." This misunderstanding can have serious ethical and practical consequences for teams, organizations, and stakeholders. Agile values "working software over comprehensive documentation," as stated in the Manifesto for Agile Software Development, but this does not mean documentation is absent or unimportant. Moreover, the Manifesto was written for software development, and although most of the values and principles can be extrapolated for product development in general, the authors may not have considered product development in highly regulated environments, such as medical devices. Rather, Agile encourages documentation that delivers true value, supports collaboration, and enables responsible professional conduct. This post explores the ethical dimensions of documentation practices in Agile contexts.

Challenges

Misinterpretation of Agile Values

The Manifesto’s principle of valuing working software over comprehensive documentation is often misinterpreted as a rejection of documentation. This misconception can lead to ethical lapses, such as inadequate record-keeping, lack of transparency, and poor knowledge transfer, all of which violate the PMI Code of Ethics’ mandates for responsibility and honesty.

Impact on Stakeholder Trust

Without sufficient documentation, stakeholders—including clients, users, auditors, and future team members—may be left in the dark about key decisions, requirements, and changes. This erodes trust, impedes compliance, and undermines accountability.

Undermining Professional Responsibility

The PMI Code of Ethics emphasizes the duty to provide accurate and timely information. Documentation is essential for traceability, maintainability, and supporting organizational learning. Ignoring documentation responsibilities can result in non-compliance, operational inefficiencies, and reputational harm.

The Challenge of "Just Enough" Documentation

Agile teams are tasked with producing "just enough" documentation to support the needs of the project and organization. Determining the right amount is challenging and requires ethical judgment. Too little documentation risks knowledge loss and non-compliance; too much documentation wastes effort and contradicts the Agile principle of maximizing value.

Recommendations

Align Documentation with Value Delivery

Agile teams should create documentation that provides clear value, such as:

• Requirements
• Architecture decisions
• User guides
• Compliance artifacts
• Operational procedures

This approach ensures documentation serves a purpose and supports the team’s ability to deliver quality software.

Follow Ethical and Professional Standards

The PMI Code of Ethics, risk management practices, as well as Scrum values, call for transparency, accountability, and risk management. Teams should:

• Record decisions made during development
• Document risks and mitigations
• Maintain audit trails for compliance

Foster a Culture of Continuous Improvement

Agile recommends regular retrospectives to assess not only code and process, but also documentation practices. Teams should continuously ask: Is our documentation helping us achieve our goals? Are we meeting our ethical obligations to current and future stakeholders?

Leverage Tools and Automation

Modern Agile teams use tools to automate the creation and maintenance of documentation, reducing overhead while ensuring accuracy. This enables "living documentation" that evolves with the product.

Educate Teams and Stakeholders

Combat the "no documentation" myth through training and clear communication. Reference authoritative sources, such as the Agile Practice Guide and PMBOK, to clarify the real intent behind Agile documentation values.

The Bottom Line

Ethics in Agile are not just about following processes—they are about fulfilling responsibilities to people, organizations, and society. Good Agile teams document what matters, when it matters, for the benefit of all stakeholders. This is not only a best practice, but a professional and ethical imperative. As the PMI Code of Ethics states: "We make decisions and take actions based on the best interests of society, public safety, and the environment."

In summary, Agile does not mean abandoning documentation; it means embracing responsible, value-driven documentation that supports working software, transparency, and stakeholder trust.

Question for Readers:  Have you ever experienced negative consequences from too little or too much documentation?

Although there is no Agile Coaching Code of Ethics, like PMI’s Code of Ethics and Professional Conduct, Agile coaching ethics relies on guidelines adapted from broader professional bodies and community-led initiatives. Some examples of codes and frameworks used by Agile coaches include:

The Agile Coaching Code of Ethical Conduct

(Developed by an open community initiative supported by Agile Alliance and Scrum.org)

This is the primary dedicated code of ethics specifically created for the Agile coaching discipline. It covers 9 core commitments:

1. Protecting Confidentiality, Intellectual Property, and Information Security: Protecting client data and properly attributing ideas.
2. Acting Within My Ability: Remaining transparent about qualifications and stepping aside when client needs exceed personal expertise.
3. Introspection and Continuing Professional Development: Engaging with mentors/peers and pursuing continuous learning.
4. Navigating Conflicts of Interest: Proactively declaring potential conflicts and ensuring decisions benefit the client over personal gain.
5. Ensuring Value in the Relationship: Preventing client dependency and continuously verifying that the coaching engagement adds tangible value.
6. Upholding Social Responsibility, Diversity, and Inclusion: Actively discouraging discrimination and elevating diverse perspectives.
7. Agreeing on Boundaries: Establishing agreed-upon scope without imposing personal preferences or violating Agile principles.
8. Managing Differences in Status and Power: Refraining from misusing influence, authority, or rank.
9. Responsibility to the Profession: Uplifting professional standards and addressing unethical behaviour in the community.

Unlike PMI’s Code and other codes developed by professional bodies, such has Mechanical Engineering, Construction, Electrical Engineering or Medical Association, this code is not structured on certain values, like Responsibility, Respect, Fairness and Honesty, nor has specific mandatory and aspirational standards.

Scrum Alliance Code of Ethics

(Mandated for Scrum Alliance certified practitioners, including Certified Agile Coaches / CEC / CTC)

The Scrum Alliance Code of Ethics governs professional behaviour across five main areas:

• Representation: Truthfulness regarding credentials, background, and capabilities.
• Professionalism: Maintaining courtesy, respecting others, avoiding harassment/discrimination, and upholding hate speech policies.
• Professional Responsibility: Managing conflicts of interest, taking accountability for mistakes, and avoiding safety risks.
• Compliance with Scrum Alliance Policies: Respecting intellectual property and mark usage guidelines.
• Pledge of Ethics & Scrum Values: Aligning behaviour with the 5 Scrum Values (Focus, Courage, Openness, Respect, Commitment).

More ethics-oriented around Scrum values, the code does not have specific mandatory and aspirational standards. Like the Agile Alliance, the Scrum Alliance doesn’t supplement the Code with a framework for investigating and resolving ethics complaints related to violations of the code of ethics there is no body that can order disciplinary or remedial actions.

Complementary & Adjacent Codes

• International Coaching Federation (ICF) Code of Ethics, structured into 4 pillars:

Responsibility to Clients: Confidentiality, clear contracts, avoiding power imbalances, and managing client conflicts.

Responsibility to Practice and Performance: Maintaining personal boundaries, ongoing self-development, and ethical awareness.

Responsibility to Professionalism: Accurate representation of coaching qualifications and respecting intellectual property.

Responsibility to Society: Promoting equality, safety, and social well-being.

• International Association of Facilitators (IAF) Code of Ethics: Followed by Agile coaches emphasizing group facilitation stance (focusing on neutrality, inclusive participation, and group autonomy).
• European Mentoring and Coaching Council (EMCC) Global Code of Ethics: Common among UK/European Agile coaches, focusing on professional competence, context awareness, and safety.

Scenarios:

Following are some scenarios to demonstrate how PMI’s Code of Ethics ethical values can be used by Agile Coaches;

Scenario 1: Handling "Off-the-Record" Leadership Information

• Ethical Principle - Responsibility: Protecting Confidentiality & Information Security
• The Situation: During a 1-on-1, a director confides to you that a major restructuring and layoff phase is coming in two months. Later that week, a team member asks you directly, "I heard rumours about layoffs—is our team safe? Should I be updating my resume?"
• In Practice:
• Unethical Approach: Confirming the rumour off-the-record or blabbing to build trust with team members.
• Ethical Approach: Protect confidentiality while maintaining trust. Explain that you cannot comment on organizational rumours but offer space to explore their immediate concerns and direct them to HR or official leadership channels for official updates.

Scenario 2: Knowing When to Say "I'm Out of My Depth"

• Ethical Principle – Honesty: Acting Within My Ability
• The Situation: An executive asks you to lead an enterprise-wide scaling transformation, including redesigning compensation structures and org design. You have strong team-level coaching experience, but zero experience with executive change management or compensation models.
• In Practice:
• Unethical Approach: Accepting the contract or assignment anyway for the prestige, higher pay, or career progression, hoping to "fake it till you make it."
• Ethical Approach: Be transparent about your current scope of expertise. Offer to help co-coach alongside an enterprise specialist or advise the leadership team to bring in an experienced enterprise transformation consultant.

Scenario 3: Firing Yourself When Value Drops

• Ethical Principles - Honesty and Responsibility:Ensuring Value in the Relationship / Preventing Dependency
• The Situation: You have coached a department for 18 months. The teams are high-performing, self-organizing, and successfully resolving their own systemic blockers. However, management wants to keep you on a retainer indefinitely to "keep things smooth."
• In Practice:
• Unethical Approach: Staying on board, creating artificial problems to solve, or making yourself indispensable so the contract keeps rolling.
• Ethical Approach: Point out that the team has achieved self-sustainability. Recommend transitioning out of the daily coaching role, moving to an ad-hoc advisory check-in model, or wrapping up the engagement.

Scenario 4: The Boss Demands "Secret Performance Data"

• Ethical Principles – Respect and Fairness: Managing Differences in Status and Power / Protecting Confidentiality
• The Situation: A VP asks you, "I need you to tell me who the low performers are on Team X so I can decide on year-end bonuses. You observe their retrospectives every week."
• In Practice:
• Unethical Approach: Sharing individual observation notes or evaluating team members' personal contributions based on retrospective participation.
• Ethical Approach: Explain that retrospective observations and coaching interactions are safe, confidential spaces required for psychological safety. Offer instead to help leadership establish transparent, objective metrics for performance evaluating outside the coaching boundary.

Scenario 5: Managing Tool Vendor Kickbacks

• Ethical Principle – Responsibility and Honesty:Navigating Conflicts of Interest
• The Situation: An Agile tooling vendor offers you an affiliate commission or a free ticket to an international conference if you convince your current client company to adopt their enterprise software package.
• In Practice:
• Unethical Approach: Recommending the tool as the "best solution for the organization" without disclosing your financial incentive or alternative options.
• Ethical Approach: Disclose the potential conflict immediately to the client decision-makers. Remain objective by providing an unbiased evaluation of multiple tool options or step back from the selection committee altogether.

Scenario 6: Steering Clear of Dogma

• Ethical Principles – Responsibility, Honesty and Respect: Agreeing on Boundaries & Respecting Client Autonomy
• The Situation: You are a strict advocate for Scrum. A software engineering team at your client company is dealing with unpredictable operational incidents and wants to adopt Kanban.
• In Practice:
• Unethical Approach: Refusing to support them or insisting they stay with 2-week Scrum Sprints because "Kanban isn't really Agile."
• Ethical Approach: Put the client team's contextual needs over personal framework preferences. Help them design a flow-based Kanban system tailored to their operational reality, ensuring alignment with overall Agile principles.

Introduction

The phrase “Agile is a process” is a widespread misconception that has undermined countless organisational transformations. Starting with “We are implementing an Agile Methodology”, regardless of which Agile framework is referred to, is a mistake that can lead to failed Agile transformation. At its core, Agile is not a set of rigid steps but a mindset rooted in values such as learning quickly, delivering value early to customers, adapting to change, collaborating closely, and continuously improving. Misinterpreting Agile as merely a process, new titles or a set of ceremonies—like stand-ups, sprints, and retrospectives—can erode its ethical foundation and lead to failed transformations. This blog post analyses the ethical implications of this misconception.

Challenges

When organisations equate Agile with a process, they risk violating several ethical principles central to professional conduct. The PMI Code of Ethics emphasises responsibility, respect, fairness, and honesty—values that are compromised when Agile is reduced to a checklist of activities. For example, implementing ceremonies without embracing the underlying Agile mindset can foster environments where employees go through the motions, disengaged from genuine collaboration and continuous improvement. Ron Jeffries, one of the original signatories of the Agile Manifesto, has repeatedly stressed that the “heart of Agile” is about people, not processes and tools.

Failed Agile transformations often stem from superficial adoptions. By focusing solely on rituals, organisations may inadvertently create a culture of compliance rather than one of empowerment. This approach conflicts with the principle of respect, as outlined by PMI’s Code of Ethics, by treating team members as cogs in a machine rather than autonomous professionals capable of self-organisation and innovation.

Moreover, practitioners highlight the importance of adaptability and learning—core tenets of Agile. When these are ignored, organisations become less resilient and more likely to falter in the face of change. Risk management standards and frameworks, and all Agile frameworks advocate for adaptive approaches and stakeholder engagement, principles that are compromised when Agile is viewed as a static process.

Recommendations

To ethically implement Agile, organisations must shift their perspective from process to mindset. Here are several recommendations:

Cultivate an Agile Mindset:

• Emphasise values such as openness, courage, and respect. Encourage teams to question, learn, and adapt.
• Reference Ron Jeffries’ advice: Focus on communication, feedback, simplicity, and courage.

Prioritise People Over Process:

• Inspire trust by empowering teams to make decisions. The PMI Code of Ethics calls for treating individuals with dignity and fairness.
• Foster environments where psychological safety is paramount, supporting the Agile Practice Guide’s emphasis on collaboration.

Embrace Continuous Improvement:

1. Use retrospectives and feedback loops not as obligations, but as genuine opportunities for learning and adaptation.
2. Integrate principles from risk management standards and traditional project delivery approaches to manage risk and change proactively.
3. Align with Global Standards:
4. Use frameworks like ISO 31000 and PMBOK® to guide ethical decision-making and stakeholder management.
5. Ensure Agile practices are tailored to context rather than rigidly applied.
6. Educate and Coach:
7. Invest in Agile coaching that emphasises mindset and values, not just mechanics.
8. Leverage resources from PMI, Agile Alliance, and LinkedIn forums to support ongoing learning.

The Bottom Line

Viewing Agile as a process rather than a mindset is not simply a technical mistake—it is an ethical lapse. By prioritising ceremonies over values, organisations risk undermining trust, stifling innovation, and sacrificing long-term value for short-term compliance. Ethical Agile adoption demands a holistic approach grounded in professional values, global standards, and a relentless commitment to learning and adaptation. Only then can organizations realize the true promise of Agile: delivering value early to customers, responding to change, and fostering environments where collaboration and improvement are the norm.

Question for Readers:  What steps can leaders take to ensure Agile is implemented ethically and authentically in their organisations?

Introduction

Agile methodologies, inspired by the Manifesto for Agile Software Development, have revolutionized project management, strengthening adaptive planning and iterative delivery. One of the most recognized metrics in Agile is “velocity,” the sum of story points completed in a sprint. However, a persistent misconception lingers that velocity measures team productivity. Velocity, introduced by the Extreme Programming framework for software development, is a planning tool designed to help teams forecast future work—not a performance metric for comparing teams or individuals. Misusing velocity this way has significant ethical implications, leading to unfair evaluations, demotivation, and even manipulation of the very metric it seeks to leverage. This post explores the ethical dimensions of this misconception and provides actionable recommendations.

Challenges

The Relativity of Story Points

Story points are inherently subjective. They reflect a team’s unique understanding of effort, complexity, and risk. Context matters: what is a “5-point” story for one team may be a “2-point” story for another. The Agile Practice Guide and Ron Jeffries, the person credited with inventing story points, both highlight that teams develop their own baselines and estimation habits. Using velocity to compare teams disregards these differences, leading to unfair assessments.

Ethical Dilemmas in Misuse

The PMI Code of Ethics urges practitioners to act with honesty, responsibility, and respect. When organizations treat velocity as a productivity scorecard, they risk violating these principles. Teams might inflate story points or focus on quantity over quality to meet perceived performance expectations. This undermines transparency, distorts reporting, and creates a culture of fear or cynicism. Risk management practices include identifying behavioural risks—misapplied metrics are a prime example.

Value Delivery vs. Story Point Completion

PMBOK and Agile Practice Guide stress that real value lies in meeting customer needs, not just completing tasks. A team could have a lower velocity but consistently deliver features that delight users or resolve critical business challenges. Conversely, a high-velocity team might churn out less impactful work. Using velocity as a direct proxy for value delivery ignores the true purpose of Agile: maximizing stakeholder value.

Contextual Variability

External factors—team experience, domain knowledge, technical debt, stakeholder availability—affect how teams estimate and deliver work. Context and team maturity significantly shape estimation accuracy and throughput. Comparing velocity across teams without accounting for these factors leads to misleading conclusions and can erode trust in leadership.

Recommendations

Use Velocity for Planning, Not Judgement

Adopt velocity as it was intended: to help a team predict how much work they can take on in future sprints. Avoid using it as a key performance indicator for individuals or to compare teams. Encourage teams to focus on delivering value, not just increasing their story point totals.

Foster an Ethical Measurement Culture

The PMI Code of Ethics calls for fairness, openness, and respect. Leaders should educate stakeholders about the true purpose of velocity and champion its ethical use. Transparency is critical—explain how estimates are derived and why comparisons are invalid. Recognize and reward behaviours that support collaboration, learning, and value delivery.

Supplement with Qualitative Feedback

Combine quantitative metrics with qualitative insights: customer satisfaction, team morale, ability to respond to change, and delivery of business value. The Agile Practice Guide advocates a balanced view of performance. Use retrospectives to capture lessons learned and context behind the numbers.

Emphasize Continuous Improvement

Encourage teams to use velocity to reflect on their own processes and seek improvement—not to compete with or be judged against others. Support experimentation and learning. Make it safe for teams to be honest about challenges and impediments.

Tailor Metrics to Context

Follow PMBOK and Agile Practice Guide recommendations by adapting measurement frameworks to organizational needs and contexts. Avoid one-size-fits-all metrics. Instead, co-create success criteria with teams and stakeholders.

The Bottom Line

Treating velocity as a productivity metric is not only a technical error but also an ethical misstep. It undermines Agile values, creates perverse incentives, and risks team well-being. By following the spirit of the PMI Code of Ethics, insights from Agile pioneers like Ron Jeffries, and industry best practices, organizations can foster healthier, more effective teams. Velocity is a tool for planning—not a yardstick for productivity.

Question for Readers: How can leaders better model ethical use of Agile metrics in their teams?

Introduction

Agile changed the way products and services are developed, aligning processes with the fast and complex changes in the business environment. Nowadays, in the high-velocity world of tech innovation, the “fail fast” mantra and the Minimum Viable Product (MVP) concept have become cornerstones of Agile product development. Teams are encouraged to release early, learn rapidly, and iterate based on real-world feedback. While these approaches can accelerate learning and reduce wasted effort, an emerging ethical dilemma shadows their popularity: What happens when “failing fast” means delivering an unfinished or untested product, exposing real users to privacy violations, security flaws, or even physical harm? Is there a risk that the watermelon effect (Green outside, red inside), used to describe unethical project reporting, can occur in Agile product development? At what point does the drive for rapid feedback cross ethical boundaries, risking harm to users or the public?

This blog post explores the ethical conflicts inherent in overusing MVP and “fail fast” strategies, examines the challenges and proposes recommendations for ethically navigating the tension between speed and responsibility.

Challenges

The Allure—and Danger—of “Fail Fast”

The “fail fast” mindset encourages experimentation and learning by rapidly deploying new features or products. When aligned with Agile values, this can be a powerful driver of innovation. However, overreliance on MVPs and under-tested releases can externalise risk—transferring the burden of failures from organisations to unwitting users. This externalisation is especially dangerous when it comes to privacy, security, and safety.

Complex systems are increasingly interconnected, and the speed of change can outpace the ability to foresee consequences. Releasing features with minimal testing may expose users to data breaches, non-compliance with regulations like GDPR, or even physical harm in cases involving IoT or health tech devices.

Ethical Responsibilities and Professional Codes

The PMI Code of Ethics and Professional Conduct emphasises responsibility, respect, fairness, and honesty. It requires practitioners to make decisions in the best interests of society, public safety, and the environment. Similarly, Risk Management Standards highlight the importance of integrating risk management into organisational processes, rather than relegating it to an afterthought.

Yet, in the race to outpace competitors, teams may deprioritise security, privacy, and compliance in favour of rapid deployment. This creates an ethical conflict: Should organisations prioritise quick market feedback, or their obligation to protect users and comply with legal standards?

Ron Jeffries, co-creator of Extreme Programming, cautions that “working software” is not enough—software must also be safe and reliable. The Agile Practice Guide warns against anti-patterns where teams treat user trust as expendable in pursuit of learning.

Regulatory and Societal Pressures

With the rise of privacy regulations such as GDPR and increasing scrutiny from both regulators and the public, companies are under pressure to demonstrate that they take user safety and privacy seriously. Failing to do so can result in legal penalties, reputational harm, and a loss of trust that is difficult to regain.

Recommendations

1. Strict Definition of Done (DoD)

Adopt a non-negotiable Definition of Done that includes comprehensive security checks, privacy assessments, regulatory compliance, and rigorous testing. As recommended in the Agile Practice Guide and PMBOK®, these criteria should be built into every iteration, not left for later stages. Definition of done should be part of the product Backlog item creation and confirmed with the Product Owner in the Sprint planning. This practice ensures that ethical and legal obligations are met before exposing users to new features.

2. Explicit Risk Backlogs

Treat risk mitigation, privacy concerns, and technical debt as first-class citizens in your backlog. Modern risk management thought holds that risks should be transparent and actively managed—not hidden or deferred. By maintaining a visible risk backlog, teams can prioritise and address potential harms alongside business features. Risks and issues must be part of the Product Backlog as separate item types and must be linked with tasks to reduce the impact of issues and negative risks or take advantage of positive risks.

3. Servant Leadership & Protection

Leaders must adopt a servant leadership model actively shielding teams from pressures to cut corners for short-term wins. Leaders should foster a culture where ethical risk disclosure is valued over meeting aggressive KPIs and where speaking up about potential harms is encouraged and rewarded.

4. Continuous Ethical Training and Review

Integrate ongoing ethics training, drawing from the PMI Code of Ethics, into team routines. Encourage regular review of ethical dilemmas, and provide forums for discussing the trade-offs between speed and responsibility.

5. Stakeholder Engagement and Transparency

Engage end-users and stakeholders early and often—not just as test subjects, but as partners in risk identification and mitigation. Transparency about what is being tested, potential risks, and the steps being taken to protect users builds trust and helps organisations identify blind spots.

The Bottom Line

The “fail fast” culture and MVP approach, when applied without ethical guardrails, can shift unacceptable risks onto users and society at large. As professionals guided by established codes of ethics and global standards, it is imperative to balance the drive for rapid learning with the obligation to protect user privacy, safety, and compliance.

By embedding robust definitions of done, explicit risk management, servant leadership, and continuous ethical reflection into Agile practices, communities can innovate responsibly—delivering value without sacrificing trust. Ultimately, the most sustainable path to innovation is one that honours both speed and stewardship.

Question for Reflection: How can your organization ensure that risk management and ethical considerations are not sacrificed for speed?