Understanding Agile Methodologies in Tech

Scrum as a Service: When Agile Teams Become Ticket Processors Scrum as a Service is when Agile teams are execution units, taking orders instead of owning value delivery. They don’t solve problems; or shaping the product, they just code and close Jira issues. It’s what happens when companies adopt Scrum mechanically but keep traditional thinking and control structures intact. Symptoms of Scrum as a Service 1) No Product Ownership The PO is a backlog manager, not a decision-maker. Teams can’t challenge priorities. The backlog is a job assignment queue. Sprint Planning is a scheduling exercise, not a conversation about functional or technical trade-offs. 2) No Cross-Discipline Collaboration UX, DevOps, and Security exist outside the team, creating slow handoffs. Developers get fully fleshed-out requirements, not problems to solve. Agile teams are ticket processors, not value creators. 3) Nothing Changes Daily Scrums become status meetings for managers. Retros don’t lead to improvements, just performance reviews. Teams are judged by team outputs like velocity, not business outcomes. How This Happens 1) No Organizational Change Leadership keeps command and control, just renaming old roles. 2) Waterfall Thinking Teams have fixed scope and deadlines, no room for continuous discovery or progressive elaboration. 3) POs as Middlemen, Not Leaders POs relay stakeholder demands instead of shaping product strategy. 4) SMs are Managers. Not Coaches SMs push teams to move faster rather than helping them achieve a sustainable pace. How to Fix It 1) Give Teams Ownership Let teams define and prioritize their backlog. Facilitate direct feedback loops with users, not just stakeholder requests. Make POs strategic leaders, not order-takers. 2) Tear Down Silos Embed UX, DevOps, QA, and Security into the Scrum team. Stop treating devs as coders for hire. Make them coequal partners in product thinking. 3) Shift to Outcome Metrics Stop measuring success by velocity, throughput, or tickets. Track customer impact, retention, usability, and product adoption. Ask: Are we solving problems or just releasing code? 4) Decentralize Decision-Making Replace top-down roadmaps with team-driven prioritization. Let teams influence scope, trade-offs, and release planning. Encourage teams to experiment and innovate. 5) Foster Continuous Improvement Make retros actionable. Give teams time for technical excellence, like refactoring, automation, and innovation. Shift from feature delivery to sustainable, high-quality product development. From Execution Teams to Product Teams Scrum teams should be value creators, not feature factories. Agile is meant to empower teams, not turn them into Jira clerks. If teams can’t challenge priorities, shape solutions, adjust processes, or innovate, then you don’t have Agile. You have Scrum as a Service. Does your organization trust teams to own the product? If not, Scrum isn’t the problem. Your structure is.

The people who run Agile CoE's and Lean Agile Centers of Excellence have a difficult job balancing what is best for the organization. It may be tempting to scale up as much training as possible to educate everyone en masse. "if everyone just knew all the things... it'd be easier for the company to make progress being agile" ... It's also tempting to focus on leadership first. Senior leaders need to set the example. Say the right things. Reinforce the right behaviors. Put an end to older unhealthy behaviors. Teach middle managers how to support agile ways of working. And yet... this can take time. Because "we also need to build the value streams and figure out how we'll become a product-led organization and define the strategy" ... And it's more than tempting, but very popular to first work on "making teams awesome". Let's build up the scrum masters and product owners and get the teams to start working in an agile way before we "scale". By defining our agile point of view as a company, we can help those on teams feel more connected to our strategy and focus on value delivery not just the squeakiest wheels asking them to "build stuff" ... And yet ... if you've been on enough agile transformations you know there's something wrong with every single one of those three approaches. So what do you do? Every organization is different, so there's no clear answer. But what I can tell you is that you have to feel that out and find a way to create tight feedback loops so you can even think about possibly working on more than one of the three at a time. Just like learning to coach a single team we have to "meet them where they are"... Maybe the strategy should be to build a few model agile teams first. Educate *their* leaders so they're well supported. Build the training just in time as it's needed so this one corner of the organization has most of what it needs for your new model for success. Then evolve organically. Ask yourself frequently, "what would be the right best next thing to do NOW?" ... because it will inevitably change. And maybe very quickly. Consider the pushback in our industry on SAFe. Most coaches dislike it because it's misunderstood by executives, as if it's a defined roadmap to success... a way to "install agile at scale". (Nevermind the capital A capitalism) But even SAFe is not meant to be implemented all at once. Some of their success stories are "partial installs" at best. Companies need to decide what suits them. No single framework should be ever be absorbed and adopted wholesale, IMO. You have to think and know what you really need and why you need it. Maybe the right approach is something like the sentiments in the "Manifesto for Scaling Agility". A value based approach to adapting as you scale. Focus on building a shared understanding of the vision, organic growth over predefined structures, favor a high performing organization over any one team or part, and team empowerment up the chain over old policies. 🤷♂️ YMMV

