Explainability Is the Measure of Accountability: Why Responsible AI Must Evolve into Accountable AI

As I was wrapping up discussions with some people that I had trained for the Project Management Professional (PMP) certification, discussions emerged around Responsible AI. It was interesting to read people's thought about "Responsible AI" from a technical and career enablement standpoint! But, Responsible AI is the start of the leadership for holding oneself accountable for the decisions made. I think therefore, there needs to be an evolution of the next level of AI leadership foundations! 

Undoubtedly, Artificial Intelligence has become remarkably proficient at making predictions. It identifies fraudulent transactions, recommends medical diagnoses, screens job applicants, prioritizes customer requests, and increasingly influences decisions once reserved for human judgment. Yet as organizations race to adopt AI, they continue asking the wrong question. The question is not whether AI is intelligent enough to make decisions. The real question is whether leaders are accountable for the decisions AI helps make. Responsible AI has advanced the conversation around technical reasoning but still has not advanced the ethical leadership. 

It is important to understand that responsibility without accountability remains an aspiration rather than an operational reality. We need to shift our mindset towards the impact of our actions (or lack of it) on the people (employees, customers, end users, societies) and planet (environment) by asking, "How are we accountable for the consequences of an AI-enabled decision?" This mindset is where I believe we move beyond Responsible AI toward Accountable AI. 

• Responsible AI establishes the intention to do the right thing. 
• Accountable AI requires us to explain, justify, and ultimately own what happens.

Consequently, the future belongs to Accountable AI, where both explainability and explicability becomes the mechanism through which accountability is demonstrated.

"Accuracy measures performance. Explainability measures reasoning behind the prediction. Explicability measures ethical and social accountability"
— Dr. Shri Rajagopalan

The distinction begins with three concepts that are often treated as interchangeable: accuracy, explainability, and explicability. 

• Accuracy tells us whether the prediction was correct. 
• Explainability helps us understand the reasoning behind the prediction by understanding data, variables, patterns, features or user behaviors contributed to the model's conclusion. This is essential because an organization cannot govern what it cannot understand. 
• But explainability has a boundary. Knowing why an algorithm reached a conclusion does not tell us whether the conclusion should have been reached, whether the underlying assumptions were appropriate, or whether acting upon that conclusion is ethically defensible. That requires explicability (Floridi & Cowls, 2019). 

Leaders are not faced with explaining the technical architecture or the model differences in the AI system used. That would be explainability based on accuracy and precision. They are faced with answering beyond technical reasoning focused on the impact of the AI system. Hence, explicability takes us beyond technical reasoning toward the ethical and social accountability of AI. It asks not only “Why did the system make this prediction?” but also “Should we accept this prediction, what are its consequences, and can we justify those consequences to the people and communities affected?”

Consider an AI system used to screen employment applicants. The model may be highly accurate and completely explainable. We might even be able to identify precisely which characteristics contributed to a candidate's rejection. But what if those characteristics reflect historical patterns of discrimination embedded within the training data, such as what happened with the Amazon's AI recruiting tool showing preferential treatment to men over women candidates (Datin, 2018)? Explainability can tell us why the model rejected the candidate. Explicability asks the more difficult question: Should those factors have been permitted to influence the decision at all? This is where algorithmic bias becomes a leadership challenge rather than simply a data science problem. The issue is not merely whether the algorithm works as designed. It is whether the organization designed, deployed, and governed the system in a way that is ethically and socially defensible.

Every participant in the AI value delivery pipeline therefore has a responsibility to ask questions that technology alone cannot answer. The onus now shifts to everyone to think risk based questions on outcome and value! Not just, "Can we get this faster?" but more focused on:

• Who benefits from this technology? 
• Who bears its risks? 
• Who controls the algorithmic system? 
• Whose voices are suppressed? 
• Which communities are marginalized? 
• What meaningful options do we give the users affected by the system? 
• What unintended consequences might emerge over time? 

These questions move us from technical accountability toward societal accountability. They also recognize that AI does not operate in a vacuum. An algorithm can optimize a decision while simultaneously optimizing inequality. It can improve overall performance while imposing disproportionate harm on a particular community. It can be technically correct and ethically wrong. That is why the ethical challenge is not the technology itself but the leadership's governance of its use.

Explicability also gives us a different way to understand the fundamental ethical principles of beneficence, non-maleficence, justice, autonomy, and fidelity. These principles should not be treated as independent boxes on an AI ethics checklist. They are symbiotic conditions of accountability. 

• If an AI system causes preventable harm, non-maleficence has been compromised. 
• But the consequences rarely stop there. If the affected individuals have no meaningful ability to challenge the decision, autonomy is compromised. 
• If the harm disproportionately affects a particular population, justice is compromised. 
• If the technology's promised benefits are not realized or are realized primarily by those already advantaged, beneficence is compromised. 
• And when an organization cannot explain, justify, or take ownership of these consequences, fidelity and trust begin to disappear. 

When one ethical principle is compromised, the others are placed at risk requiring not only understanding the primary risk but also the secondary risks. Ethical accountability therefore cannot be achieved by satisfying five principles independently; it requires recognizing their interdependence. The need for this awareness is why I propose the movement from Responsible AI to Accountable AI (Rajagopalan, 2020). If an end-user was unfairly treated with no alternatives presented, it is not technology failure but leadership failure. Reasoning at that point is too late as the arrow has not only left the bow but hit the wrong person or the wrong place. Explainability, from Responsible AI, provides evidence of reasoning. Explicability, from Accountable AI, provides the basis for ethical judgment. This distinction is critical because a transparent explanation of an unjust decision does not make the decision just. A perfectly explainable harmful outcome is still harmful.

Ultimately, Accountable AI requires humans to remain meaningfully involve, not simply as a Human-in-the-Loop who approves or rejects an algorithmic recommendation, but as Humans-in-the-Middle of an ongoing accountability system. Anyone in the AI based delivery lifecycle shouldn't be afraid of their jobs but should reorient themselves to their new improved leadership responsibility. The future of ethical AI, therefore, should not be measured solely by how intelligent our machines become. It should be measured by how accountable the humans governing those machines remain in our commitment to people, community, and the planet.

“Responsible AI asks whether we are doing the right things. Accountable AI asks whether we are willing to stand behind what those things do.”
— Dr. Shri Rajagopalan

What are your thoughts?

References

Datin, J. (2018). Insight - Amazon scraps secret AI recruiting tool that showed bias against women. https://www.reuters.com/article/world/insight-amazon-scraps-secret-ai-recruiting-tool-that-showed-bias-against-women-idUSKCN1MK0AG/

Floridi, L., & Cowls, J. (2019). A Unified Framework of Five Principles for AI in Society. Harvard Data Science Review, 1(1). https://doi.org/10.1162/99608f92.8cd550d1

Rajagopalan, S. (2020, September). Artificial Intelligence Solutions: Four Considerations extended from Digital Bioethics. https://agilesriram.blogspot.com/2020/09/artificial-intelligence-solutions-four.html

From Agile to AI: Why Culture May Determine the Winners of the AI Revolution

Twenty-five years ago, a small group of software practitioners gathered in the mountains of Utah and produced the Manifesto for Agile Software Development (n.d). Disappointed with the way software projects were developed then, their ideas challenged the dominant project management paradigm of the time: detailed upfront planning, rigid processes, and extensive documentation. Instead, they advocated for adaptability, collaboration, customer feedback, and continuous learning. Little did they really understand the concepts of just-in-time, limiting work in progress, eliminating waste, and progressive elaboration with rolling wave planning that were already foundational to project management where practice created a non-existent theory (Rajagopalan, 2014). 

Although the adaptive Agile ways eventually spread across industries and continents, its adoption was far from uniform. Some organizations embraced it enthusiastically, while others struggled or rejected it altogether. The reasons were often deeper than process or technology; they were cultural. While later Agile practitioners called any Agile Transformation to be a practice rooted in change management to modify the team and organizational culture, the adoption of culture was an after-thought! It shows the myopic foresight and the lack of diversity of the practitioners which is evident from the second manifesto principle "working software over comprehensive documentation" limiting the agile approaches to software development. 

Based on numerous years of research, the Dutch social psychologist Geert Hofstede (1980) provided a comprehensive lens to view the geographical culture across five dimensions first and later adding the sixth dimension. These dimensions include: Power Distance, Individualism, Motivation towards achievement and success (which was originally called Masculinity), Uncertainty Orientation, Long-Term Orientation, and Indulgence (sixth dimension added later). More details of these cultural elements can be found in Hofstede's Culture Factor Group (n.d) or in other scholar-practitioner materials (Hofstede & Bond, 1988; Hofstede, 2011).

