AI in Agile: Are You Innovating or Just Automating Mistakes?

AI in Agile: Racing Faster… But in the Wrong Direction? A few months ago, I was invited to observe how AI was being integrated into a Fortune 100 company’s operations. When I walked into the conference room, the whiteboards were covered—flowcharts, decision trees, AI integration plans, pages upon pages of automation roadmaps. The team was waiting for me to be impressed. “What do you think?” one of the senior engineers asked, expecting validation. I looked around, scanning the intricate maze of diagrams. Then, I said the only thing that came to mind: “I think you’re missing the whole point.” “What do you mean, Amit?” “Tell me, where will AI give the most value? In automation, or in helping us explore how to optimize?” Silence. A few nervous chuckles. But they knew exactly what I meant.They had mapped their existing world in painful detail. Not once had they asked whether that world even needed to exist. That’s the problem with how most organizations are approaching AI today. They assume faster means better. But AI applied to an inefficient process does not create innovation—it just scales inefficiency at an exponential rate. Turbocharging Bad Decisions: The AI Pitfall Agile Teams Ignore Most organizations are not innovating with AI—they’re just automating old inefficiencies. It’s the corporate equivalent of turbocharging bad decisions—using cutting-edge tools to speed up a flawed process instead of rethinking if that process even needs to exist. This is exactly what I saw in the Fortune 100 company I worked with. They were obsessed with automating their call support workflows as quickly as possible. But in their rush, no one stopped to ask: It took one conversation—one heated debate among their tech team—to uncover the real problem. They weren’t using AI to innovate; they were using it to copy-paste inefficiencies at scale.And that’s the real danger. The illusion of progress.If you take a broken, outdated process and use AI to make it move faster, what will you really achieve?Not much. You’ve automated waste. AI Shouldn’t Follow Rules—It Should Challenge Them Don’t use AI to replicate human inefficiencies at scale—use AI to challenge them. But that requires a mindset shift: This is exactly what was happening at this fortune 100 company. Once we stopped treating AI as a mere accelerator and started using it as a partner that could analyse, something changed. Instead of blindly automating all workflows, the company re-engineered AI to analyze processes first, detect redundancies, and flag unnecessary steps. Instead of scaling inefficiencies, they were now systematically removing them. Here’s what we did differently: The impact was clear: AI didn’t just automate work—it helped redesign how work happens. If AI Isn’t Challenging You, You’re Using It Wrong AI is a force multiplier. But what are you multiplying? Are you scaling efficiency, or are you scaling waste? Most companies get caught in the automation trap—pushing AI to move faster without stopping to ask: Is this even the right direction? I believe AI in Agile should be more than just a fancy speed boost—it should be a thought partner. It should tell us: If your AI isn’t challenging you, you’re not using it right.So, before you invest in AI, ask yourself one hard question:Are you using AI to transform work? ORAre you just making bad decisions… faster? Share your experience! Have you seen AI used to redefine work, or just to replicate it? Drop a comment—I’d love to hear your thoughts. Amitabh Sinha (Amit) is a trusted Agile transformation expert and AI strategist, known for helping organizations cut through the hype and unlock real, tangible value from Agile and AI. With decades of experience as a software engineer, Agile coach, and product leader, he brings a deep technical understanding and a practical, no-nonsense approach to driving meaningful change. Amit and his team help companies “adopt AI in Agile”—by ensuring they integrate it the right way. Connect with Amit for tailored, high-impact solutions that actually work.

Agile everywhere: transforming non-IT teams for greater value delivery

Agile Everywhere: Transforming Non-IT Teams for Greater Value Delivery