Most organizations wait way too long to adopt portfolio-level agility practices. They’ve been told, “You can’t scale what’s broken,” so they wait until they nail agile at the team and product group level. What if fixing what’s broken REQUIRES focusing on the upstream that’s shaping the work and context of these teams?  Back in 2012 or so, I met an SVP responsible for a 1000-person delivery organization that was working in a traditional waterfall. Critical Chain optimized waterfall. But still. Component Teams. Heavy coordination and integration costs across multiple products. Build that takes 2 weeks to integrate. Riki and her team ran a very successful and profitable shop. However, they recognized that in order to satisfy their customers, they often had to accept change out of cycle, which created a constant fire drill. We discussed options. What Riki liked was starting with visualizing, understanding, and managing flow at the portfolio level, to break the waterfall. We got it going within weeks. (Did I mention Riki and the team were experienced, highly motivated operations-focused leaders? ). It didn’t take long for Flow times to start improving and for “Welcome Change” to be a more reasonable proposition. Over time, we’ve noticed how much “cross-product” work this portfolio delivered and started exploring ways to reorganize around value. We started introducing more and more agility principles and practices (eventually, they did reorganize to stream-aligned cross-product groups focused on the REAL product and leveraged team-level agile ways of working). Here’s the thing – Starting at the Portfolio level gives you, as a leader, tons of leverage to make an impact on the product-oriented agility of your organization – by tackling the systemic constraints to Product thinking, Flow, and Empiricism and allowing you to learn and model the behaviors you expect from your people. Yuval "Don't sleep on Portfolio Agility" Yeret

Agile is dead. I’ll wait while you process that. Here’s the deal: Agile didn’t die because the idea was bad—it died because we killed it. Let’s break it down. 1️⃣ The Checklist Mentality: Agile started as a revolution in thinking but got buried under its own rituals. Daily standups? Backlogs? Sprints? They’ve become corporate theater. It’s not about outcomes anymore, it’s about checking boxes. Agile was supposed to be adaptable. Now it’s just as rigid as the systems it was designed to disrupt. 2️⃣ Scaling Without Soul: Frameworks like SAFe slapped a “scale” sticker on Agile without addressing toxic work cultures. What’s left? More bureaucracy, less agility. Scaling a broken system doesn’t fix it, it amplifies the dysfunction. 3️⃣ Speed ≠ Value: Agile promised faster results, but we’ve confused speed with success. Delivering something fast is useless if it doesn’t make an impact or add value. Agile became a race to nowhere, a hamster wheel of meaningless output. 4️⃣ Leadership Didn’t Get It: Let’s be honest—most leaders never truly bought into Agile contrary to their cheerleading behind it. For old-school executives it’s impossible for them to let go of control, and Agile demands exactly that. Without leadership trust, Agile was destined to fail. 5️⃣ Consulting Snake Oil: As they are famous for doing, consultants turned Agile into a product and sold it like magic beans. They pitched it as the answer to everything, but it wasn’t designed to fix bad leadership or broken teams. Agile isn’t Change Management 2.0, and you failed miserably if you tried to implement it as such. 6️⃣ The Human Cost: Agile became synonymous with “do more, faster.” Guess what? That’s not sustainable. Teams burned out. Engagement dropped. People became Agile collateral damage. The Harsh Truth: Agile didn’t fail; we failed Agile. We ignored its heart, culture, collaboration, trust and turned it into a system for systems’ sake. Here’s a radical idea: forget Agile. Forget the buzzwords. Forget the frameworks. Start with your people. Ask the uncomfortable questions. And lead with empathy. Real transformation doesn’t come from processes or tools. It comes from people who feel heard, valued, and empowered. Agile is dead. Let’s stop pretending otherwise.

