Understanding Agile Methodologies in Tech

Most Scrum Masters aren’t struggling with Scrum. They’re struggling with something far more dangerous: A culture that says “We want agility”… but behaves like it wants control. Every day, Scrum Masters walk into organizations asking for - speed without learning, - transparency without discomfort, - self-management without letting go, - innovation without ambiguity. And then we wonder why transformation stalls. Scrum doesn’t break teams. It exposes the system that’s been breaking them for years. - Fear. - Silence. - Hero worship. - Perfectionism. - Obedience disguised as “alignment.” Scrum Masters don’t own culture— but they’re the first to feel when culture contradicts the truth. And the only ones expected to name it before it crushes the team. This carousel is for every Scrum Master fighting battles their organization doesn’t even acknowledge. Because Scrum is easy. Culture is where the real work begins. #ReTHINKagile Agilemania Agilemania Malaysia

𝗔𝗴𝗶𝗹𝗲 𝗱𝗶𝗱 𝗻𝗼𝘁 𝘀𝘁𝗮𝗹𝗹 𝗮𝘁 𝘁𝗲𝗮𝗺 𝗹𝗲𝘃𝗲𝗹. 𝗜𝘁 𝗿𝗲𝗮𝗰𝗵𝗲𝗱 𝗮 𝗹𝗶𝗺𝗶𝘁 𝗮𝘁 𝗹𝗲𝗮𝗱𝗲𝗿𝘀𝗵𝗶𝗽. Recently, I joined a panel on the 𝗠𝗮𝗻𝗶𝗳𝗲𝘀𝘁𝗼 𝗳𝗼𝗿 𝗘𝗻𝘁𝗲𝗿𝗽𝗿𝗶𝘀𝗲 𝗔𝗴𝗶𝗹𝗶𝘁𝘆 alongside Lenka Pincot PMP, PfMP, PMI-ACP, PMI-PBA, Heidi Musser, and Jon Ward. The focus was not on frameworks or scaling models, but on how organisations actually make decisions, set priorities, and deliver value. I’ve written a new article: 𝗘𝗻𝘁𝗲𝗿𝗽𝗿𝗶𝘀𝗲 𝗔𝗴𝗶𝗹𝗶𝘁𝘆 𝗜𝘀 𝗡𝗼𝘁 𝗮 𝗧𝗲𝗮𝗺 𝗣𝗿𝗼𝗯𝗹𝗲𝗺 — 𝗜𝘁’𝘀 𝗮 𝗟𝗲𝗮𝗱𝗲𝗿𝘀𝗵𝗶𝗽 𝗢𝗻𝗲 One question shaped the discussion. Why does progress stall once Agile moves beyond teams? Teams have improved. Delivery has improved. Yet many organisations still struggle to translate that into consistent outcomes. The issue is not the capability inside teams. It is how the organisation is run around them. Agile never redesigned decision-making, funding, or prioritisation at the leadership level. Many organisations scaled team practices without changing those elements. Teams are pushed to move faster, while decisions stay slow and priorities remain unclear. That creates activity without a consistent impact. The shift in conversation is telling. Leaders are no longer asking about Scrum or ceremonies. They are asking about value, speed, and risk. That is where the real constraint sits. From a CIO perspective, the pattern is familiar. Too many priorities, slow decision-making, limited visibility into outcomes, and misalignment among teams, funding, and strategy. These are structural issues, not delivery ones. The unit of change is no longer the team. It is the organisation. Leadership behaviour, decision-making, and how value flows all need to evolve together. AI is making this visible. Faster execution exposes slow decisions and misalignment very quickly. That is increasing pressure on leadership to fix the system, not just the symptoms. The article goes deeper into what this means in practice and what leaders can do differently starting Monday morning. Link: https://lnkd.in/eBcRqjAH Where do you see the biggest constraint today, teams or leadership systems? #EnterpriseAgility #Leadership #CIO #CTO #BusinessAgility #Transformation #AI #OperatingModel

