Project Management

Using the Agile Manifesto (Not Just ‘Manifesto for Agile Software Development’) and Lean Kanban (Not Just ‘Kanban’): An Ethical Reflection Through Ethical Values

From the The Agile Enterprise Blog
by
"The Agile Enterprise" explores Agility at the Enterprise level, examining how Agile principles can be implemented throughout the organization beyond IT. The blog is inspired by the concept of an Agile Enterprise, introduced by the Agile Manufacturing Forum (1991) and the Manifesto for Agile Software Development (2001). Agility is examined from a Project Management perspective with a focus on areas not covered by frameworks that emerged from the work of small software development teams, such as Risk Management, Ethics, Organisational Change Management and Financial Management.
General | History | Metrics | show all posts

About this Blog

RSS

Recent Posts

Concealing Technical Debt for Short-Term Speed: An Ethical Examination

Transparency, Truthful Reporting, and Risk Visibility: The Ethics of Agile Delivery

Navigating the New Agile Landscape: Fairness, Bias, and Ethical Technology Use. An Ethical Reflection

Accountability and Responsible Decision-Making in Agile Projects/n Ethical Reflection.

Transparency, Accountability, and Trust in Agile Decision-Making: The Ethical Imperative

Categories

Agile, Artificial Intelligence, Benefits Realization, Change Management, Communications Management, Complexity, Consulting, Decision Making, Disciplined Agile, Diversity, Earned Value Management, Estimating, Ethics, General, Governance, History, Innovation, Knowledge Management, Leadership, Lessons Learned, Metrics, Organizational Culture, Product Management, Risk Management, Scope Management, Scrum, Social Impact, Stakeholder Management, Teams, Testing/Test Management, Using PMI Standards

Date

linkedin twitter facebook Request to reuse this  


Introduction

In the 21st-century business environment of continuous and disruptive change, project delivery, including project management, can’t escape from the buzzwords, and we can see Agile frameworks and established practices often travelling far from their origins. Two of the most influential concepts—Agile and Kanban—have been widely adopted, adapted, and, at times, misunderstood outside their intended contexts. This blog post explores the ethical implications and risks of using the term “Agile Manifesto” as a generic label for Agility and avoiding recognising Kanban as an over 50 years old Lean Six Sigma practice, rebranded the knowledge work implementation as “Lean Kanban” without acknowledging their roots. We’ll reflect on these issues through the lens of PMI’s Code of Ethics and Professional Conduct, the Agile Practice Guide (2026), the Agile Manufacturing Forum (1991), Manifesto for Enterprise Agility (2026), and the original Manifesto for Agile Software Development (2001) itself.

Challenges

Misrepresentation of Origins and Intent

The Manifesto for Agile Software Development was crafted by software developers for software development. Its values and principles are rooted in the challenges and culture of that specific discipline. When organizations refer to “the Agile Manifesto” as a universal principle for all types of work, they risk distorting its intent, potentially violating PMI’s ethical value of responsibility—which demands honesty and accuracy in representation.

Similarly, “Kanban” in its pure form is a Lean Six Sigma manufacturing tool, while “Lean Kanban” is a knowledge work adaptation. Treating “Lean Kanban” as something else than Kanban can mislead stakeholders. The term Lean in front of an established practice potentially violating the ethical value of respect by failing to honour the history and contributions of the practitioners who developed these adaptations

Erosion of Professional Integrity

The PMI Code of Ethics emphasizes fairness and honesty. Presenting the Manifesto for Agile Software Development or Lean Kanban as universal tools for any context undermines professional integrity. It suggests a one-size-fits-all mentality that can lead to failed implementations, disenfranchisement of teams, and a loss of trust.

The Agile Practice Guide and PMBOK both stress tailoring methods to context. Ignoring the original intent of these frameworks can cause project managers to violate the ethical value of responsibility—by not exercising due care in their professional duties.

Risks of Oversimplification

When “Agile” or “Kanban” are thrown around as buzzwords, organizations may ignore the need for real cultural change and the discipline required for successful implementation. Scientific articles published in the 1990s by the Agile Manufacturing Forum, the Manifesto for Enterprise Agility, and PMBOK indicate that successful Agile transformation requires deep understanding, respect for context, and continuous learning. Oversimplification can result in failed transformations, wasted resources, and diminished value delivery—contradicting the ethical value of responsibility and respect for stakeholders.

Impact on Stakeholders

The PMI Code of Ethics underscores the importance of respect and fairness toward all stakeholders. By misapplying frameworks, organizations risk creating confusion and setting unrealistic expectations among teams, leaders, and customers. This can lead to disengagement, frustration, and even project failure.

Recommendations

Honor the Origins