Before you roll out Scrum, read this. These 9 lessons could make or break your organization’s agile transformation. At last night’s PMI Chicagoland Annual Business Meeting, David Schwab (William Everett) and Annie Reyes (CASL) shared how Scrum helped shift their organization from siloed planning to collaborative, high-impact delivery. Their nonprofit journey mirrors many of the same challenges and wins I’ve seen in the for-profit world. These lessons are universal—and essential for anyone navigating agile adoption. Here are 9 insights that stood out: ✅ Scrum isn’t just for tech. ↳ It brings speed, alignment, and coordination—even in resource-constrained, people-first environments. ✅ Scrum thrives in ambiguity. ↳ From program launches to cross-functional initiatives, Scrum aligns diverse teams—even when the roadmap is unclear or evolving. ✅ Culture first, then process. ↳ Scrum cannot fix dysfunction, poor leadership, or burnout. It needs trust, psychological safety, and purpose-driven routines. It will shine a light on dysfunction—organizations should be prepared to confront and learn from it. ✅ Start small, scale smart. ↳ Early leader buy-in and time to understand the new ways of working increases the odds of successful adoption across the organization. ✅ Don’t drop the whole playbook on Day 1. ↳ Jumping in with full Scrum terminology and structure can overwhelm teams unfamiliar with agile. Introduce it in plain language and build fluency over time. ✅ Invest in a quality Scrum Master. ↳ One of CASL’s success factors was having an experienced Scrum Master from the start. A trained facilitator is critical to guide, educate, and sustain the team’s momentum. I've seen organizations skip this step—and it significantly derailed adoption. ✅ “Blurry roles lead to blurry results” ↳ When everyone knows their lane, teams move faster, take ownership, and build momentum. Role clarity is critical to a successful rollout—people must not only understand their roles but also be coached to them. ✅ Agility is about people and mindset—not just tools. ↳ Change management and leadership are essential. Expect to spend time coaching your teams, guiding behaviors, and managing resistance. ✅ Retrospectives are the secret sauce. ↳ They create a safe space for feedback and empower voices across titles. These sessions increase engagement, build trust, and generate insights that fuel continuous improvement. The biggest lesson? Agility is about people. It’s not about the framework—it’s about leadership. Reshare to help other leaders navigate their agile transformation. What lessons have you learned when implementing agility in your organization? Drop them in the comments below. 👇 ♻️ Reshare to help other leaders navigate their agile transformation. ➕ Follow Morgan Davis, PMP, PROSCI, MBA Davis for practical insights on leading organizational change and building agile, high-impact teams.

🚨 A Hard Truth: Nothing has been abused more than the Daily Scrum 👉 The Daily isn't open mic night for managers, Product Owners, and Scrum Masters. It’s supposed to be for the Developers to plan out the next 24 hours so they get a step closer to the Sprint Goal. Over the years we’ve: - Forced people to stand up - Made people answer the 3 infamous questions like zombies - Turned it into a status meeting for managers, Scrum Masters, and Product Owners - Stretched it into a 30 to 60 minute problem-solving workshop - Endlessly reviewed Jira tickets one by one - Scheduled it at a time that works for others, not the Developers - Crushed self-management as Scrum Masters by facilitating it for the Developers - Let stakeholders "observe" silently, turning it into surveillance - Treated it as optional, with people wandering in late or skipping entirely 🦃 Guilty as charged! I'm truly sorry I was part of that. Here’s a story from the trenches: A few years ago I was invited to consult with an organization that thought they only needed to "make a few small adjustments." For 45 minutes, a team of project managers sat in front of the team during the Daily, interrogating them, taking notes, and updating Microsoft Project plans in real time. That wasn’t a Daily Scrum, it was a daily status interrogation disguised as Scrum. Here are several ways to make your Daily Scrum effective: ✅ Protect the 15 minutes: ask managers, Product Owners, and even Scrum Masters to allow Developers to have this time without interruption. ✅ Keep it simple: 15 minutes, same place, same time. ✅ Always work toward a Sprint Goal. Stop committing to a fixed number of PBIs. ✅ Use the time to inspect progress toward the Sprint Goal, adapt the Sprint Backlog, and move forward together. ✅ Don't use a Sprint Goal? Start next Sprint. ✅ The three questions are not required. Drop them if they don’t add value. ✅ Scrum Masters, stop inventing "cute" replacements for the three questions. You are impeding self-management. Let Developers design their own structure. ✅ The Daily is not a synchronization meeting. Synchronization should be happening all day long. ✅ Impediments should not wait for the Daily. Raise them as soon as they appear. ✅ Scrum Masters are not required to attend or facilitate the Daily. ✅ If you do attend as a Scrum Master, observe quietly. Stand back, stay silent, and let the Developers own it. ✅ If the Daily is off the rails, use the Retrospective to figure out how to get back to it's purpose and make it healthy. Share your observations and ask Developers how they want to improve it. ⚠️ A plea to all Scrum Masters: For the next week, do not attend your team’s Daily Scrum. 🚪 Seriously, stay out. Hand it back to the Developers. 🤸 If they stumble, good. If it feels awkward, even better. 💡 That is how self-management grows. I promise you this: the world will not end, and your team will survive without you.

