<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>team structure on Agile Software Development</title>
    <link>https://agilesoftdev.com/tags/team-structure/</link>
    <description>Recent content in team structure 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-structure/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>How AI Has Shifted the Leverage Points in Engineering Teams</title>
      <link>https://agilesoftdev.com/how-ai-has-shifted-the-leverage-points-in-engineering-teams/</link>
      <pubDate>Sat, 02 May 2026 00:00:00 +0000</pubDate>
      
      <guid>https://agilesoftdev.com/how-ai-has-shifted-the-leverage-points-in-engineering-teams/</guid>
      <description>Engineering team composition has historically been organized around the constraint that writing code is slow and skilled developers are scarce. Ratios of developers to product managers, to QA engineers, to designers, to technical writers — all of these reflect an underlying assumption about where the production bottleneck sits. When that bottleneck moves, the ratios that were optimized for the old constraint become wrong.
AI-assisted development has moved the bottleneck. For teams working effectively with generation tools, the constraint is no longer coding throughput.</description>
    </item>
    
    <item>
      <title>Kanban vs. Scrum Is Usually the Wrong Question</title>
      <link>https://agilesoftdev.com/kanban-vs.-scrum-is-usually-the-wrong-question/</link>
      <pubDate>Sat, 02 May 2026 00:00:00 +0000</pubDate>
      
      <guid>https://agilesoftdev.com/kanban-vs.-scrum-is-usually-the-wrong-question/</guid>
      <description>The debate over whether a team should use kanban or scrum is often a proxy for a different and more useful question: does this team&amp;rsquo;s work arrive in predictable batches or as a continuous flow? Scrum is designed for the former. Kanban is designed for the latter. The choice follows from the nature of the work, not from a preference for ceremonies or a dislike of story points.
Scrum works well when a team can define discrete deliverables, plan a fixed amount of work for a fixed period, and evaluate progress at the end of an iteration.</description>
    </item>
    
    <item>
      <title>Most Teams Adopting Scaling Frameworks Do Not Need Them</title>
      <link>https://agilesoftdev.com/most-teams-adopting-scaling-frameworks-do-not-need-them/</link>
      <pubDate>Sat, 02 May 2026 00:00:00 +0000</pubDate>
      
      <guid>https://agilesoftdev.com/most-teams-adopting-scaling-frameworks-do-not-need-them/</guid>
      <description>The scaling agile industry — SAFe, LeSS, Nexus, Scrum@Scale, and their variants — exists to solve a real problem: how do you coordinate multiple agile teams working toward a shared product without recreating waterfall planning at the portfolio level? The problem is genuine. The solution is frequently applied to organizations that do not have it.
The typical trigger for a scaling framework adoption is not coordination failure between teams — it is discomfort at the leadership level with the absence of a visible, organization-wide plan.</description>
    </item>
    
  </channel>
</rss>