Acknowledge that the Manifesto for Agile Software Development was written by and for software developers. When applying Agile principles outside software, draw from sources such as the Manifesto for Enterprise Agility, which intentionally adapts Agile thinking to broader contexts. Similarly, acknowledge the roots of Lean Kanban (as applied in knowledge work) in the original Kanban in manufacturing.

Tailor with Integrity

Follow the guidance of the PMBOK and Agile Practice Guide: tailor your approach to fit the context. This means being honest about the limitations and applicability of each framework. When communicating with stakeholders, clarify what version or adaptation of Agile or Kanban you are using—and why.

Educate Stakeholders

Invest time in stakeholder education. Ensure teams, leaders, and clients understand the source and intent of the practices being used. This supports responsibility and respect, and aligns with the PMI value of serving the public interest.

Reflect on Ethical Values

Use PMI’s Code of Ethics and Professional Conduct as a compass. Ask yourself: Are you being honest about what you are implementing? Are you respecting the contributions of those who developed these frameworks? Are you treating stakeholders fairly by setting realistic expectations?

Continuous Improvement

Adopt a mindset of learning and humility. Just as the Manifesto for Agile Software Development calls for continuous reflection, so too should organizations regularly review their practices in light of ethical standards and evolving contexts.

The Bottom Line

Using the Manifesto for Agile Software Development (aka “Agile Manifesto”) as a blanket term for all things Agile or treating Lean Kanban as something other than the Lean Six Sigma practice of kanban risks misrepresentation, confusion, and ethical lapses. By honouring the origins, tailoring with integrity, educating stakeholders, and reflecting on ethical values, project managers and organizations can uphold the ethical values of responsibility, respect, fairness, and honesty. This not only avoids ethical pitfalls, but also increases the likelihood of real, sustainable transformation and value delivery.

Question for Readers: Have you experienced challenges when Agile or Kanban were applied outside their original context?


Posted on: August 07, 2026 01:37 AM | Permalink

Comments (12)
Please login or join to subscribe to this item
avatar
Luis Branco CEO| Business Insight, Consultores de Gestão, Ldª Carcavelos, Lisboa, Portugal
An important argument for historical accuracy and contextual tailoring, but I see a tension in applying that standard.
If misrepresenting origins can become an ethical concern involving responsibility, respect and honesty, then the same evidentiary standard should apply to the historical claims used to make that case.
Describing Kanban "in its pure form" as a Lean Six Sigma manufacturing tool is problematic because Kanban emerged within the Toyota Production System and predates Lean Six Sigma as a later synthesis.
More fundamentally, I would distinguish historical provenance from legitimate applicability.
Calling the Manifesto for Agile Software Development the Agile Manifesto, or adapting ideas beyond their original domain, is not by itself an ethical lapse.
Misrepresentation may become one, but that requires more than terminological simplification or conceptual evolution.
Otherwise, there is a risk of applying two different standards: demanding historical precision from others while using a debatable historical characterization to justify that demand.
If ethical values are the test, the test should apply symmetrically, including to our own claims.

avatar
Stelian ROMAN Project Manager| MicroSafety Carlingford, New South Wales, Australia
@luis Branco. Reusing a practice or term is fair; Rome was not built in one day, and we should continuously adapt to change. My concern related to the "Agile Manifesto" is that some people forget that it was written by software development consultants for software developers. Moreover, it was written at a time when software development was done completelly different than today. Assuming that "Business people and developers must work together daily throughout the project" is naive. In most projects, we meet with the business weekly or even less frequently. Nothing changed from 1970 when a smart man wrote that "for some reason what a software design is going to do is subject to wide interpretation even after previous agreement. It is important to involve the customer in a formal way so that he has committed himself at earlier points before final delivery. To give the contractor free rein between requirement definition and operation is inviting trouble.". I wonder how many Agile Coaches or Trainers recognise this quote.
Lean Six Sigma acknowledged the origins of kanban. My ethical dilemma is how Lean Kanban can be Agile?
In the Agile spirit, we should challenge and adapt every practice and tool in use, but I strongly believe that it is unethical to clone practices and tools from the very approach that is used to justify Agile superiority.
I like the closing statement of the framework that many teams claim that they use: "The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques".
A practice is either kanban and should retain its name, or it is not kanban and should have a different name.

avatar
Luis Branco CEO| Business Insight, Consultores de Gestão, Ldª Carcavelos, Lisboa, Portugal
Thank you, Stelian. I agree that principles and practices should be continually challenged and adapted as contexts evolve. I also agree that the Manifesto for Agile Software Development emerged from a specific historical context and was written for software development. That origin should be acknowledged. However, using the conventional shorthand "Agile Manifesto" does not, by itself, conceal or misrepresent that origin. Nor does recognizing the original domain of a set of principles permanently confine their legitimate applicability to that domain. Historical provenance and subsequent applicability are distinct questions.