Agility isn’t a phase. It’s a leadership mindset. Lately, I’ve been thinking about what that really means. Because in my experience, the most agile orgs aren’t just chasing speed. They’re the ones where clarity, trust, and adaptability are baked into the culture. Not just in frameworks or sprint cycles, but in how we show up, make decisions, and create space for our teams to move faster than we ever could on our own. A few ways I’ve seen that come to life: Empower small, cross-functional teams: Some of the most meaningful work I’ve seen has come from lean teams with a shared mission and the freedom to move. When people are trusted, they move with purpose. Make feedback continuous and lightweight: Agility doesn’t mean changing direction every week. It means building habits around listening, iterating, and staying close to the signals that matter. Use AI to reduce drag, not just cut costs: The right tools go beyond automation. They unlock autonomy, helping teams make smarter decisions faster and clearing the path for momentum. Agility starts with how we lead, not just how fast we can go. Curious to hear: what has helped you build a more responsive, resilient organization? #Leadership #EnterpriseAgility #FutureOfWork

Agile isn’t just a process—it’s a mindset. At its core, Agile is about valuing progress over perfection. It’s choosing working software over a big, detailed plan that might never see the light of day. It’s about learning fast, experimenting, and improving as you go. Think of it as a loop: 1️⃣ You build something. 2️⃣ You reflect on whether it worked (hello, retrospectives). 3️⃣ You improve. 4️⃣ Repeat. This iterative approach isn’t just about delivering better results; it’s about adapting and growing. Agile frameworks like Scrum are tools that help implement this mindset, but the mindset itself is what matters most. Here’s something interesting I learned from @Maria Chec: Scrum, which many associate closely with Agile, was actually created before Agile. The thought leaders and creators behind it had already started shaping what would eventually become the Agile Manifesto. For me, this is a reminder that frameworks like Scrum are helpful, but they’re not the goal. They’re just vehicles to help us embrace an Agile way of thinking. And a few tips to embrace an Agile mindset: ✅ Value progress over perfection: Focus on creating working software instead of detailed plans that might never happen. ✅ Learn fast: Experiment, make mistakes, and learn from them quickly. ✅ Reflect and improve: Use retrospectives to see what worked and what didn’t. Then, make changes and improve. ✅ Think iteratively: Build, reflect, improve, and repeat. This loop helps you adapt and grow. ✅ Use frameworks like Scrum: Remember, Scrum was created before Agile. It’s a tool to help you implement the mindset, not the goal itself. ✅ Embrace change: Be ready to adapt as you learn more and as circumstances change. What’s your experience with Agile? Do you feel like it’s a mindset or more of a set of rules where you work? Let’s discuss in the comments! 👇

I’ve been working as a contractual Program/Project Manager on complex projects for the past 7 years, most of which followed Agile methodologies. While the Software Development Life Cycle (SDLC) is designed to reduce risk, poor implementation can have the opposite effect. If not executed properly, it significantly increases the risk of project failure. Here’s a quick ranking of critical failure points that commonly derail software projects: 🔴 1. Unclear or Changing Requirements Poorly defined needs or constant scope changes break alignment early and often. ✅ Fix: Involve stakeholders early, use user stories and clarify DoD (definition of done), and validate frequently; another advice: make sure to define change request in the initial contract with the client. 🔴 2. Inadequate Planning & Estimation Unrealistic timelines or budgets create pressure that leads to shortcuts and burnout. ✅ Fix: Buffer for unknowns, involve tech leads in estimation. 🟠 3. Ineffective Communication Team silos and misalignment cause costly rework and delays. ✅ Fix: Daily stand-ups, shared documentation, clear ownership. The tech team needs to understand the functional requirement to be able to implement it technically. 🟠 4. Weak Design & Architecture Hasty or shortsighted technical decisions lead to rework and scalability issues. ✅ Fix: Involving a software architect who could support drafting the best scalable architecture choices within the available projects needs, constraints and budget 🟠 5. Insufficient Testing & QA Testing cut short = bugs in production, bad UX, security holes. ✅ Fix: Invest in a QA strategy to identify tests to be run by type of release, and automate critical time-consuming tests 🟡 6. Lack of Stakeholder Involvement Software built in isolation rarely meets business goals. ✅ Fix: Demo regularly (ideally after each milestone), build feedback into the cycle. 🟡 7. Poor Change & Config Management Inconsistent environments and chaotic updates derail progress. ✅ Fix: Version control, CI/CD, and clear change protocols. 🟡 8. Inadequate Risk Management Unexpected issues become blockers when risks aren't flagged early. ✅ Fix: Ongoing risk logs, contingency planning. 🟢 9. Neglecting Post-Launch Support No plan for support = user churn and poor adoption. ✅ Fix: Monitor performance, address issues fast. 🟢 10. Lack of DevOps & Automation Manual processes delay releases and increase error rates. ✅ Fix: Embrace CI/CD and infrastructure-as-code. Strong software isn’t just about great code—it’s about clarity, communication, and continuous feedback. A strong Project Manager implements the right processes and follows each step methodically to spot weak links early and address them proactively. And when issues do arise (as they often do), they stay calm, communicate transparently, and ensure all stakeholders remain aligned throughout the journey. #SoftwareDevelopment #SDLC #TechLeadership #ProjectManagement #Agile #DevOps #ProductDelivery

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

