Scrum Methodologies in Tech

If the 2020 Scrum Guide is a guide, the Expansion Pack is the Field Manual. It should change how serious practitioners think, teach, and practice Scrum in complex organizations where uncertainty demands discovery, not just delivery. Accountabilities Get Depth. Still 3 accountabilities: 1) PO 2) SM 3) Developers But the Expansion Pack refers to Developers as Product Developers - emphasizing their responsibility for creating real product increments, not just completing tasks. Reintroduces "roles" as relationship types that influence outcomes: -Stakeholders: Clearly defined -Supporters: Shape the environment -AI: An increasingly capable (but unaccountable) contributor You still teach the 3 accountabilities. But you'll coach in a broader, messier, more realistic landscape. Events Stay the Same. Agendas Get Smarter. Sprint Planning breaks into Why, What, and How - with strategy, value sequencing, and trade-offs front and center. Daily Scrums become about plan adaptation, not status updates. Reviews focus on evidence and result feedback, not demos. Retros expand beyond process improvement - tackling self-management, safety, and system-level dysfunction. Artifacts Evolve. Commitments Mature. Still 3 artifacts: 1) Product Backlog 2) Sprint Backlog 3) Increment And 3 commitments: 1) Product Goal 2) Sprint Goal 3) Definition of Done But "Done" gets split: Output Done = Technical quality Outcome Done = Proof of value Backlog Items become hypotheses. Increments trigger learning. Each increment becomes an opportunity to validate or disprove assumptions. Refinement shifts from prepping work to framing problems, surfacing assumptions, and setting up outcome measurement. Teams do research, clarify intent, and negotiate tradeoffs. Sizing is explicitly the Developers' responsibly. The backlog becomes less like a fixed roadmap, more like dynamic bets. If discovery invalidates direction, the backlog can (should) be replaced. The metrics conversation shifts from points and velocity (never part of Scrum) to evaluating whether work produced actual outcomes. Velocity and burndown charts aren't mentioned in the Expansion Pack - not forbidden, but not included. Instead of "Did we complete commitments?", ask "Did the increment advance the product toward its goals?" Measurement focuses on learning - value delivered, assumptions validated, and signals of real user behavior. In essence, Scrum shifts from delivery to discovery - without abandoning professionalism. SMs Step Up. Or Step Aside. The Expansion Pack resets SM expectations: -Change agents -Interference shields -Complexity navigators -System challengers They're accountable for effectiveness, not event logistics. Situational leadership, not servant leadership. The SM role isn’t entry-level anymore. Now it operates at the systems level. Final Thought Agile tourists won't need it, but if you're serious about succeeding with Scrum in complex organizations, you won't work without it.

In theory, Scrum is simple. In practice, teams hesitate at the exact moments Scrum asks them to decide. Sprint Planning stretches because no one wants to commit. Reviews feel polite because no one wants to challenge. Retros repeat because no one wants to change what feels “safe.” Not because people lack skill. Not because they don’t understand Scrum. But because deciding without full clarity feels risky. So decisions get deferred. Softened. Hidden behind process language. In complex product environments, clarity is often created by acting, by making a decision, observing its consequences, and adjusting. Waiting for perfect information doesn’t reduce risk. It usually just delays learning. This is why Scrum doesn’t try to remove uncertainty. It exposes it. Events aren’t checkpoints. They are decision points. Backlogs aren’t plans. They are options. And “commitment” isn’t about sticking to a forecast. It’s about owning the trade-offs you make when the forecast changes. That tension between acting without certainty and remaining accountable for outcomes is one we explore deliberately in the Professional Scrum Master class. Agilemania Agilemania Malaysia