Some company cultures are just not compatible with Agile. They treat Agile as a process that can be implemented, rather than a change in mindsets, behaviors, and most of all, values of the people doing the work. Someone up top has decided that we’d better implement this Agile thing. The PMO is assigned to “go figure it out” and come back with a plan. A few months later, Agile processes are feeling heavily bureaucratic or like a bunch of checkbox exercises. There is confusion about roles and responsibilities, and things are getting messy. The problem is that you're struggling to adopt Agile methodologies at the values-level, making it feel more like a set of rules to follow rather than a different way of working altogether. It’s like your company starts up an employee baseball tournament. Only, you’re not allowed to go outside. You have to play in one of the big conference rooms. Oh, and you have to use whatever equipment you find in the supply room. The solution is to start with the values and principles behind Agile first, not the processes. The fundamental values of Agile are often in direct opposition to the established culture of the company. But by addressing the cultural blockers up front, you’ll be more likely to move toward Agile ways of working. 1) Self-organizing teams. The team is the primary unit of an Agile approach, not the individual. Decisions are often made collectively. People can switch roles or overlap without needing any permission or supervision from outside the team. The rigid culture around role definition, incentive and reward structures, and decision making will all need to be modified FIRST before you can support self-organizing teams. 2) Building in smaller increments. Teams cannot know in advance everything they need to know in order to build a working complex system, which most products and applications are. Instead, they need to start with a rough idea that includes a vision, some clear objectives, and some general constraints. Executives attempt to exert a high degree of control over everything before embarking on a project that is large and complex. Leaders will need to change the way they think about planning and funding projects to be able to adapt to Agile ways of working. 3) Adapting to change. The heart of Agile approaches is the acceptance of unknowns, and the ability to change direction based on new information coming in as we go. This is another hard pill to swallow for rigid corporate cultures. Planning has been an important part of company cultures since the days of Frederick Winslow Taylor, and old habits die hard. Executives need to get more comfortable with embracing flexibility rather than adhering to a plan. We work with leaders to help them understand, appreciate, and adopt the changes of mindset, culture, and values necessary before or during big transformations. If you're stuck in the middle of a messy Agile rollout, give me a ping and we'll talk.

Agile was supposed to make everything better. Slower delivery? Agile will fix it. Rigid processes? Just add a Scrum Master. Too expensive? Don’t worry, "self-organizing teams" will handle it. We’ve been hearing the same pitch for over 20 years. Stand-ups, sprints, sticky notes, retrospectives and a flood of buzzwords like "fail fast", "iterate" and "MVP". But here’s what nobody wants to talk about -->Agile didn’t fix everything. In fact, it created new problems. And somewhere along the way, someone started making a whole lot of money while the rest of us were told to stay quiet and "trust the process." The moment you question it, the Agile gatekeepers show up, ready to label you old-fashioned or say "you just don’t get it" or simply blame it on people who can't follow Agile processes. Well, I do get it. I’ve lived it for 20 years. And I’m not here to please anyone, I’m here to speak the truth. Behind the daily ceremonies and Jira dashboards, there’s a different story. Sad story where: a. Testing roles being cut in the name of "efficiency" b. Accountability disappearing because "everyone owns quality" c. QA voices being muted so nobody rocks the sprint d. Chaos being marketed as "experimentation" e. Metrics being gamed just to survive And most people won’t say anything because speaking up can get you in trouble. But I’m not most people. I have no boss over me. No investor telling me what not to say. So I’ll say it, for those who can’t. This article is for anyone who still cares about doing things right. For testers, developers, and leaders who are tired of pretending. For those who still believe quality isn’t optional and who want a better way forward. That’s why I created HIST (Human Intelligence Software Testing). To bring back sanity, structure, and smart thinking into Agile chaos. If you've ever felt like the only one raising your hand while everyone else nods along, this is for you. #HIST #AgileTruths #QARevolution #TestingVoicesMatter #HumanIntelligenceSoftwareTesting

One of the most frustrating experiences as a Scrum Master or even Agile Project Manager is …… …..realizing that the real obstacle to agility isn’t your team. It’s sometimes the system around them. I’ve seen teams go through all the motions: - Sprint planning. ✔️ - Standups. ✔️ - Retrospectives. ✔️ But when you listen closely, you realize something’s off. People are complying, not collaborating. They’re estimating to please, not to plan. They’re adapting the backlog, but not the mindset. This happens when Agile is adopted as a process but not understood as a #value system. Because here’s the hard truth: →You can’t prioritize “Individuals and interactions” in a culture where people are afraid to speak. →You can’t “Respond to change” in a system that punishes deviation. →You can’t “Collaborate with customers” when success is defined by scope and speed, not outcome. And when that gap exists, it always trickles down straight to the project level. Suddenly: You’re delivering “on time” but solving the wrong problems. You’re releasing fast, but nobody’s sure what changed for the user. Teams are “productive” but disengaged. You become the bridge constantly interpreting Agile values for a system that still speaks the language of control and certainty. So what do you do as the team leader? - You stop pushing frameworks and start inviting conversations. - You make retrospectives about honesty, not optics. - You remind your stakeholders that change isn’t the enemy and rigidity is. - And you protect your team’s ability to think, not just deliver. Because in the end, Agile isn’t a method to manage work. 📌 It’s a belief about how humans solve problems together. And if that belief isn’t shared across the system, you’ll keep running sprints in circles. In your experience, what breaks first? Agile processes or Agile values