We don't have to have all of the same opinions about agile to get along. I know lots of coaches and scrum masters with very different opinions who are excellent. You may believe in the Scrum Guide to the letter. I'm much more like "directionally correct and usefully wrong" about following agile frameworks. You might have a bunch of certifications. I choose instead to be a rabid reader and accumulate diverse, real stories to help me be a better coach. We don't even have to define the Agile Mindset exactly the same way. HOWEVER... if you don't think these 7 cultures and mindsets are a crucial part of "being agile", then we are miles apart! * An Iterative Mindset -- Deliver value in small, iterative steps allowing for early and frequent feedback on each piece of work, which helps eliminate waste and build better products faster. * A Product Culture -- Form long-lasting, durable, product teams that reflect the company’s focus, vision, and purpose. Share a product vision that influences the teams’ backlogs and day-to-day work. * A Customer-Centric Mindset -- In customer terms, give the teams an appreciation for WHY it matters to the users before doing anything. Don’t guess what customers want, be customer-driven and empirical. * A Culture of Learning -- Team members share knowledge, make learning a priority, and invest in communities that grow people and skills that benefit the company. All failures are opportunities to learn something. * A Culture of Experimentation -- A Design Thinking mindset should be utilized from idea formation through delivery. Instead of requirements, think hypotheses. What’s the smallest thing we can do to learn something? * A Culture of Continuous Improvement -- Teams are empowered to change and improve their own process. Self-reflection, transparency, courage, and respect lead to sustainable value delivery and better results. * A Culture of Psychological Safety -- People will not be punished or humiliated for speaking up with any ideas, questions, concerns or mistakes. This breeds greater innovation, inclusive collaboration and a greater flow of ideas that can impact our products, people, and company. THIS is how I define the Agile Mindset. And that feeling you get when the team "gets it"... that mysterious sort of time when it "clicks" is because these 7 things have started to grow and become habits, beliefs, and BEHAVIORS of the team.