Agile was born in the world of software development, but its values and principles extend far beyond coding. Despite this, many people still believe, “Agile is only for IT.” It’s a mindset that has kept countless non-IT teams from exploring its transformative potential. Agile is not just about frameworks or ceremonies. It’s for delivering value, nurturing collaboration, and continuously improving. When applied thoughtfully, it can empower any team—documentation, sales, research, or beyond—to work better together and deliver meaningful results. Let me share what I’ve learned about overcoming challenges and bringing Agile to life in non-IT teams. Agile in Non-IT Departments: Common Challenges Mindset BarriersIt’s no surprise that non-IT teams often hesitate to adopt Agile. I’ve seen this hesitation firsthand. The central documentation group at a large enterprise once asked me, “What do we need to do to become the best Scrum team?” My answer was simple: “Why Scrum?” Scrum comes with its own set of overheads – events and structures, and Agile should not be about blindly following a framework. Instead, we stripped it down to what mattered most: By focusing on these fundamentals, the team found their rhythm. They didn’t need ceremonies for the sake of ceremonies—they needed clarity, collaboration, and alignment. Seeing their transformation reaffirmed for me that Agile is about principles, not labels. Siloed Work PracticesSilos are a killer for collaboration. I’ve seen this play out with a biomedical sales team I worked with. At the start, the team was simply set up to fail: It was chaos. The team’s struggles weren’t about “bad Agile.” They were trying to fit Agile into their silos instead of using Agile to break them down. We started by splitting the group into three smaller Scrum teams. Everyone came together to create working agreements, and I worked closely with the Product Owners to help them write simpler, more valuable stories. Slowly, the blame game between developers and POs started fading. It wasn’t an overnight change, but as people began turning their cameras on during meetings, I saw trust growing. By the time the teams hit their stride, they were collaborating like never before—and their delivery reflected it. Resistance to ChangeChange is hard, especially for teams rooted in traditional ways of working. When I worked with a group of research scientists, I saw this resistance play out in full force. Senior researchers were hesitant to share their work openly. Ego and trust issues created a wall that prevented true collaboration. We began small: standups three times a week, focusing on pairing researchers to tackle key problems. The early days weren’t easy. Conversations were guarded, and progress was slow. But with time, things started shifting. Refinement sessions became powerful, timeboxed discussions. Outcomes—not just outputs—began driving their reviews. Three months later, this team that once doubted Agile was running daily standups and solving problems together. I’ll never forget the moment one senior researcher admitted, “This is the first time I’ve felt like part of a team.” Moments like that remind me why Agile isn’t just a methodology—it’s a mindset shift that impacts behaviors and culture by establishing the human connection. Adapting Agile Values for Non-IT TeamsAgile is not a one-size-fits-all solution, but its values can be adapted to fit any team’s unique challenges. Here’s how you can start: When non-IT teams embrace these principles, they unlock the flexibility and focus they need to thrive. Conclusion Agile doesn’t belong to IT—it belongs to anyone willing to embrace its values. Whether you’re in sales, research, or documentation and beyond, Agile can transform the way you work, connect, and deliver. What’s holding your team back from trying Agile? Share your biggest challenges—I’d love to hear how you’re making it work in your world. Please connect with us to help onboard your non-IT teams to Agile. This post combines the author’s personal thoughts, ideas, and experiences, with some refinement provided by our Agile Bot AgiNomi.

Navigating the Rough Waters of Agile Offshore Teams: A Coach’s Playbook

Intro: The Uncharted Waters of Agile Transformation Agile is no longer the new kid on the block. Over the past two decades, it’s been around the block, through the maze, and even found its way into traditional, non-tech sectors. But despite its widespread application, one thing that’s rarely talked about is how Agile fits with offshore remote teams. Businesses are heading toward this model in droves, and yet we’re still stuck on Agile playbooks that advocate for co-location. So, let’s cut to the chase: How do we make Agile work in this complex offshore maze? A Story Worth Telling: The Offshore Abyss Let’s walk through a common war story.  You’re working with a client in the Midwest, running a Scrum team that’s a cocktail of cultures and time zones. You have folks in India, Argentina, and Romania. Right off the bat, your Scrum Master is struggling. The offshore team members are shying away from the camera, creating a virtual barrier that’s hard to break down. These ‘invisible’ members find themselves swimming in their private ponds, disconnected from the team’s collective objectives. The Scrum Master looks like a helpless spectator, attempting to conduct Scrum events but never really achieving the cohesion Agile demands. The Elephant in the Room: When Time Zones Attack But what about another beast? The time zones. Forget the cultural barriers and organizational eccentricities for a second. The sheer lack of overlapping working hours between Romania and Argentina, and India and US for example, is a challenge of herculean proportions. Your daily standups turn into an uncomfortable juggle between the early mornings and late nights, and you struggle for more team time but know it can’t come without making someone less happy. More Than Just Cultural Gaps: The Silent Struggles And, then there are cultural nuances. Imagine having a Product Owner who’s a Westerner—outspoken, assertive, and always open for dialogue. Now pair this person with team members from India or Romania, where the culture might promote more subdued, less confrontational communication styles. You have a fertile ground for misunderstanding and missed opportunities. The Devil’s in the Details: Misaligned Metrics And let’s not forget, your offshore team members aren’t just juggling multiple tasks, they’re juggling multiple performance metrics. They have their managers and KPIs to answer to, which often don’t align with Agile methodologies. It’s not their fault, but it’s a hurdle, nonetheless. The Way Out: Strategies that Actually Work So, how did we overcome these challenges in our war story? First, I pulled everyone back to the basics—to the ‘Why’ of Agile. With regular training sessions, we rehashed the essence and importance of every Agile ceremony. When team members understand why they are doing what they’re doing, the ‘how’ becomes easier. It adds a layer of respect and purpose to daily stand-ups and retrospectives. For the Scrum Masters in the room, it’s time to embrace the essence of Servant Leadership fully. No longer can they afford to be mere facilitators; they must be leaders who command respect and are capable of guiding their troops through the Agile labyrinth. This starts with equipping them to have tough conversations, even with the vendor managers of their offshore team members. The key is intimacy. I advised Scrum Masters to conduct more targeted one-on-ones with their team members. If you want to break down barriers, start by building bridges. Forging individual relationships can provide team members the safety to voice out their challenges and concerns, be it time zones or vendor metrics. Avoiding the Pitfalls: Lessons from the Trenches If you’re a leader navigating these waters, remember that Agile doesn’t just ask for co-located teams; it demands small and stable teams. Offshore or not, team members are humans, not resources. Moving them around like chess pieces can severely destabilize your Agile practices. Another pitfall is stretching your Scrum Master too thin. Serving two teams filled with offshore members from multiple time zones is a recipe for burnout and inefficiency. Take this off their plate. Make it an organizational concern. Conclusion: Doing Agile Right—Anywhere, Everywhere To be clear, there’s nothing inherently wrong with having offshore team members in Agile teams. It’s the lack of aligned practices and the underestimation of the complexities involved that trip us up. We’re writing the rulebook as we go along, but one thing is crystal clear: Agile can be successfully implemented in remote, offshore settings. It takes a village of committed leaders, empowered Scrum Masters, and engaged team members. Guidelines and working agreements must be in place with clear expectations that all parties agree and adhere to. Otherwise, the complexity of it all will weigh too heavy for Agile to start rolling smoothly.

