<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>team dynamics on Agile Software Development</title>
    <link>https://agilesoftdev.com/tags/team-dynamics/</link>
    <description>Recent content in team dynamics on Agile Software Development</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Sat, 02 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://agilesoftdev.com/tags/team-dynamics/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Planning Poker Works, But Not for the Reason Most Teams Think</title>
      <link>https://agilesoftdev.com/planning-poker-works-but-not-for-the-reason-most-teams-think/</link>
      <pubDate>Sat, 02 May 2026 00:00:00 +0000</pubDate>
      
      <guid>https://agilesoftdev.com/planning-poker-works-but-not-for-the-reason-most-teams-think/</guid>
      <description>Planning poker is an estimation technique in which team members simultaneously reveal their estimates for a story, then discuss discrepancies before converging on a number. The standard explanation for why it works is that simultaneous reveal prevents anchoring — no one&amp;rsquo;s estimate influences others before they have formed their own. This is true and not the main reason the technique is valuable.
The main reason planning poker works is that it makes disagreement visible.</description>
    </item>
    
    <item>
      <title>Remote Agile Teams Fail at the Informal Layer, Not the Ceremony Layer</title>
      <link>https://agilesoftdev.com/remote-agile-teams-fail-at-the-informal-layer-not-the-ceremony-layer/</link>
      <pubDate>Sat, 02 May 2026 00:00:00 +0000</pubDate>
      
      <guid>https://agilesoftdev.com/remote-agile-teams-fail-at-the-informal-layer-not-the-ceremony-layer/</guid>
      <description>When agile teams moved to remote work, the common concern was whether the ceremonies would survive the transition. Would sprint planning work over video? Could retrospectives produce candor without physical presence? Would the daily standup maintain its discipline when the team was distributed across time zones?
These concerns were largely misplaced. The ceremonies adapted. Video-based sprint planning, while less fluid than in-person, functions well enough with the right tools and facilitation.</description>
    </item>
    
    <item>
      <title>Retrospectives That Change Nothing Are Worse Than No Retrospective</title>
      <link>https://agilesoftdev.com/retrospectives-that-change-nothing-are-worse-than-no-retrospective/</link>
      <pubDate>Sat, 02 May 2026 00:00:00 +0000</pubDate>
      
      <guid>https://agilesoftdev.com/retrospectives-that-change-nothing-are-worse-than-no-retrospective/</guid>
      <description>The retrospective is the most important ceremony in the sprint cycle and the one most commonly reduced to ritual. Teams go through the motions — what went well, what didn&amp;rsquo;t, what to improve — produce a list of action items, and proceed to the next sprint having changed nothing. The list sits in a document somewhere. The problems repeat.
This failure mode is so common that many experienced practitioners have concluded retrospectives do not work.</description>
    </item>
    
    <item>
      <title>The Scrum Master&#39;s Real Job Is Organizational, Not Ceremonial</title>
      <link>https://agilesoftdev.com/the-scrum-masters-real-job-is-organizational-not-ceremonial/</link>
      <pubDate>Sat, 02 May 2026 00:00:00 +0000</pubDate>
      
      <guid>https://agilesoftdev.com/the-scrum-masters-real-job-is-organizational-not-ceremonial/</guid>
      <description>The scrum master role is routinely reduced to meeting facilitation and impediment tracking. The scrum master runs the standups, schedules the retrospectives, maintains the board, and removes blockers that the team surfaces. Done well, this produces smooth ceremonies and a team that is not visibly impeded. It does not produce the organizational change that agile practice requires to sustain value over time.
The Scrum Guide defines the scrum master as responsible for the team&amp;rsquo;s effectiveness and for helping everyone understand scrum theory and practice, both within the team and across the organization.</description>
    </item>
    
  </channel>
</rss>
