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.
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
No comments:
Post a Comment