Jobs To Be Done vs User Story Maps – 1

This part – 1 of the article explains situations that arise due to lack of ownership for journey mapping exercises. Who should own them?, why should they be done? Etc. The part – 2 of the article discusses in depth the Jobs To Be Done vs. User Story Maps – 2 Part-1 While helping clients with Agile transformation, I focus on a few important aspects, which are outlined below: It is with respect to this last point #4, I often introduce journey (aka user story) mapping concepts and workshops to the leadership. It is usually received with mixed response, and although, people love the workshop, they need some hand holding to get started onto this. We eventually get the product owners to own this and work with a small group of engineering and design leads to get the high level maps in place, which eventually results into exploring deeper area maps (remember: maps, contain maps, contain maps…) that are owned by individual teams as they try to build a shared understanding for the features or products they are responsible for. I also saw resistance from Product Owners to drive the creation of journey maps citing that they already created a PRD (Product Requirement Document) and since it’s all clear in their minds, they failed to understand why it is difficult for engineering and design teams to align with their thinking. The engineering team, on the other hand, complained that the product only provides a document or a one-liner explanation for critical items, and they have to interpret the details on their own. The design teams tended to side with engineering in not having a clear understanding of assumptions made by the product team. Moreover, the design team decided to start driving the creation of the JTBD list involving members from engineering and product through discussions. Let’s distil the issues hidden in the above paragraph:  Firstly, written documents do not create a shared understanding. Writing such documents and making them the basis for alignment is the reason why so many of the products fail to delight the end users and customers, and as such, do not do well in the market. I wrote an article on this: The Problem with Requirement Specification Documents Secondly, Product Owners not wanting to own creating visual artifacts (JTBD, Journey Mapping, etc.) and being more in the role of a secondary observer/participant is quite puzzling. On inquiring a little, I found that the Product teams had bandwidth issues, were overwhelmed in learning a new concept and lacked belief in new ways of thinking to create a powerful version of their product that would highly differentiate them from their competitor’s offerings. This not only needs coaching to understand the value of such activities, but also a commitment from the product leadership to invest time in them. Thirdly, the product leadership failed to understand why their Product Owners should co-drive the journey maps? I asked a few questions:  They realized that missing POs during such journey mapping activity might not give them the desired outcome they want to see while delivering the product! Once this was resolved, the product leadership had two asks: In answer to the first question, I took them through a fun and hands on user story map session. It took around 90 minutes to facilitate this for a big group of 20 people. I have captured this into a 4-minute cartoon video that anyone can find handy. In answer to the second question: Please read the part 2 of this article Jobs To Be Done vs User Story Maps Amitabh (Amit) Sinha is a servant leader entrepreneur, visionary, mentor, trainer and coach. Amit is highly passionate about Agile, its principles, values, and the human side. Amit is a people champion and strives to bring out the best in his teams. Amit leverages his expertise in Agile, Scrum, Kanban and people skills to increase team effectiveness and happiness. See more

Transform Your Team, Elevate Your Business!

Subscribe to the Agilonomics Newsletter and Claim Your Free Power Team Consultation Today!

We promise to keep your email address safe. You can check our Privacy Policy.

Thank you for subscribing to our Agile Wisdome - Weekly Tips!

You’re almost there! Please check your email and click the confirmation link to complete your subscription. If you don’t see the email, be sure to check your spam folder.

Privacy Overview

This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognizing you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.

Strictly Necessary Cookies

Strictly necessary cookies are enabled at all times so that our website can function optimally.

3rd Party Cookies

Our website uses Google Analytics to collect useful information. These cookies are used by us to build a profile of interest and show you relevant offers.

Keeping these cookies enabled helps us to improve our website and your experience.