In summary, countries with lower power distance often found it easier to embrace self-organizing teams and decentralized decision-making. Cultures with lower uncertainty avoidance were generally more comfortable with experimentation, iterative delivery, and evolving requirements. Highly individualistic societies often adapted quickly to Agile's emphasis on empowered individuals, while collectivist cultures sometimes preferred greater structure and consensus-building. None of these approaches were inherently better or worse, but they influenced how Agile was interpreted, implemented, and sustained. When Agile was promoted because people attended a Scrum Master workshop or gained an online training, little to no attention was given to the cultural considerations of the team members, their hybrid cultures due to long travel, immigration, expatriate arrangements, etc. So, agile didn't fail but we failed agile. 

Author's attempt to compare four countries (May 2026)

Today, organizations face another transformative wave: Artificial Intelligence. Much like Agile, AI is frequently presented as a universal solution capable of improving productivity, accelerating innovation, and transforming business models. The landscape of existing roles are being refined or even redefined where people have began question why do we need developers as AI tools can write them, why do we testers because tools can help with automation, and why do we need project managers, product owners, or scrum masters because AI can replace them! Organizations and leaders have not yet learned the lessons that Agile adoption taught. Extending these observations, AI adoption will not be determined solely by technological capability. As a popular saying goes, "A fool with a tool is still a fool," successful AI adoption needs people to realign AI ways of working with the individuals and team culture, organizational culture, leadership philosophies, risk tolerance, and societal values. The same cultural dimensions that shaped Agile adoption are likely to shape AI adoption as well.

Consider uncertainty avoidance, which is the orientation to risk. Organizations and societies with high uncertainty avoidance often demand predictability, governance, and clear accountability. Such environments may be slower to adopt generative AI systems whose outputs can be probabilistic and occasionally unpredictable. Conversely, cultures more comfortable with ambiguity may experiment aggressively with AI, accepting occasional failures as part of the learning process. Similarly, power distance influences whether AI is viewed as a democratizing force that empowers employees or as a centralized tool controlled by senior leadership. Long-term oriented cultures may prioritize investments in AI capabilities that take years to mature, while short-term oriented cultures may focus on immediate productivity gains and rapid return on investment.

However, AI introduces a dimension that Agile largely avoided: ethics at scale. While Agile transformed how work was organized, AI has the potential to transform how decisions are made. This shift requires leaders to move beyond questions of efficiency and effectiveness toward questions of responsibility and societal impact. Ethical frameworks such as Utilitarianism ask whether AI creates the greatest good for the greatest number. Deontological perspectives ask whether certain actions remain wrong regardless of outcomes. The Indian concept of Lokasamgraha (Singh & Awasthy, 2023) reminds us that decisions should contribute to the welfare and stability of society as a whole. Likewise, the bioethical principles of beneficence, non-maleficence, justice, and autonomy provide valuable guidance for evaluating AI systems that increasingly influence human lives.

One of the most important lessons from Agile is that transformation cannot simply be imposed through frameworks, certifications, or technology investments. Many organizations adopted ceremonies without embracing values, resulting in what practitioners often call "Agile in name only." AI faces a similar risk. Organizations may deploy chatbots, copilots, and predictive algorithms without addressing trust, transparency, governance, workforce readiness, or ethical safeguards. Just as Agile required cultural adaptation rather than procedural compliance, AI adoption requires organizations to align technology with values, leadership behaviors, and stakeholder expectations.

The future may belong not to the organizations that adopt AI the fastest, but to those that adopt it the wisest. Agile taught us that successful transformation occurs when methods align with culture and when people are empowered to learn and adapt. AI extends that challenge from teams and organizations to society itself. As leaders navigate this next era, the question is not simply whether AI can improve performance. The more enduring question is whether our cultural values, ethical principles, and leadership choices can ensure that AI improves humanity as well.

References

The Culture Factor Group (n.d.) Retrieved from https://www.theculturefactor.com/

Hofstede, G. (1980). Culture's Consequences: International Differences in Work-Related Values. Beverly Hills, CA: Sage. 

Hofstede, G. & Bond, M. H. (1988). The Confucius connection: from cultural roots to economic growth. Organizational Dynamics, 16, 4-21.

Hofstede, G. (2011). Dimensionalizing Cultures: The Hofstede Model in Context. Online Readings in Psychology and Culture, 2(1).

Manifesto for Agile Software Development (n.d.). Retrieved from https://agilemanifesto.org/

Rajagopalan, S. (2014). Review of the myths on original software development model. International Journal of Software Engineering & Applications, 5(16), 103-111.

Singh, D. & Awasthy, R. (2023). Lokasamgraha: An indigenous construct for social entrepreneurship. IIMB Management Review, 35(4), 344-358.

Mechanical Empathy: A New Leadership Competency for the AI Era

I have been experimenting with some of the AI tools in developing some new functionality! When I asked it if something can be done, it started doing it! I responded with a prompt, "Don't jump to conclusions dragging me with you! Instead, stop and engage me with powerful questions so that we can collaborate on the solution!" I treated the interaction with the AI tool as a coach would engage with the person coached. Not commanding with prompt engineering as many prompt engineering schools of thought emphasize with the STAR (Situation, Task, Action, Results) method, for instance. During my interactions with AI, I realized the need for "Mechanical Empathy."

The irony of the modern workplace is striking. I have seen people complain, “Gen AI sucks!” In one of the interactions with participants at my talk in Melbourne on "Modern Cost of Quality", people asked, “Why should we worry about workload for robots? They are not living beings.” Yet, I see everyone emphasize empathy, inclusion, psychological safety, and sustainable work practices for human teams. Wait, did we somehow in our rush toward the “AI race,” forget a critical leadership principle: the way we interact with technology shapes the quality of the outcomes we receive. We may not need emotional attachment to machines, but certainly need something deeper and more practical: mechanical empathy. Not empathy for feelings, but empathy for systems, limitations, constraints, context, and capability. As the AI race continues, the more we fail to realize this new leadership competency, the more we will extend that same thoughts on humans. Would that shape a better future?

Consider how we treat children learning to communicate. We do not ask a six-year-old fifty complex questions in thirty seconds and then ridicule them for misspelling a word. We do not hand a new employee the workload of five people and then publicly shame them for underperforming. If we did, most leadership experts would identify the root problem not as incompetence of the child or the employee, but failure in parenting, coaching, management, and system design. Yet this is precisely how many people interact with AI systems today. Users bombard AI with vague prompts, contradictory instructions, overloaded requests, insufficient context, unrealistic expectations, and then critique the results with remarkable confidence. The issue is often not that the machine lacks capability, but that humans lack intentionality in how they engage with it.

Mechanical empathy is not about pretending AI is human. It is about recognizing that every system — human or machine — operates within constraints, patterns, architecture, and context. High-performing leaders already understand this intuitively when working with people. Leadership-level empathy requires presence in the moment, careful observation, appreciation of ideas and situations, curiosity expressed through thoughtful questions, reflection before reaction, risk awareness, ethical consideration, and constructive feedback designed to stimulate improvement rather than humiliation. Ironically, these same leadership behaviors improve AI interactions as well. Clear prompts, structured context, iterative refinement, workload balancing, validation mechanisms, and feedback loops often produce dramatically better outcomes than impulsive criticism. In many ways, effective AI utilization is exposing how poorly many individuals communicate, delegate, and think critically.

There is also a broader organizational implication. As agentic AI systems increasingly become part of the workforce — scheduling work, analyzing data, drafting communications, automating workflows, and even coordinating decisions — organizations may need to rethink the meaning of workforce management itself. Leaders already understand that burned-out human teams make more mistakes under chaotic conditions. Similarly, overloaded AI ecosystems operating with poor governance, weak data quality, fragmented instructions, and unrealistic dependency expectations can amplify errors at scale. Mechanical empathy therefore becomes a form of operational intelligence. It requires leaders to design environments where both humans and machines can perform sustainably and responsibly. The question is no longer simply whether AI is intelligent, but whether humans are interacting intelligently with AI.

Ultimately, the conversation about empathy toward AI is not really about protecting machines. It is about improving humanity’s relationship with technology and reflecting on our own behaviors. The faceless mechanical workforce may not possess emotions, but our interactions with it reveal our patience, discipline, ethics, critical thinking, and leadership maturity. The organizations and individuals who succeed in the AI era will not necessarily be those with the fastest tools, but those who develop the wisdom to engage thoughtfully with both human and mechanical systems. Mechanical empathy may become one of the defining leadership capabilities of the next decade — not because machines demand it, but because effective leadership always begins with understanding the nature, limitations, and potential of the systems we seek to influence.

What are your thoughts? Please share.

AI isn’t replacing leaders - It reveals the leadership gaps