The Royce quotation is relevant because it illustrates the enduring problem of ambiguity and the need for customer involvement even after requirements have been agreed. However, it does not establish that daily collaboration is naive, nor that nothing has changed since 1970. Formal customer commitment at defined points and continuous collaboration with the business are different coordination models. Working together daily does not necessarily require a formal daily meeting. It can mean preserving the capacity for daily interaction, with timely access to business judgment, clarification and feedback. The fact that many projects engage with the business weekly describes current practice, but does not by itself demonstrate that this frequency is sufficient or appropriate.

On Kanban, the distinction is made particularly clear in the second edition of PMI's Agile Practice Guide. The guide explicitly separates Kanban, the Lean manufacturing concept developed within the Toyota Production System, from the Kanban Method created for knowledge work. It presents both Agile and the Kanban Method as descendants of Lean thinking, acknowledges the continuing debate about whether the Kanban Method belongs to the Lean or Agile movement, and nevertheless formally defines the Kanban Method in its glossary as an agile approach inspired by the original Kanban inventory control system.

The same guide presents the coordinated use of Scrum, the Kanban Method and Extreme Programming practices as a common combination capable of producing synergistic results. It does not characterize Kanban as a Lean Six Sigma practice. Even if later Lean Six Sigma literature acknowledges the origins of Kanban, that does not alter its historical provenance or make Kanban a Lean Six Sigma practice.

I would also question the premise that integrating Kanban into Agile ways of working amounts to unethical cloning. The Manifesto does not claim that Agile is superior to Lean. PMI's guide instead presents Agile and the Kanban Method as sharing a Lean heritage. Integrating practices with common or different origins is therefore not inherently contradictory, particularly when their provenance and purpose remain transparent.

I would distinguish provenance, compatibility and identity. A practice does not need to originate within Agile to contribute to agility. The Scrum Guide similarly protects the integrity of Scrum while explicitly stating that Scrum functions as a container for other techniques, methodologies and practices. Nor is the identity of Kanban a binary choice between remaining completely unchanged and ceasing to be Kanban. The relevant question is whether its defining principles and core properties, including visualizing and managing flow, limiting WIP, using a pull system, making policies explicit, implementing feedback loops and pursuing collaborative, evolutionary improvement, remain substantively preserved, and whether any adaptation is described accurately.

The ethical issue arises when origins are concealed or materially distorted, authorship is misrepresented, or stakeholders are materially misled. Adaptation, combination and conceptual evolution are not unethical in themselves, provided they are represented accurately and applied transparently. If ethical values are the standard, that standard should apply symmetrically to every claim, including our own.

avatar
Stelian ROMAN Project Manager| MicroSafety Carlingford, New South Wales, Australia
Hi Luis, thank you for your comment. There are a few topics that I will answer separately.
1) "Using the conventional shorthand "Agile Manifesto" does not, by itself, conceal or misrepresent that origin." I agree. My ethical concern is not the name; after all, that's the web domain of the page, but avoiding to aknowledge that it was conceived for software developers by a group of consultants who developed their own frameworks, based on hands-on experience. In 2001, XP was the de facto Agile approach, and it was limited to software development.

avatar
Stelian ROMAN Project Manager| MicroSafety Carlingford, New South Wales, Australia
2) "However, it does not establish that daily collaboration is naive, nor that nothing has changed since 1970. " I started software development in the early 1990's although I had a mechanical engineering background. 'Nothing changed' means that we still have challenges in bridging the gap between business and technology. In my experience, we, the 'developers' were part of the business before the early 2000's when small software development companies appeared. I started in a 'small', in the big scheme of things, manufacturing company (5000 employees), and the IT (The Computer Office) had less than 15 employees, mostly data entry operators. In my opinion and based on empirical observation, formal daily scrums with active participation from the business are a myth. A 'PO' who has no strategic vision, no decision power, and low authority in the organisation does not add value to the team/project.

avatar
Stelian ROMAN Project Manager| MicroSafety Carlingford, New South Wales, Australia
3) Kanban, either version, is a technique to standardise the process, not a real enabler for embracing change. Everything can be Agile AND Lean at the same time, but one of the aspects will be dominant. Royce's 'waterfall' method is, in my opinion, more Agile than any 'scaled' Agile framework that started as a book about how Lean principles can be used in software development.

avatar
Stelian ROMAN Project Manager| MicroSafety Carlingford, New South Wales, Australia
4) " I would also question the premise that integrating Kanban into Agile ways of working amounts to unethical cloning. " Integrating Kanban is not unethical; covering a failed Scrum adoption, in my opinion, is. When Kanban is used to remove time commitments, retrospectives, and, in general, planning, the result is not Agile. (Hence the quote from the Scrum Guide)