Scrum Explained in 5 Minutes (No Buzzwords, Just Reality) Everyone talks about Scrum. Most people overcomplicate it. Here's what it actually is. Scrum = Simple Framework Work in 2-week cycles. Build. Show. Improve. Repeat. That's it. Everything else is just structure to make this happen. 𝕋𝕙𝕖 𝟛 ℝ𝕠𝕝𝕖𝕤: 𝟭. 𝗣𝗿𝗼𝗱𝘂𝗰𝘁 𝗢𝘄𝗻𝗲𝗿 Decides WHAT to build Responsibilities: - Prioritize features (what's most important?) - Write user stories (what does the user need?) - Accept/reject work (does this meet requirements?) Not a project manager. A mini-CEO for the product. 𝟮. 𝗦𝗰𝗿𝘂𝗺 𝗠𝗮𝘀𝘁𝗲𝗿 Removes blockers Responsibilities: "Team can't deploy? I'll fix permissions." "Designer unavailable? I'll find coverage." "Too many meetings? I'll push back." Not a boss. A servant leader who clears the path. 𝟯. 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗺𝗲𝗻𝘁 𝗧𝗲𝗮𝗺 Builds it Responsibilities: - Developers, designers, QA → everyone needed to ship - Self-organizing (they decide HOW to build) - Cross-functional (no "that's not my job") Not individual contributors. A team that owns delivery together. 𝗥𝗲𝗮𝗹 𝗘𝘅𝗮𝗺𝗽𝗹𝗲 (𝟮-𝗪𝗲𝗲𝗸 𝗦𝗽𝗿𝗶𝗻𝘁): Goal: Build user login feature Week 1: Monday: Sprint Planning (decide scope, estimate tasks) Tue-Fri: Daily standups, team builds Week 2: Mon-Thu: Daily standups, finish building Friday: Sprint Review (demo login to stakeholders) Friday: Retrospective ("Standups ran too long—let's enforce 15-min limit") Next Monday: Start new sprint with improved process. Scrum isn't about following rules. It's about: - Shipping working software every 2 weeks - Getting feedback fast - Improving continuously Everything else? Just structure to enable this. 𝘼𝙨 𝙖 𝙋𝙧𝙤𝙙𝙪𝙘𝙩 𝙈𝙖𝙣𝙖𝙜𝙚𝙧: You don't need to be Scrum Master. But you MUST understand: - Why sprints matter (predictable delivery) - Why standups exist (catch blockers early) - Why retros matter (continuous improvement) I've shipped 20+ products in FinTech, EdTech, Logistics. Every successful one used some form of Scrum. Not because of the framework. Because of the discipline. What's your biggest Scrum challenge? Drop it below. 👇 Follow Santonu Mukherjee for product management fundamentals... practical, from 20+ years in the field. #Scrum #Agile #ProductManagement #SoftwareDevelopment #TeamWork

Scrum is evolving. And honestly, it’s long overdue. We’re seeing the shift from Scrum by the book to Scrum that works. And with it, Scrum Masters are maturing too. 📊 From velocity gaming to value tracking We’re done obsessing over story points. Now it’s about impact customer value, lead time, outcomes that matter. 🧭 From teaching Scrum to enabling agility Less about explaining what’s in the guide, and more about helping teams and leaders become truly adaptive. 🧳 From career Scrum Master to adaptive professional Scrum Masters are stepping into broader delivery, product, or leadership roles guided by agile thinking, not job titles. 🤝 From translating Agile to co-creating it with stakeholders Instead of preaching to 'the business', we’re shaping agile ways of working with 'our business' context first, jargon second. 🛠️ From one-size-fits-all Scrum to toolkit thinking Teams are combining Scrum with Kanban, DevOps, Lean UX dynamically pulling in what works based on need, not dogma. 🎙️ From facilitator to designer of purposeful collaboration Scrum Masters aren’t just meeting hosts they’re leading collaboration that unlocks insight, decisions, and momentum. 🔄 From adherence to continuous improvement mindset We’re not chasing perfect Scrum. We’re building teams that reflect, adapt, and improve continuously in all it's forms. 🤖 From admin and manual work to an AI-augmented role AI is helping with retros, backlog insights, standup summaries freeing Scrum Masters to focus on higher-impact work. 🌉 From team servant to organisational connector Scrum Masters are reaching across teams, departments, and silos connecting the dots to remove friction at scale. 🧭 From framework enforcer to context-based guide No more sticking to the rulebook but using the core patterns of the framework to create space for better delivery and learning. The core hasn’t changed. We're still delivering value fast, adapting based on feedback and helping good people solve real problems together. But the way we deliver that value is what’s changing. And if we keep evolving with intent, Scrum will stay very much alive.

Our CTO Chuck Griess has been a practitioner and critic of Scrum for fifteen years. He's implemented it on teams of five and teams of fifty. He's watched it work beautifully and watched it cargo-culted into dysfunction. So when people ask if Scrum is dead, he doesn't have a simple answer. He has a better question: which of Scrum's assumptions still hold when AI agents are writing code alongside your team? The sprint was sized to human coding speed. Team size guidelines were based on coordination costs when everyone wrote code by hand. Velocity as a metric was a useful proxy when the underlying unit of work was consistent. None of that holds anymore. But not everything breaks. Retrospectives become more critical, not less. The concept of "done" needs redefining but matters more than ever. Timeboxing as a discipline survives any technology shift. Chuck's take: AI didn't kill Scrum. It revealed which parts were solving real problems and which parts were just filling time. He wrote the full breakdown — what breaks, what stays, and what replaces the rest. See the link in the comments for the full Substack article.

Release Notes Updated Chapter: “Beyond Kaizen to Kaikaku: Two Patterns That Transform Good Scrum to Great” https://lnkd.in/eASMHWPg Overview The latest update to First Principles in Scrum: Implementing Scrum and Agile Practices introduces a transformative chapter focusing on two core patterns, the “Happiness Pattern” and “Scrumming the Scrum.” These patterns enable teams to elevate their Scrum practices from incremental improvements (Kaizen) to radical transformation (Kaikaku), driving significant productivity and morale enhancements. Key Enhancements 1. Happiness Pattern Introduction: • Purpose: Establishes a precise tool for identifying high-impact impediments through happiness metrics. • Method: Prompts team members to rate their happiness on role and organizational level, with a focus on identifying actionable changes for the upcoming sprint. • Outcome: Empowers teams to convert broad dissatisfaction into specific improvements, driving iterative yet impactful changes. 2. Scrumming the Scrum: • Description: A systematic approach to remove the most significant impediments identified through the Happiness Pattern. • Implementation: Ensures that high-priority impediments are tackled at the start of each sprint, creating a streamlined focus on improvement before other sprint tasks. • Impact: The combination of these two patterns results in a rapid, compounding performance improvement through continuous focus and feedback loops. 3. Case Studies on Rapid Transformation: • Scrum Inc.: Highlights how one-week sprint cycles, happiness tracking, and empowerment led to a 500% performance boost and rapid resolution of major impediments. • Microsoft: Demonstrates adaptation to Scrum in a large organizational setup using temporary solutions for immediate action. • Toyota: Details the shift from large team sizes to smaller, empowered Scrum teams, achieving a full project turnaround in six months. 4. Key Takeaways for Agile Leaders: • Pattern Precision: Emphasizes the importance of exact pattern implementation, advocating for one-week sprints and iterative action on impediments. • Kaikaku Mindset: Encourages leaders to foster a culture of continual transformation, aiming for revolutionary changes that drive productivity and team satisfaction. • Transformative Leadership: Urges leaders to inspire teams by sharing a vision for improvement, supporting self-organization, and embracing bold actions. 5. Common Pitfalls & Solutions: • Addresses common errors such as defaulting to two-week sprints, treating happiness as a lagging metric, and implementing multiple improvement stories per sprint. • Provides guidance on focusing on one high-leverage improvement per sprint and reinforcing the synergy between Happiness and Scrumming the Scrum patterns.

🚨 Hard Truth: Most teams doing Scrum aren’t actually doing Scrum. Scrum has been around for 30 years. We have a few million certified Scrum Masters. Yet Zombie Scrum is alive and well. They copy the names of the events and roles, but not the purpose. What shows up looks more like project management with "stand-ups" than real Scrum. Zombie Scrum = going through the motions of Scrum without empiricism, a Done Increment, or the Scrum values. It looks alive on the surface, but the purpose and outcomes are dead. Zombie Scrum vs Real Scrum: 🧟 Events as empty rituals, no inspection or adaptation 🌟 Empiricism: transparency, inspection, and adaptation drive every Scrum event 🧟 No Done Increment at Sprint end 🌟 A valuable, useful Increment every Sprint 🧟 Sprint Goals don’t exist ("finish the tickets") / Product Goal ignored 🌟 Sprint and Product Goals give focus, alignment, and long-term direction 🧟 Product Backlog = list of tickets 🌟 Product Backlog ordered by value toward the Product Goal 🧟 Product Owner in title only, no authority 🌟 Product Owner empowered to maximize value 🧟 Scrum Master as admin or coordinator 🌟 Scrum Master enabling self-management and empiricism 🧟 Daily Scrum as a status check for Product Owner or Scrum Master 🌟 Daily Scrum as a short planning session for Developers 🧟 Sprint Review = demo, no stakeholders 🌟 Sprint Review as a working session with stakeholders shaping what’s next 🧟 Sprint Retrospective skipped or just venting 🌟 Sprint Retrospective drives at least one real improvement each Sprint Scrum is simple, but not easy. Without empiricism, a Done Increment, Scrum values, Goals, and self-management… you’re not doing Scrum, you’re just acting it out. 💬 Scrum Masters: Zombie Scrum is everywhere. What are you doing to help your team come alive?

Startup CTOs, if you're running engineering for an even slightly complex enterprise B2B product, it's not just Scrum everywhere or Kanban everywhere. You have to configure your teams properly for success, and apply the right process principles to each (or better, guide them to do it). You'll have three different buckets of work: 1. Sales support and onboarding new customers 2. Maintenance and support 3. R&D / innovate Each of these business functions requires a different set of people (or configurations of the same people) with a different approach to getting work done. You can't just smear "agile" on it like peanut butter. The work required for sales engineering is a lot like consulting. It requires careful listening and reflecting back. And onboarding new customers includes dealing with configuration, data imports, integrations, and the like. The process for this team, and its metrics for performance and success, will be unique and different from that of the other two types of work. Projects have a start and finish, and don't align well with either Scrum or Kanban methods. A documented protocol or checklist approach is usually better. Operating an existing customer product tends to involve a steady stream of heterogenous work, arriving randomly, sometimes with urgent response times. Kanban is perfect for this. A "platform team" as described in Team Topologies aligns well here. Teams that are developing new capabilities are the ones we tend to think about the most as "engineering" or "product" teams, as if that's the only thing tech companies do, ignoring the above two to our detriment. These product development or innovation teams can apply principles from Design thinking, Continuous Discovery, and Scrum to enable reliable and predictable delivery of new, valuable capabilities. The value-stream aligned teams concept aligns here. Look, you don't have to break it down exactly as I have said. Use your judgement, and expand your understanding of what is available to you by looking around and learning from other companies and teams. Don't just paint by numbers to build your teams and process. -- If you need help with this sort of thing, I coach CTOs and other technology leaders. I'd love to hear from you. Give me a shout.

Make Scrum Work FOR You, Not the Other Way Around After 10+ years managing technical programs, the main lesson i do not see implemented enough is Scrum is a tool, not a religion. The TPMs that reign supreme are the ones who understand why each element exists and adapt it accordingly. My Scrum Basics & When to Actually Use Them: Daily Stand-ups (15 min) Essential for: Fast-moving projects with high interdependencies. Adapt for: Distributed teams (async updates work), stable maintenance work (2-3x/week suffices) Sprint Planning Essential for: Innovation projects, unclear requirements, evolving scope Adapt for: Predictable operations work (monthly planning often better than bi-weekly) Backlog Refinement Essential for: ALL programs,this is non-negotiable Why: Prevents sprint planning from becoming a 4-hour nightmare Retrospectives Essential for: New teams, high-change environments, after incidents Adapt for: Mature teams (monthly deep-dives > bi-weekly check-ins) Sprint Reviews/Demos Essential for: Client-facing work, stakeholder-heavy programs Adapt for: Internal tooling (quarterly showcases may be enough) My Pragmatic Approach: For Compliance/Governance Programs: Keep stand-ups and retros. These programs live and die by clear communication and continuous improvement. For Innovation/R&D Work: Sprint planning and refinement are your best friends. Everything else? Make it work for the team's rhythm. For Client Onboarding Programs: Reviews and demos are critical—this is where trust is built. Everything else supports this goal. For Infrastructure/Platform Work: Longer sprints (3-4 weeks), less frequent ceremonies, but never skip retrospectives after incidents. We really need to learn to alternate the program management methods the the program advantage. What's your take? How do you adapt Scrum for different program types? #ProgramManagement #TechnicalProgramManagement

Agile is about co-creation, not delegation. If a Product Owner takes stakeholder requirements, turns them into tickets, and hands them off for estimation, you’ve just rebranded Waterfall. This approach ignores the essence of Scrum: 1. Shared understanding 2. Ongoing collaboration 3. Iterative discovery Instead, let’s include the team early. Let them ask questions, challenge assumptions, and explore solutions before anything hits the sprint backlog. Scrum isn’t just a new language for the same old process. It’s a mindset shift, starting with how we build our backlog. Are your teams involved in shaping or delivering the product? Let’s unpack this together! #AgileMindset #ScrumTransformation #ProductDiscovery #AgileLeadership