Telco Organizational Latency Is Worse Than Network Latency At Google Cloud, structure was the accelerator. Managers had 10 to 12 direct reports. Most employees sat within 3 layers of a VP. Alignment was not a meeting. It was built into the model. You owned the outcome or you did not. The result was speed, not from hustle, but from architecture. Telcos run on a different blueprint. Most still carry 8 or 9 layers. Manager spans an average 4 to 5. Departments like legal, billing, IT, care, marketing and compliance each protect their domain. But no one owns the full outcome. Work gets fragmented. Accountability disappears into the process. That used to make sense. Technology was modular. Switches stayed in the NOC. Billing systems ran on mainframes. Care followed scripts. Org charts mirrored technology silos. But modern business is horizontal. AI, analytics, and cloud cut across functions. Identity, security, personalization, and observability; none live in one team. Execution flows through the whitespace between roles. And that whitespace is unmanaged. Vertical structures now create drag. Layers multiply decision latency. Teams wait for approvals. Silos fail to align. Every extra step adds delay. The structure itself becomes the blocker. The numbers expose the gap. Meta generates over 1.5 million USD per employee. Microsoft sits at 1.05 million. AT&T is under 600 thousand. Orange is near 370 thousand. To generate 1 billion in revenue, Meta employs 650 people. Orange needs 2,700. That is a structural difference, not just a business model gap. STL reports that 70% of Telcos still follow strict verticals. Boston Consulting Group (BCG) found that digital-native companies launch products 40% faster. Bain & Company data shows flatter orgs double decision speed, even with the same headcount. In some Telcos, a prepaid plan update requires input from 12 departments. Every step adds latency. Every layer compounds it. Strategy may say agile, but structure still runs waterfall. So, how to create an "ultra low latency org chart"?: Eliminate internal SLAs. Replace with shared OKRs tied to real outcomes such as churn, NPS, ARPU, and conversion. Organize around squads, not functions. Each squad owns a product or journey end-to-end, with embedded tech, ops, marketing, care, and analytics. No handovers. No alignment meetings. One goal. One backlog. One accountable unit. Flatten the structure. Limit org layers to 3 or 4. Expand the manager spans to 10 or more. Remove matrix reporting. Push budget, scope, and delivery decisions to the squad level. Embed legal, finance, and compliance into teams or abstract them as internal platforms. Kill approval chains. Replace control with coordination through code, systems, and shared KPIs.

Agile Manifestation: More Than Just Sprints and Standups. We often speak of Agile in the context of delivery models, scrums, kanban boards, retrospectives. But true Agile manifestation is a mindset shift that goes beyond ceremonies. Agile manifestation is when: Teams own outcomes, not just tasks. Feedback isn’t feared — it’s fuel. We deliver value, not just outputs. Adaptability becomes culture, not compromise. It’s not about being fast. It’s about being focused, flexible, and customer-first — continuously inspecting and evolving, even when it’s uncomfortable. 1) Are you just "doing Agile"? 2) Or are you truly living it across your product, culture, and leadership? Agile isn't a tool. It's a transformation. #Agile #Leadership #ProductManagement #AgileMindset #Transformation #TeamCulture #Innovation #DeliveryExcellence

There's a sad phenomenon I've observed in so many organisations: they proudly declare themselves agile, yet somehow end up running waterfall in disguise. The gap between management expectations and engineering reality keeps widening, and I've been trying to understand why. It often starts innocently enough. Leadership embraces agile terminology but struggles to let go of traditional command structures. They want the benefits of agility (speed, innovation, adaptability) whilst maintaining the comfort of detailed roadmaps and fixed deadlines. Meanwhile, engineering teams start with genuine enthusiasm for agile practices, only to find themselves executing predetermined plans with little room for iteration or learning. The disconnect grows gradually. Management asks for commitment to specific features months in advance. Engineering agrees, hoping to maintain some flexibility. When changes inevitably arise or estimates prove wrong, trust erodes on both sides. Management sees a team that can't deliver on promises. Engineering sees leadership that doesn't understand the realities of software development. What fascinates me is how both sides retreat to their comfort zones when stressed. Management tightens control, demanding more detailed plans and status reports. Engineering becomes defensive, feeling reduced to order takers rather than problem solvers. The resentment builds quietly but steadily. The tragedy is that both sides want the same thing: successful products delivered efficiently. But without genuine understanding and trust, the gap becomes a chasm. Management wonders why their "agile" teams can't seem to deliver reliably. Engineering wonders why they're doing waterfall with extra meetings. Breaking this cycle requires courage from both sides. Leadership needs to truly embrace uncertainty and empower teams. Engineering needs to communicate challenges early and often. Most importantly, both need to acknowledge that real agility isn't about following a methodology; it's about creating an environment where adaptation and learning are valued over rigid adherence to plans. When what flows down the organisational hierarchy is orders rather than intent, this divide will never truly heal. Until leaders share the 'why' and trust teams with the 'how', we're just playing agile theatre. #agile theatre #agilesoftwaredevelopment is not #waterfall in disguise #softwaredevelopment #softwareengineering #leadership #softwaremanagement