Recently, I took part in a strategy discussion about the need to incorporate AI in designing good practices and preparing the next generation training them on AI tools. I reasoned the focus should not be on execution efficiency but strategic effectiveness. A gentle reset is required understanding the role of AI in future than rushing to adopt AI everywhere! If we look back into the present from a future, is this what we want our next generation to have? 

Artificial Intelligence is often celebrated as the ultimate accelerator of efficiency—automating workflows, optimizing operations, and reducing human error. And to be fair, it delivers on that promise. Organizations today can execute faster, cheaper, and at scale in ways unimaginable a decade ago. But beneath this efficiency boom lies an uncomfortable truth: AI is not closing leadership gaps—it is exposing them. The more we rely on AI for execution, the more visible our shortcomings become in strategic thinking, business acumen, and long-term value creation.

I can certainly say that AI excels at anomaly detection, pattern recognition, and fault prevention, far beyond the mundane automation tasks it is commonly used for. I myself have used AI to create things that would have taken a lot of time! So, yes, it can identify fraud in milliseconds, predict equipment failures before they happen, and surface trends hidden deep within complex datasets. Yet, do these capabilities inherently translate into better strategic decisions? 

Recognizing a pattern is not the same as interpreting its meaning in a volatile market. Detecting anomalies does not equate to understanding their business implications. Drafting even an email does not necessarily connect with the cultural connation of the way the message may be perceived. The gap here is not technological; it is cognitive. Leaders must still ask: Which patterns matter? Which risks are worth taking? Which signals should shape our strategy? AI informs decisions; it does not make them wise. So, do we prepare people for leadership role? Does the use of AI in their responsibilities make someone a leader?

Consider facial recognition technologies. AI systems have reached remarkable levels of accuracy in identifying individuals, yet they continue to struggle with bias. This is not a failure of algorithms alone; it is the lack of risk management thinking leading to the  failure of governance, ethics, and oversight. Bias in AI reflects bias in data, which in turn reflects bias in human systems. Leadership gaps in ethical frameworks, inclusive thinking, and accountability become amplified when scaled through AI. In my mind, AI there is an amplifier of our gaps mainly on leadership level strategic thinking. The question is no longer whether AI can recognize faces, but whether leaders can recognize and correct systemic inequities embedded in their organizations.

Similarly, AI’s prowess in pattern recognition has not guaranteed success in market or product development. Companies have access to unprecedented consumer insights, yet many still fail to create products that resonate or strategies that endure. Why? Because strategy is not just about identifying trends—it is about making choices under uncertainty. It requires judgment, intuition, and the courage to deviate from data when necessary. AI can suggest what is happening, but it cannot define what should happen. That responsibility lies fully with leadership, and it is here that capability gaps—particularly in strategic thinking, customer-centric innovation, process oriented sustainment considerations, alternative impact oriented thinking inherent in risk and people oriented change management become glaringly evident.

Even in highly automated environments like aviation, autopilot systems have not eliminated the need for pilots. Instead, they have elevated the role. Pilots are no longer just operators; they are decision-makers in critical moments when systems fail or unexpected conditions arise. In the healthcare setting, AI enabled systems can identify tumors but have not removed the need for diagnostic image operators, radiologists, physicians, or surgeons. It has only made their role more important. 

The same principle applies to business leadership in the age of AI. As execution becomes increasingly automated, the expectation for leaders shifts toward higher-order capabilities: governance, risk management, ethical judgment, and continuous capability building. AI does not replace leadership and it raises the bar for it. The organizations that will thrive are not those that adopt AI the fastest, but those that close the widening gap between technological capability and strategic leadership maturity.

What are your thoughts? Please comment.

With AI here to stay, what kind of humans will autonomous systems and mechanical robots demand?

I was traveling in India where I had discussions with family and friends around the revolutionary AI landscape. I could sense a feeling of paranoia and confusion. So, I asked myself, "Imagine a future meeting where scheduling is automated, risks are predicted in real time, stakeholder sentiment is analyzed instantly, and portfolio trade-offs are simulated before anyone speaks. The dashboards are perfect." In such a utopian world, what happens when the contextual decisions are problematic and the forecasts are probabilistic. Would the robots turn to the human in the room and say, “Optimization complete. Strategic ambiguity unresolved. Ethical trade-off undefined. Human intervention required.” In my mind, that is not science fiction. That is trajectory.

AI is extraordinarily good at optimization. It can reduce noise in medical images, prevent aircraft drift through autopilot, activate ABS braking systems in milliseconds, and execute trades at speeds no human can match. It detects patterns, flags anomalies, and recommends mitigation paths. But optimization is not direction. Prediction is not purpose. Progress is not value. Algorithms can simulate ten efficient options; they cannot define which future is worth pursuing. They cannot decide what the organization should value when speed conflicts with sustainability, or profit conflicts with reputation.

In such a world, project management does not disappear—it mutates and reemerges. The coordinator of tasks becomes the architect of decisions. The status reporter becomes the framer of ambiguity. The future competency is not mastering more tools; it is mastering judgment. It is rethinking the current process and workflow rather than fall victim to an old tool. It is the ability to think and address risks much before it materializes. It is the ability to define value under uncertainty, to reconcile competing incentives, to make trade-offs that algorithms surface but cannot morally resolve. AI will compress execution layers. What remains, and expands, is decision architecture.

If Agile were written in an AI-native era, it might read differently. Not “responding to change over following a plan,” but conscious human judgment over blind automation. Not velocity metrics over everything else, but strategic intent over algorithmic efficiency. Agile was always about adaptability in complex environments. AI increases complexity. It accelerates data. It amplifies consequence. It does not eliminate the need for leadership—it sharpens it.

The uncomfortable truth is this: AI will not replace project leaders. It will expose those who never moved beyond tools. In a room full of autonomous systems, the only human invited to stay will be the one who can answer: Why are we doing this? Who benefits? What risks are we willing to accept? What future are we choosing? Leadership begins where optimization ends. And in that moment—when the machines pause and wait—the human who can think will matter more than ever.

What are your thoughts?

Has AI killed Agile and Project Management?

Is Agile dead? Do we even need project managers in an AI-driven world? 

These questions surfaced every time technology discussions around AI came up in the last 3-4 months. But before we declare the end of a profession, we must pause and examine a deeper truth: First, AI isn’t new. I was exposed to Expert Systems in 1991-92 when I designed rules based first responder system  using Prolog. If I have exposure to it almost 3 decades back, then, I am sure many others have used it in numerous ways. 

In my experience subsequently, I have found that we have trusted it for years. It already flies planes through auto-pilot systems, prevents skidding through ABS braking, and executes trades in milliseconds through algorithmic platforms. In healthcare, it enhances diagnostic images and flags clinical risks long before the human eye can detect them. Yet in every one of these domains, humans remain accountable. Why? Because context, risk, and ethics cannot be automated. Judgment cannot be outsourced.

The question to ask here is did AI eliminate pilots, drivers, traders, or physicians? No. It elevated them. It removed repetitive execution and exposed the higher-order responsibility of decision-making. The same shift is happening in project management. AI can optimize schedules, analyze risks, summarize meetings, and generate reports. But it cannot align conflicting stakeholders, resolve strategic trade-offs, or lead teams through ambiguity and resistance. It cannot sit in a room where political tension exists, apply context, and choose courage over convenience. It cannot balance short-term delivery pressures with long-term enterprise value. Project management was never about tasks; it was always about decisions.

So, Agile is not dead and neither is project management. What is dying is cargo-cult Agile and checklist-driven project management. Frameworks were never meant to replace thinking but promote it. When we confuse process compliance with leadership, we diminish the profession. The uncomfortable reality is this: AI will not replace project managers, but it will expose those who never learned to think strategically. It will surface who understands value and who only understands velocity. It will reveal who can translate uncertainty into direction and who relies solely on templates.

In Leadership Unleashed, I argue that leadership begins when we move beyond tools and into conscious choice. This moment in history is not a threat to project management; it is a clarifying force. AI optimizes execution. Humans create meaning. AI accelerates data. Leaders shape direction. In a world of increasing complexity, the need is not for fewer project leaders—it is for stronger ones. The future does not belong to those who manage tasks. It belongs to those who can think, decide, and lead when certainty is absent.

Tools Don’t Create Great Scrum Masters—Leadership Does

Very recently, I was engaged in LinkedIn conversation! That LinkedIn post began listing a few commercial tools as the critical assets of a great Scrum Master! When I mentioned Scrum is mainly about promoting leadership, there was a comeback that leadership can coexist in the tools! Since social media is a place for free speech, I didn't extend the conversation much to create an unhealthy discussion! However, I decided to write my thoughts briefly in my monthly blog. 