avatar
Stelian ROMAN Project Manager| MicroSafety Carlingford, New South Wales, Australia
5) "I would distinguish provenance, compatibility, and identity." I agree 100%. That's why I believe that it is unethical to acknowledge the origin of concepts like Servant Leader, Team Formation, and Kanban. Iterative and incremental software development didn't start in 2001, and it is not, in my opinion, what defines Agile because it can, and is done, in traditional software delivery methodologies. Moreover, that's how any product was developed for millennia; otherwise, we would still use spears.:)

avatar
Stelian ROMAN Project Manager| MicroSafety Carlingford, New South Wales, Australia
"The ethical issue arises when origins are concealed or materially distorted, authorship is misrepresented, or stakeholders are materially misled. Adaptation, combination and conceptual evolution are not unethical in themselves, provided they are represented accurately and applied; that's exactly my point.

avatar
Stelian ROMAN Project Manager| MicroSafety Carlingford, New South Wales, Australia
"The ethical issue arises when origins are concealed or materially distorted, authorship is misrepresented, or stakeholders are materially misled. Adaptation, combination and conceptual evolution are not unethical in themselves, provided they are represented accurately and applied; that's exactly my point.

avatar
Stelian ROMAN Project Manager| MicroSafety Carlingford, New South Wales, Australia
" If ethical values are the standard, that standard should apply symmetrically to every claim, including our own."
In my humble opinion, there is no IF when it comes to ethics. PMI has a very mature approach to ethics, with the ERC having a lot of power to enforce ethical behavior.

avatar
Luis Branco CEO| Business Insight, Consultores de Gestão, Ldª Carcavelos, Lisboa, Portugal
Thank you, Stelian. I think we have reached substantial agreement on the central point. Historical origins should be acknowledged when they are materially relevant to the claim, application or representation being made. However, adaptation, combination and conceptual evolution are not unethical in themselves. The ethical concern arises when provenance is materially distorted, authorship is misrepresented, stakeholders are materially misled, or one approach is deliberately used to conceal the failure of another.

Your example of Kanban being used to conceal a failed Scrum adoption sharpens that distinction. If essential Scrum elements are removed, the result is no longer Scrum. However, it does not necessarily follow that the resulting approach is no longer agile. Scrum identity and agility are not equivalent tests.

Projects may be managed through iteration-based or flow-based approaches. Both can be agile when they preserve responsiveness, feedback, learning, adaptive planning, value orientation and the capacity to act on emerging evidence. Scrum structures work through fixed-length Sprints, while the Kanban Method manages and improves work primarily through flow. These mechanisms differ, but neither has an exclusive claim to agility.

Moving away from fixed-length Sprints or Scrum-specific events does not necessarily eliminate planning, forecasting, feedback or improvement. In a flow-based approach, planning may occur through continuous prioritization and replenishment, forecasting may draw on flow metrics, work in progress may be explicitly limited, and feedback and improvement may be supported through appropriate review and learning cadences. The relevant question is not whether Scrum events remain, but whether the resulting system retains the substantive capacity to learn, adapt and deliver value responsibly.

On your final point, my use of "if" does not suggest that ethics is optional. It identifies the evaluative standard adopted in the post. When ethical values are used to assess the claims or practices of others, the same standard must be applied symmetrically to the claims on which that assessment is based, including our own.

Invoking the Ethics Review Committee does not resolve the substantive question. The ERC's authority derives from PMI's governance arrangements, which establish who may adjudicate alleged breaches of the Code and what institutional consequences may follow. That authority does not, by itself, determine whether a particular terminological simplification, methodological adaptation or conceptual evolution constitutes an ethical violation.

Governance and ethics are related, but they are not interchangeable. Governance establishes authority, procedures and institutional consequences. Ethical evaluation requires examining whether particular conduct breached an applicable obligation, based on relevant and sufficient evidence. The existence of an authorized decision-making body cannot provide the substantive justification that the ethical conclusion itself requires.

Like any adjudicative body, the ERC must apply the Code impartially and recognize the limits of its jurisdiction, procedures and available evidence. Its institutional authority does not eliminate the need to distinguish carefully between error and deception, conceptual evolution and misappropriation, unsuccessful implementation and dishonesty, or methodological disagreement and a breach of the Code.

That is precisely why symmetry and evidentiary precision matter. Before describing a practice as unethical on grounds of misrepresentation, we should be able to identify what was materially misrepresented, who was misled or placed at risk, which ethical obligation was breached and what evidence supports that conclusion. The authority of an enforcement body cannot substitute for that demonstration.

Please Login/Register to leave a comment.

ADVERTISEMENTS

"I choose a block of marble and chop off whatever I don't need."

- Rodin

ADVERTISEMENT

Sponsors







Newsletters

Sep 2: Busy is Not a Symptom of Ambition
Aug 26: Stop Writing Status Reports
Aug 19: PM Lessons From the Himalayas

See all newsletters