Having helped many companies with their agile transformation and stood up many successful teams, I firmly believe that no commercial tool makes anyone a great Scrum Master, Project Manager, or leader. Neither has any tool promoted the self-organization emphasizing the critical Scrum Values - Courage, Focus, Openness, Respect, and Collaboration. Please don't get me wrong - a good tool can certainly help the team bring risk driven prioritization and enable visibility to the work in progress! A good tool can surface impediments earlier, promote single source of truth, and advance the total cost of ownership! 

However, over the years, I’ve seen organizations invest heavily in many siloed tools and use reporting dashboards weaponizing the metrics. Some examples include: 

• Use one team's velocity as a benchmark for another team's performance
• Use individual stories completed within the team creating a hierarchy instead of self-organization
• Create more work with integrating documents in one tool (wiki) with stories in another tool (board), etc. 

What is going on here? People are missing the fundamental concepts of a framework. No framework (PMBOK, Agile, Scrum, Lean, Kanban, etc.) ever mentioned using one commercial tool! People's affinity and comfort zone towards certain tools make them believe agility would emerge once the tool was “properly configured.” What actually emerged was something else: beautifully documented dysfunction. I challenge this exact fallacy, that is, the belief that structure can replace thinking, process can substitute for leadership, and tool can provide both the thinking and leadership (Rajagopalan, 2025a). Thinking and leadership should continually evolve with external and internal business environment! 

In one engagement, a team proudly showcased an advanced Jira setup with custom workflows, automated rules, and detailed dashboards. Yet delivery was slowing, morale was low, and finger-pointing was high. When asked what problem the tool was meant to solve, the room went quiet. The use of the tool had become the goal (Rajagopalan, 2025b)- not using the tool to create a product, service, or result that the customer used! The leadership conversation had disappeared.

Scrum is about helping people dream, learn, and deliver more for customers

A great Scrum Master’s job is not to manage boards but to expand what the team believes is possible. Many scrum certification courses and microlearning modules emphasize servant leadership without truly even understanding the elements of servant leadership (Rajagopalan, 2024)! Having invested substantial time and researched these areas of leadership, I firmly believe this is where transformational leadership becomes essential. The Scrum Master must help teams dream bigger, learn faster, and deliver more meaningfully. Scrum Master does not do this by pushing people harder, but by leading differently.

I once coached a Scrum Master (Rajagopalan, 2025c) who believed the Scrum Master role was to “keep the team moving faster.” Velocity charts dominated every discussion. When we stepped back, it became clear that the team had stopped experimenting, stopped challenging assumptions, and stopped learning. Speed had replaced curiosity. This is exactly why I emphasize that thinking leadership over mechanical execution is inexorably pivotal because without learning, acceleration is just burnout in disguise.

The 4 I’s of Transformational Leadership show up daily in effective Scrum Mastery (Rajagopalan, 2014a). 

• Individualized consideration is visible when a Scrum Master recognizes that a senior engineer disengaging in retrospectives is not a performance problem but a signal of unaddressed frustration. 
• Inspirational motivation appears when sprint goals are framed around customer impact instead of ticket completion.
• Intellectual stimulation surfaces when team members are coached to ask uncomfortable questions (Why do we accept this risk? Why is delivering this feature with bugs important over delivering something usable to the customer? What kinds of new persona of customers have we unearthed by these new functionalities?).
• Idealized influence is the power skills that the Scrum Master demonstrates by walking the talk. 

These are conversations that does not happen in the tool that direct the team to deliver valuable outcomes. 

Tool Fetishism: When Comfort Zones Kill Agility

But, what happens when people gravitate on the tools galore without understanding the core empirical pillars like transparency, inspection, and adaption! This leads to Tool Fetishism that thrives when familiarity (learning has stopped) and judgment and comfort substitutes ways of working. I’ve seen teams defend suboptimal workflows simply because “that’s how <the tool> works.” In reality, that’s how they configured it, often years ago, under different constraints. 

The tool itself is not the culprit. The tool itself evolves over time! But, the internal security policies or lack of interest in upgrading the tool to benefit from its newer features or exploring tools to evaluate other tools make people think the tool is the failure!  

In one case, a team resisted adopting a newer collaboration tool that better supported discovery work, insisting Jira was sufficient. Discovery conversations were being forced into ticket comments, and learning slowed dramatically. The Scrum Master initially complied—until she realized comfort was masquerading as maturity. Challenging the status quo felt risky, but leadership demanded it. This mirrors a core theme in Leadership Unleashed: comfort zones are organizational blind spots.

Velocity misuse is one of the most damaging agile anti-patterns I encounter. Originally designed as a planning heuristic, velocity often becomes a proxy for productivity, discipline, or even individual performance. When that happens, teams respond rationally—to the wrong incentive. I once worked with a team (Rajagopalan, 2014b) whose velocity steadily increased while customer defects also rose. Stories were being split unnaturally, estimates inflated, and technical debt deferred—all to “meet expectations.” Jira showed success. Reality did not. This is a textbook example of metric-induced blindness (Rajagopalan, 2025a) when numbers replace judgment because data can be abused to tell a wrong story.

Pseudo-Agility: When Doing Agile Replaces Being Agile

The tool fetishism leads to pseudo-agility, which is not a failure of intent but a failure of leadership. Standups occur, PI plans are conducted, and retrospectives are documented. Ceremonies become ritualized with nothing fundamentally changing because mediocrity has become the new norm. Teams comply without committing, participate without owning, and deliver without learning.

In a global program spanning time zones, daily standups had become status broadcasts. No impediments surfaced, not because they didn’t exist, but because it wasn’t safe—or useful—to raise them. Once leadership shifted the focus from reporting to sense-making, the same ceremonies began producing real insights. The rituals didn’t change. The leadership did.

I believe tools are radiators with data to serve key metrics. As the old saying, "Garbage In, Garbage Out" goes, it is the working agreements, ways of working, and business processes that drive critical conversations! A transformational Scrum Master treats tools as conversation starters, not judgment tools. Metrics are invitations to inquiry, not verdicts. Dashboards raise questions rather than close discussions. 

Remember that although the manual screw driver works well, if we fail to see what other types of tools exist like a power drill, we will not be supporting the team to dream, learn, and deliver. I myself have challenged the leaders based on appreciative inquiry inside the organization and outside the organization to give up on the tools (Jira, OnTime, Mercury Quality Center, and numerous other processes like manual tracking) and leading the organization to be more productive on a better tool called SpiraTeam (Rajagopalan, 2012).

Leadership First. Tools Next. Agility cannot be installed, configured, or automated into existence. Tools can support agility, but they cannot rescue it. When leadership leads and tools follow, teams learn, adapt, and improve sustainably. What do you think? I am interested in your thoughts!

References

Rajagopalan, S. (2012, April). Leading Change: Remote Teams can collocate on the right ALM tools. Retrieved https://agilesriram.blogspot.com/2012/04/leading-change-remote-teams-can.html

Rajagopalan, S. (2014a, February). Ingredients of a Transformational Leader-What can you do? Retrieved https://agilesriram.blogspot.com/2014/02/ingredients-of-transformational-leader.html

Rajagopalan, S. (2014b November). Cost of Quality: The increasing value of acceptance testing besides automated testing. Retrieved https://agilesriram.blogspot.com/2014/11/cost-of-quality-increasing-value-of.html

Rajagopalan, S. (2024, January). Servant Leadership: Demystify the Agile Scrum Scaled Agile misconceptions. Retrieved https://agilesriram.blogspot.com/2024/01/servant-leadership-demystify-agile.html

Rajagopalan, S. (2025a). Leadership Unleashed: Game Changing Insights. Denver, CO: Outskirts Press.

Rajagopalan, S. (2025b, August). Resource Management: Stop Managing People-Start Managing Flow, Capacity, and Intent. Retrieved from https://agilesriram.blogspot.com/2025/08/resource-management-stop-managing.html

Rajagopalan, S. (2025c, July). When “Team Harmony” Becomes the Problem: A Scrum Master Coaching Moment. Retrieved https://agilesriram.blogspot.com/2025/07/when-team-harmony-becomes-problem-scrum.html

Rajagopalan, S. (2025d, October). Consensus Isn’t Alignment: Lessons from NGT, Delphi, and Wideband Delphi. Retrieved https://agilesriram.blogspot.com/2025/10/consensus-isnt-alignment-lessons-from.html

Navigating and leading team and stakeholder journeys

 Navigating Team and Stakeholder Journeys: A Dynamic Approach

Team development and stakeholder engagement both follow structured stages—Forming, Storming, Norming, Performing, and Adjourning for teams, and Unaware, Resistant, Neutral, Supporting, and Leading for stakeholders. While these stages appear linear in theory, real-world challenges can cause regression. Poor collaboration, change introduction, lack of risk awareness, shifting roles, or inconsistent practices can push teams and stakeholders backward, making proactive engagement essential for sustainable progress.

1. Forming & Unaware: Laying the Foundation
Just like teams may be anxious unaware of what the initiatives are for in the forming stage, some stakeholders may be unaware of how these initiatives may impact them or what their role would be in them. Clear communication is crucial—leaders must articulate vision, objectives, and expectations early. For teams, setting norms and fostering psychological safety can ease transitions. For stakeholders, awareness campaigns, informative sessions, and targeted messaging help move them from unawareness to engagement. Essential documents here include business case, benefits management plan, and project charter.

2. Storming & Resistant: Managing Conflicts and Concerns
As teams enter the storming phase, conflicts emerge over roles, responsibilities, and approaches. Similarly, stakeholders may resist changes that disrupt their routines or priorities. Leaders must actively listen, mediate conflicts, and address concerns with transparency. Encouraging open dialogue, clarifying goals, and demonstrating quick wins can mitigate resistance and build trust. Essential documents include project charter, risk register, stakeholder register, stakeholder engagement plan, and team charter with a clear project vision/scope statement.

3. Norming & Neutral: Aligning and Strengthening Commitment
Once conflicts subside, teams begin norming, establishing efficient workflows and mutual respect. Stakeholders, too, may shift to a neutral stance, neither opposing nor actively supporting efforts. Reinforcing alignment through continuous feedback, recognition, and collaborative decision-making strengthens commitment. Encouraging stakeholder input in planning processes fosters a sense of ownership and investment in outcomes. An essential aspect here is the updates to all the management documents in the storming phase and primarily the team charter that the team creates themselves. 

4. Performing & Supporting: Driving Synergy and Value
High-performing teams operate with synergy, leveraging strengths for optimal results. Stakeholders at this stage move from passive acceptance to active support. Leaders should empower teams with autonomy, provide resources for innovation, and celebrate successes. For stakeholders, demonstrating tangible benefits, inviting deeper collaboration, and showcasing impact stories can strengthen their advocacy.

5. Adjourning & Leading: Sustaining Engagement Beyond Completion
Teams eventually adjourn as projects conclude or objectives shift. Engaged stakeholders, however, can continue leading initiatives forward. Capturing lessons learned, maintaining relationships, and transitioning responsibilities smoothly ensure sustained engagement. Recognizing contributions, fostering ongoing dialogues, and preparing for future collaborations reinforce long-term partnerships.

By understanding the dynamic nature of both team and stakeholder journeys, leaders can anticipate regressions and proactively address challenges. Intentional engagement strategies help navigate transitions, ensuring both teams and stakeholders remain aligned, resilient, and forward-moving in the face of change.

Consensus Isn’t Alignment: Lessons from NGT, Delphi, and Wideband Delphi

When coaching a person for their PMP exam, a discussion emerged emphasizing that consensus meant alignment of expectations! Early in my career, I understood the expression, "the elephant in the room," where everyone in a collective setting fail to address a controversial issue despite the knowledge of its obvious existence. The comfort of not addressing it, bringing it to the surface due to the sensitivity of the issues, or even be labelled a naysayer for acknowledging it publicly were a few things I had observed are risks that impede value delivery! To me, silent agreement or unanimous consensus without any discussion is frequently a possible indication that important knowledge is not visible into the room and subsequently never makes it into the decision-making. 

That realization pushed me toward structured consensus techniques, not because I love process, but because I had seen what unstructured collaboration does under pressure. So, I explained three techniques, in particular, that have stayed with me over the years in light of a product that once I managed: These are the Nominal Group Technique (NGT), Delphi, and Wideband Delphi. Each earned its place through practical scars and are not juts theory.

Sometime around 2012, I was developing an innovative first-responder mobile application  for a pharmaceutical client. The application integrated with portable ECG collectors connected to an iPad and used in an ambulance. The goal was to capture ECG data from unconscious or incoherent patients, detect critical cardia conditions in real time and transmit actionable insights to hospital before arrival enabling immediate treatment including invasive interventions if needed. 

Developing this application was not just a product. It was a medical device ecosystem operating under clinical, technical, regulatory, and ethical constraints. I found out that everyone was competent and were knowledgeable but not everyone spoke the same language. Medical experts dominated the dialog about the criticality while engineers optimized the solution prematurely. Neither factored the regulatory risks until those members were specifically engaged. So, it was apparent to me that the 'unknown unknown' stayed unspoken sometimes due to the deference to the sensitivity or criticality of impact. 

Here is where I used the Nominal Group Technique (NGT). The goal was to get more breadth of features and risks to delivery without getting into the solution mode! I facilitated the interaction face-to-face in a combined setting using silent data generation (dot voting, brainstorming), undebated round-robin (brainwriting, Yes-And scenario writing), facilitated inter-group clarification (forming multiple teams of clinical, engineering, and regulatory members working together) to prioritize among diverse requirements. The advantage of this technique is that it is encouraged diverse participation and promoted consensus. It was not quick but picked up on many constraints, assumptions, risks, and dependencies. I particularly saw this NGT facilitation led to increased collaboration. For example: 

• Clinicians highlighted most critical ECG patterns to focus on such as ventricular fibrillation, elevated myocardial infarction and a few others
• Engineers emphasized battery drain and securing against signal interference risks
• Designers questioned about the ambulatory users to design for stability and UX considerations when first responders were operating in a stressful environment with gloves and moving vehicles
• Compliance specialists named medical, legal, and regulatory considerations for approval

Obviously, NGT didn't give us all the answers but it shaped the product needs better leading to the prioritization of minimum viable product. We diverged first across the problem space before converging on solution space. But, as the solution began taking space with more people involved, I found some began identifying requirements soon after the meetings were over. I found that dominant personalities in the room or the absence of anonymity were challenging for people to speak up in these facilitated settings. Here is where I found the Delphi technique come to the rescue.

The Delphi technique required people to raise their concerns in anonymous surveys and questionnaires. These surveys and questionnaire required careful design to avoid double-barred and leading questions but focused on identifying those risks across the lifecycle, regulatory and ethical edge cases, and most importantly the assumptions people were willing to challenge anonymously but not publicly. I would say that the anonymity brought known unknowns and unknown knows.  Designing the survey and questionnaire took time working with expert sometimes to ensure they collected the qualitative and quantitative data correctly and working iteratively to understand some answers. 

The Delphi technique didn't remove disagreements when the new risks and challenges unidentified in public settings were brought up. But, it removed the fear of identifying them and the bias associated with group thinking. As the development of the solution emerged, the focus shifted to ensuring that our solutions were built in such a way it maximized the regulatory approval and learning from the piloted first responders. Here is where I found the Wideband Delphi helpful. 

The Wideband Delphi is a hybrid technique. It combined the best of both the NGT and the Delphi technique. No longer was the focus on diverging to understand the problem space and converging to focus on solutions! No longer was the focus on power imbalances or biased interpretations leading to further risks as all the team members were in a 'performing' stage! But, as first responders identifying needs such as the UX needs to be simpler (fewer bigger buttons to click rather than nested menus) and iterative regulatory focus emerged (agreements on the details behind the ECG patterns), a mini Delphi approach to product backlog (missed documentation, design considerations) from experts along with a discussion to prioritize and estimate them followed. The planning poker and PERT are all Wideband Delphi techniques to facilitate them in a light-weight setting.  

It was wonderful to retrace my earlier product development experience to reconnect with these techniques on how we need to unearth risks. All these techniques have been time-tested and practiced in various settings whether or not we know them by their names! But, ignoring their benefits and thinking silent consensus is team alignment is not acknowledging the elephant in the room. 

The person I was coaching felt very grounded and satisfied. What do you think? What other techniques have you used or benefitted from?

When Risk Materializes at 35,000 Feet: A Lesson in Contingency, Leadership, and Empathy

Late last week, I was traveling from Mumbai to Ahmedabad, expecting a routine landing around 8:30 pm. Instead, nature had other plans. Severe lightning, heavy thunderstorms, and unsafe landing conditions meant our aircraft attempted to land three times and then made the only responsible decision left: divert to one of the nearest viable airport, Surat. This was not a hypothetical risk. This was risk materializing in real time.

To add to the emotional backdrop, Ahmedabad had recently witnessed a tragic Air India crash that killed almost everyone on board except one survivor. That reality was not lost on many of us sitting in that aircraft. As the pilot announced this diversion, I was talking with people near my seat where some were calm but afraid what would happen to the flight!

Once we landed in Surat, we were asked to remain seated on the tarmac while authorities coordinated next steps. The pilot stepped out of the cockpit and addressed us directly—calm, composed, and transparent. He explained that the risks avoided by not forcing a landing, the air traffic and safety regulations that prohibit deplaning without clearance, and their immediate next steps to identify safe and lawful alternatives before moving passengers. The pilot further announced that refreshments are being ordered from Surat to serve in the cabin as soon as possible and if anyone had further connecting flights that he was willing to talk with the authorities to evaluate options. 

This is a textbook example of risk response planning. As the primary risk of not landing in the destination city became an issue, the secondary risks were identified and analyzed working within the constraints of safety for all. And yet—this is where things started to unravel when risk management meets human behavior. 

As announcements continued, emotions in the cabin escalated.

• People began raising their voices (raising is put mildly here).
• Many formed informal lines in the aisle inside the aircraft inconveniencing others.
• Others demanded to deplane because they “had friends in Surat.”
• A few insisted this was the airline’s “fault” and demanded vouchers.
• One passenger demanded that their checked-in luggage be retrieved immediately—on the tarmac because their Uber would be coming soon (what, to the tarmac?)

The emotional intelligence of this pilot operating under this pressure was commendable! He was patiently addressing that he was still working with the air traffic control (ATC) authorities as the opportunity to take off to Ahmedabad was very likely as the weather storm will clear soon. He emphasized that situation is still fluid and that the flight is officially not yet cancelled and no one can be deplaned unless there is a medical emergency or he got ATC confirmation.  

As if he jinxed the situation, he got on the call and quickly announced that another diverted aircraft had a medical emergency, requiring a passenger to be deplaned for urgent treatment. He said that the refreshments are on the way but the medical emergency is being prioritized. It created another uproar between the passengers where some complained that why someone can deplane in another plane but they can't deplane from this plane! Others were answering in their own words which part of the medical emergency they didn't understand! 

Amidst this chaos, the most surreal moment of all happened! I saw a few teenagers and adults pushing forward to take selfies with the pilot and airhostess. Really! It was disheartening to see safety and empathy deprioritized over social media hype! In that moment, I wasn’t just witnessing travel frustration. I was witnessing a complete breakdown in understanding how people break the systems under stress.

Here’s the uncomfortable truth: Most people are fine with processes until those processes inconvenience them. We celebrate safety protocols when they work quietly in the background as long as we are not impacted. We challenge them the moment they interfere with personal comfort, entitlement, or impatience.

What many failed to understand:

• Contingency plans are not personalized
• Exceptions are not scalable
• Safety decisions cannot be crowd-sourced mid-crisis
• Regulatory constraints are not negotiable based on emotion

In project management, product delivery, aviation, healthcare, crisis response or virtually any discipline or industry, the rule is the same:

"Once risk materializes, options narrow. Discipline increases. Flexibility decreases."

In that chaos, I also observed the pilot's leadership. I wish I had got his name but I didn't want to make things worse! He didn’t retreat behind the cockpit door; didn't lecture; didn't react emotionally to provocation. Instead, he patiently, politely, and assertively communicated what was known, clarified what was not yet possible, explained why safety and compliance came first, and remained empathetic without becoming authoritative. In my experience, great leaders don’t “cash in” on adversity. They rush to the front of the line and hold the line, even when it’s unpopular.

Everyone of us is also a leader! So, we need to practice leadership when adversity strikes us. Don't ever waste a risk! When an issue presents, practice the leadership hygiene on how to accommodate these contingencies that arise. Having only plan A is an unrealistic optimism. Having a plan B is a realistic professionalism. Knowing when to activate and respond to the issues that presents before us is leadership. Contingency and fallback plans exist precisely for moments when conditions change rapidly, emotions escalates, conflicts arise over individual preferences over group safety, and decisions are made with just-enough incomplete information! 

And yet, in corporate settings, I often hear:

• “Let’s cross that bridge when we come to it”
• “We’ll figure it out if it happens”
• “That’s an edge case”

Until it isn’t. This practice makes us complacent leaving us to react unempathetically!

The real lesson from that flight wasn’t about aviation but leadership. It is about how humans process and respond when the control is taken away! If you respond with entitlement, blame, or opportunism, then, there is a continuous improvement opportunity. Learn to respond with patience, practice situational awareness, trust/appreciate/respect other's people expertise, process guidelines, and systems in place for larger society. 

True leadership shows up not when things go as planned, but when they don’t.

That night, safety won. Process won. Calm leadership won. And while not everyone appreciated it in the moment, everyone benefited from it.

How do you relate to my interpretation of this experience? What other experience, similar to or different from mine, have you experienced? I am looking forward to hearing from you!

Resource Management: Stop Managing People-Start Managing Flow, Capacity, and Intent

I was fortunate to travel to Melbourne, Sydney, Manilla and India as part of my work discussing good practices using a specific SaaS product in product, project, and program management processes. The industries ranged from banking, investment, FinTech, defense, transportation, non-profit sectors, and healthcare. One of the things that kept resurfacing is managing resources. Those that were using adaptive approaches want to use the metrics to push the velocity. Others that were following plan driven approaches thought of the people's unutilized capacity meant productivity loss. At the program level, people reasoned that all resources are interchangeable that they can be moved from one team to another across the projects in the program! 

I feel that rushing to use some metrics to measure resource utilization may also lead to failures. Resource management is not about people shortage or utilization of people's time. In fact, the resource management focus should be managing flow, capacity, and intent. So, let me elaborate with some examples. 

One team using an adaptive approach reasoned that the velocity was unstable and stories often spilled over to subsequent sprints. Their conclusion was that team members had maxed their available capacity! So, either new people have to be added or AI and automation must be factored.  I asked how much the backlog was ready with risks to delivery, clear definition of ready for pointing, and how much wiggle room for people existed for innovation and experimentation! The discussions led to the fact that features were big in the backlog without a clear articulation of value to the customer. So, the story points were not based on risks to delivery or a clear definition of done! Hypothetically, even if the team delivered 20% more, they were taking on technical debt - just enough to fill the velocity charts told the narrative the management wanted to see! How is the improved velocity valuable to the customer or business if the backlog was not ready? One important hidden lesson is that poor backlog readiness masquerades as a resource problem! 

Another plan-driven team used hours! Here, planning looked at number of people in the release, available hours/person between the start/end dates and made sure that everyone had 100% of the available capacity filled with tasks! In theory, great! But, the same team commented that the challenges were the work delivered had more defects and incorrect documentation for the users. Follow-up discussions pointed to inadequate time understanding the collaboration on the work (assumptions were made and assumption analysis was done) and metrics on number of defects logged/closed meant the increased defect density (defects/requirement) was demotivating! So, does utilization mean quality delivery?   

I always emphasize that we should measure what matters! This applies to resource management too as we shift focus on flow, capacity, and intent. For instance, we should come up with good leading indicators during release/phase or iteration/sprint planning to see how ready we are to maximize flow, utilize capacity, and improve intent. Here are some good resource management metrics to support this approach. 

Measure	Description	Impact	Steps
Backlog Readiness Index	% of upcoming backlog items meeting DoR	If this is low, it means: Story spillover Sprint churn Scrap/Rework	Define DoR (clear AC, risks, responses) Review next 1-2 sprints of backlog Count items meeting DoR (A) Count Total items reviewed in planning (B) Compute A/B
Capacity vs Demand Ratio	Comparison between available team capacity and planned demand	If this is high, it means Overcommitment Under estimation Team Burnout Low Quality	Calculate team capacity (days or points)(A) Sum planned work effort(B) Compute Demand(B)/Capacity(A) (Closer to 1, higher the risk)
Resource Availability Rate	% of actual time available for planned work	If this is low, it means: High context switching Hidden operational work Inadequate planning	Identify capacity (A) Subtract meetings, support, shared work (Good practice is to allocate 20%-30% for these things) (B) Compute Available Time (B)/Capacity (A)
Unplanned Work Ratio	Portion of work that entered the sprint after planning	If this is high, it means: Unstable Delivery Discovery Delay Weak Decision-Making (This may be either upstream or downstream issues)	Track work added mid-sprint Compare effort vs planned work Express as %
Technical Debt Accrual Rate	Rate at which new technical debt is accruing	If this is high, it often means: Declining throughput Delayed Design Issues Disappointed Clients	Tag unclosed items/release Track debt/release Project trend over time

At the end of the release, phase, iteration, or sprint review, measure delivery performance using lagging indicators. These includes time-to-market, defect density, feature adoption, schedule/cost variance (part of earned value management), and team's throughput. There are various other KPIs that can be used based on the industry, team maturity, product life cycle stage, etc. 

It is important to avoid some anti-patterns when measuring flow, capacity and intent. Some of the obvious patterns are around treating backlog readiness as paperwork exercise without truly spending time on it, planning releases with 100% capacity, ignoring unplanned work exceptions, accumulating technical debt without increased visibility, and measuring outcomes without tracking leading signals. 

Furthermore, more subtle anti-patterns exist too. These are: 

• Treating DoR should not be treated as optional in the backlog to continue going faster. That only creates drift more than agility. 
• Assuming shared resources will self-manage context switch within and across products.
• Failing to adequately factor unplanned operational support work
• Focusing on features and tracking defects without tracking the debt creation and customer value loss
• Reviewing and addressing lagging metrics without focusing on prevention costs (Think CoQ)

What are your thoughts around this concept resource management at the product level? I am looking forward to your ideas. 

 

When “Team Harmony” Becomes the Problem: A Scrum Master Coaching Moment

 A Scrum Master I was tutoring came to me visibly frustrated.

“I think I need to push the team harder. They’ve become too comfortable. Everything is consensus-driven. Velocity is flat. Technical debt keeps growing. Stories keep rolling over. And now bugs are showing up because the Product Owner doesn’t give enough clarity.”

On the surface, this sounded familiar. Many leaders respond to this by tightening controls, adding pressure, or redefining accountability. But instead of jumping to how to push the team, I asked a different question:

“Why do you believe pushing the team is the right answer?”

That question changed the conversation. As we unpacked the situation, a pattern emerged. The team wasn’t lacking effort, intelligence, or intent. From the discussions, I felt that they were highly cooperative, polite, and aligned. At the least, they appeared to be. The emerging patterns were that the decisions were rarely challenged, estimates were accepted without debate, and risks never surfaced clearly. The Scrum Master was experiencing wasn’t laziness. It was group comfort. That’s when I introduced a concept from Japanese lean organizational culture: Mura Shakai (pronounced moo-rah-shah-kah-ee)

Mura Shakai is a cultural pattern often called as the 'village effect.' Contrary to the collaborative self-organized team's effort where the team drives to excel, this pattern is analogous to the collectivist's approach to respecting harmony and conformity where people avoid standing out because of the social risk it carries. The very fact that no risks surfaced or questions emerged on estimates or decisions mean that no individual wants to 'rock the boat!' 

I reasoned that people confuse agility thinking that asking powerful challenging questions or raising risks disrupt psychological safety! On the contrary, psychological safety does not mandate the absence of conflict but the presence of constructive disagreement. In our example case, the misunderstanding of avoiding conflict meant that all the observed challenges (stagnant velocity, rising technical debt, shifting stories, and PO blamed for bugs) were being socially filtered before they were truly visible. 

This microcosm of collectivist group thinking needs to be carefully addressed not by pointing fingers. So, pushing people hard would be a counter-productive move as it will only create more dissent, people gravitate more towards their zone, and defend their practices. Per the Speed Leas' (1985) conflict model, we are in level 3 - contest at a minimum.

Now that we had a better understanding of the actual problem, I introduced the A3 technique. The attention to detail, quick-win mentality, and connections one slide business canvas model has made this technique to be an easy solution to solve problem. A3 is a thinking discipline (similar deBono hats, for instance) applied at the team level forcing them to slow down, face the reality, and confront the uncomfortable issues collectively. So, how does this approach work?  

1. A3 approach starts with reframing the problem! So, instead of telling the team is slow, I suggested stating, "stories are rescoped in mid-sprint", "work carries forward in multiple sprints" or "defects are discovered too late in the life cycle." Now, none of these statements are new to them but brings context into the problem. 
2. The next step is to understand the impact on the current state. This is the "Go and See" approach also called as the Gembutsu (Rajagopalan, 2024). The goal here would be understand the impact of the reframed problem statements. Asking ourselves, "Where does this ambiguity come from?, How does this technical debt slow us down later? When does the team recognize this risk and why was it not raised?" I also cautioned the Scrum Master to practice active listening. 
3. The next step is to perform root-cause analysis.  Ishikawa diagram, 5-Why, Influence Diagram, and many other techniques exist. The focus is two-fold. Not only identify the root causes but also identify potential set of solutions.
4. The final step is to identify the action items on what can be changed. Suggest and coach but not direct action items, I emphasized. Once they identify the action items, owners, and the related changes, make them visible from the next iteration creating accountability!

I concluded the session recalling that Mura Shakai favors harmony and sometimes hides a team dysfunction. A3 technique reminds us to be structured about unearthing the dysfunction to the team and make accountability visible to the team.

References

Leas, S. B. (1985). Discover your conflict management style. Alban Institute.    

Rajagopalan, S. (2024). Quality Responsibility: 5G of Quality Audit. https://agilesriram.blogspot.com/2024/08/quality-responsibility-5g-of-quality.html

Playing the CARD at Scale: Lessons from a Global Strategic Business Office

An opportunity presented itself for me to reflect on a mental model that I had developed a long time back. I had relied on this model to proactively sow the success seeds for any initiative that I worked on and also reactively address challenges as they surfaced. The opportunity came when I had a good friend who discussed with me about supply chain related failures for a drug portfolio where decision-making delays created strategic and operational challenges for a mid-level healthcare organization. 

While some early thoughts focused on teams lacking the capacity and capability, I didn't feel completely convinced. Over the years, as a VP leading a PMO with many project and program managers reporting under me, I noticed a recurring pattern: projects rarely failed because teams lacked effort or intelligence. They struggled because the realities of execution were not made explicit early enough. To address this, I often used a simple but powerful mental model called CARD—Constraints, Assumptions, Risks, and Dependencies. Like a card in your pocket, it is something every mid-level manager should carry into planning conversations, steering committees, and day-to-day decision-making.

My thinking around CARD further matured significantly as my role evolved into VP of a Global Strategic Business Office (GSBO), where the PMO increasingly became a shared services capability rather than a standalone function. One arm of the GSBO focused on client-driven delivery programs, while the other governed the internal product and R&D portfolio across the organization. In this dual mandate—external execution and internal innovation—CARD became a pivotal enabler, helping us navigate strategy over a three-year horizon while still executing tactically at the project level.

Constraints are the non-negotiables of an initiative and strong managers surface them early and often. They act like the skeletal system defining the shape, structure, and boundary limits. The organization fails without the skeletal system and too much rigidity compromises agility. Beyond traditional limits like budget and timelines, constraints on a strategic side included leadership capacity, market timing, regulatory environments, and investment guardrails across portfolios. For client-driven programs, constraints were often contractual and immovable; for product and R&D initiatives, constraints showed up as funding thresholds, architectural decisions, or talent availability. 

In my GSBO initiatives, CARD helped ensure that constraints were explicitly acknowledged at the portfolio level, so teams didn’t overcommit locally and underdeliver globally. When surfaced early, constraints became tools for prioritization rather than excuses for delay. Every trade-off such as scope reduction, sequencing, and resourcing must explicitly reference which constraint is being protected. When constraints are invisible, teams make local optimizations that create global failure. Making constraints explicit creates realism, not pessimism.

Assumptions are where many plans quietly go wrong. These are statements we treat as true without proof. I view the assumptions as the nervous system and determines how the organization perceives the market and reacts to the signals. I found the assumptions were where the CARD created the most leverage especially in product and innovation work. Multi-year roadmaps are built on assumptions about customer adoption, technology maturity, data readiness, and organizational change. In the GSBO, we treated assumptions as testable hypotheses, particularly for R&D experiments embedded within the portfolio. 

Product managers and business analysts or the project and program managers were expected to articulate what must be true for success and define signals (triggers) that would invalidate those assumptions. Unchecked assumptions turn into surprise risks and surfaced assumptions turn into managed conversations. This discipline allowed leadership to course-correct portfolios early rather than defending plans that no longer matched reality.

Risks spanned both execution and strategy and provided the highest value in the GSBO. In fact, risks were the main thread that connects projects, programs, and portfolios in any enterprise. Risks differ from constraints and assumptions in that they are probabilistic events with a positive or negative impact! 

• At the project level, risks were treated within the project's threshold but escalated when their cumulative and overall impacts exceeded the project boundary. 
• At the program level, risks included benefit slippage, vendor reliability, and integration complexity.  The program level risks also were delegated to project level as needed. 
• At the portfolio level, risks expanded to include concentration risk, innovation failure, market shifts, and opportunity cost. 

CARD helped management elevate the right risks that genuinely threatened strategic outcomes. More importantly, it encouraged explicit risk ownership and leadership decisions about which risks to mitigate/enhance, transfer/share, avoid/exploit, and finally which risks to consciously accept.

Dependencies were the connective tissue of the GSBO and are frequently the most underestimated element of CARD. Client programs depended on internal product roadmaps; product initiatives depended on shared platforms, data, and specialized skills; R&D experiments depended on leadership patience and protected funding. In my opinion, projects do not fail in isolation but across the integration points between teams, vendors, stakeholders, and systems. 

CARD forced visibility into these interdependencies and prevented siloed decision-making. For project and program managers, managing dependencies became less about tracking dates and more about orchestrating conversations, aligning incentives, and escalating decisively when assumptions broke down. It forced us to ask hard questions: Who do we rely on? Who relies on us? What happens if this slips?

CARD Element	Body Metaphor	Leadership Connection
Constraints	Skeletal	Structure, System, Boundary, Leverage
Assumptions	Nervous	Interpretation, Signals, relexive decision-making
Risks	Circulatory	Awareness, Escalation, Flow
Dependencies	Connective	Alignment, Integration, Cohesion

Finally, CARD works because it forces clarity. Just like bad strategy may result from rigid bones and faulty nerves, execution can fail because of weak connective tissue and blocked circulation. So, constraints shape choices, assumptions test logic, risks demand foresight, and dependencies expose interconnections. When the management and leadership consistently apply CARD, status conversations become sharper, surprises decrease, and leadership trust increases. 

In my experience, you don’t need more templates or tools—just the discipline to play your CARD well, every time. What are your thoughts? How have you applied any of these thoughts? Please share your insights.

Relocating Experience: A Real-Life Lesson in Fisher & Ury’s Negotiation Principles

I have lived in the cold-weather belt of the United States for a long time. Once school-related constraints for our children eased, our long-standing dream of relocating became more urgent. We had explored towns across multiple states for years, but in early 2025, the decision solidified: relocate from Boston to Dallas by the end of April.

This single decision triggered a cascade of negotiations—with my wife, children, employers, a realtor, neighbors who are like family, lenders, inspectors, attorneys, insurance companies, our landlord, the homeowners’ association, and relocation movers. With an aggressive 90-day window to find a home or abandon the move altogether, emotions and time pressure were real. Looking back, I realized how deeply Fisher and Ury’s (1981) negotiation principles shaped both our personal and professional interactions—often without us consciously naming them.

1. Separate the People from the Problem

Coordinating travel for house-hunting quickly became emotional. One son wanted to participate actively, the other was neutral. My wife had work constraints; my role was largely remote. Our realtor strongly recommended that both my wife and I travel together for weekend visits. Frustration surfaced quickly: comments like “You’re being inflexible” or “What’s the point of you coming?” began to creep in.

Instead of letting this become personal, we reframed the problem as a scheduling and logistics challenge—not a commitment issue. We explored late-night travel, inexpensive hotels farther from target neighborhoods, and tightly packed viewing schedules. By acknowledging constraints rather than assigning blame, we preserved trust and opened up workable options.

2. Focus on Interests, Not Positions

Positions were clear: who had to travel, who couldn’t, and how much time we had. Interests were deeper: inclusion, learning, health concerns, cost, and quality family time. One son was willing to rely on video walkthroughs; I wanted him involved as a learning experience. My younger son preferred an uninterrupted summer break.

Our realtor played a critical role here. She filtered homes based on unstated interests—including allergies and lifestyle needs—and pushed early conversations with banks because time, not indecision, was our biggest risk. While it felt premature at times, aligning around interests rather than rigid positions helped us move faster with fewer regrets.

3. Invent Options for Mutual Gain

When a promising house from the first trip fell through, our realtor suggested another visit the very next weekend—something none of us had planned for. Work schedules, travel fatigue, and prior commitments collided. Walking away was tempting.

Instead, we invented options. We shifted travel days, adjusted work commitments, relied on video participation, and leaned on a close neighbor to cover personal obligations. Even our realtor adjusted around her prior commitments. What made this work was a shared focus on the collective objective—successful relocation—rather than individual convenience. This was win-win thinking in action.

4. Insist on Objective Criteria

Once we identified the right house, negotiations intensified—offer price, inspection outcomes, mortgage rates, insurance, and legal reviews. Here, objective criteria anchored every decision. Market data, expert inspections, lender benchmarks, and legal guidance replaced assumptions and emotions. Credit is due largely to our realtor, who consistently grounded discussions in facts rather than pressure or opinion.

5. Know Your BATNA

All of these principles ultimately converged on one critical discipline: knowing when to walk away. Our BATNA was explicit—if we could not find an affordable home and close within 90 days, we would exit the relocation altogether. Having clear exit criteria prevented emotional escalation and preserved relationships, even when discussions became tense. As I often emphasize elsewhere, if stop conditions are unclear, negotiations drift—and often fail (Rajagopalan, 2025).

I am sure all of us encounter similar negotiation opportunities to reflect. What comes to your mind? Please share your thoughts.

References

Fisher, R. and Ury, W. (1981) William Ury. Getting to Yes: Negotiating agreement without giving in. 3rd ed. New York: Penguin Books.

Rajagopalan, S. (2016). Agility in Negotiation: Focusing on the “Why” behind mixing strategy with scenario. https://agilesriram.blogspot.com/2016/03/agility-in-negotiation-focusing-on-why.html

Rajagopalan, S. (2025). SEED: Understanding the warning triggers for failures. https://agilesriram.blogspot.com/2025/04/seed-understanding-warning-triggers-for.html

SEED: Understanding the warning triggers for failures

I was facilitating a leadership course focusing on organizational transformation at Northeastern University! Learners came from Human Resources, Project Management, Informatics, and Leadership concentrations. In one of the discussions related to reasons for organizational failures, learners discussed initiatives failed because because of poor market research, management myopia, process overhead, ethical oversight and overreliance on technology instead of people. When I asked a few follow-up questions related to the reason for these failures, everyone narrowed in on bad strategy! 

How could strategy by itself fail? After all, strategy is to create a "competitive advantage" and failure lies in people not paying attention to the warning triggers and make the required course corrections! So, I explained to the learners the thoughts behind what I call as SEED warning triggers. This is an approach I developed over a period when managing the Program Management Office working with C-Suite directly and clients delivering numerous programs supporting a few portfolios. 

Success Measure: An organization is like a big family taking care of members of the family. Some family members may be children while others adults. What makes one happy may not make others happy as everyone has specific goals and objectives. If organization is a family, every member's longer term needs are like the organizational initiatives.  Most initiatives focus on achieving specific goals and objectives. So, this is frequently one of the things people identify in various documents, such as the business case, benefit management plan, benefit register, project charter, etc. Some metric driven organizations may have specific objectives & key results (OKR) to evaluate interim progress as well that are used in the governance framework to prioritize and optimize initiatives aligned to the enterprise environmental factors and related resource management needs as well.

Entry Consideration:  An organization is a living entity with every portfolio, program, and product a healthy organ working holistically to sustain life. It is therefore important to have interim reviews to evaluate the level of success achieved until then and reevaluate what initiatives should continue moving forward. Even a successful initiative that has met all the criteria may be parked for a different initiative because of the external and internal events. So, it is always better to have predefined milestones (it could be functionality or schedule based) to evaluate if the initiative should continue to enter its next phase based on its own success criteria met. 

Exit Criteria: One of the major challenges with any initiative is failing to understand, recognize, and act on exit criteria. In my humble opinion, this is one of the main warning triggers people ignore. If one's lifestyle changes causes an unhealthy situation (e.g.: prolonger exposure to construction work causes hearing loss, longer commutes to work causing family imbalance, toxic work environment causing increased stress), then, one has to make lifestyle changes which may sometimes involve looking for options (e.g.: a different role in the company, remote work options, an alternative job) to exit from the current challenges. Similar logic applies in a portfolio, program, or project where we should first have the exit criteria and monitor the warning signs to determine when it is time to "STOP." Continuing to do the same thing expecting different results is not smartness!

Decision Delay: This is the final and more challenging issue. Even when one knows that the heredity may have possible diabetes, people follow specific lifestyle (eating sugary foods) leading to diabetes diagnosis. Despite the diagnosis, they don't exit the current lifestyle options creating more challenges for their family members. Their reason is delaying the decision to act on the earlier warning signals. This delayed decision-making is the cancer that kills all the initiatives. When products delay customers' requests for newer functionality for a long time, for example, customers are dissatisfied (relate to Kano model here). When portfolios defer rebalancing the initiatives or reskill the employees and programs delegate program level risks constituent project sustaining benefits, such delays seal the failure of any initiative. This is where the skilled and timely governance really matters!

So, in the end, my SEED triggers are example of things that leaders should constantly monitor and manage. Otherwise, failures are just accidents waiting to happen. I felt some learners in the class felt thrilled to learn about this experiential approach. What are your thoughts? Please share.