We Keep Getting It Wrong About Agile

The latest State of Agile Report continues to confirm that organizations commit to Agile (and scaling) without initially exploring the implications and prerequisite changes. General Organization Resistance to Change is often a side effect of Implicit Resistance Mindset originating outside the teams (and often manifested by the PMO.)

1. Require each Agile team to look, feel and behave identically to other Agile teams (whether on a Scaled Agile Framework Agile Release Train, within another scaling framework or within an internal scaling or delivery framework)
2. Require each Agile team to use precisely the same planning, development and delivery practices (down to what constitutes a 1-point User Story, a 2-point User Story, etc.)
3. "Drive" (a word I hear far too often from people claiming to lead Agile initiatives) teams to a clock, a cadence and a plan not of their choosing

One of the pervasive Agile Myths is that we can easily (and often forcibly, unfortunately) transform development teams, programs and groups by sending people to Agile training, hiring Agile coaches and retiring Gantt charts. (If Henry Gantt had known how popular his last name would become, he surely would have trademarked it!) This might work for a brief period, but the foundational elements of a successful Agile Culture (and mindset) are far more elusive and require persistence, diligence and transparency. Add humility and empathy to that list (and this list is far from complete.)

When you review and discuss The Agile Manifesto, (note that I didn't say "Read Once and Ignore", a common leadership pattern), you should gain a sense of what the authors were aiming for. (They were aiming, not prescribing.) The language (especially the verbs) is forgiving, allowing for tolerances and imperfections in organizations, groups, teams and individuals. It's not about perfection and metrics. Too much of Agile has become setting standards and procedures and then force fitting them onto Agile Teams (versus engaging the teams in the planning and discussion of how to best work and refine the "How" over time.)

The figure above illustrates a healthier model for Agile Teams to increasingly deliver on their commitments and to flourish from interactions within teams, amongst teams and with the rest of the organization. It's another Agile Myth that Agile Teams are self-sufficient and that Scrum Masters resolve all their impediments. If you were on an Agile Team of 10, would you want one person attempting to resolve impediments or would you want the team to participate as needed and as makes sense? Prolific teams choose the latter strategy, thoughtfully and transparently. Yes, this violates Scrum dogma, but we're in the delivery business, not the follow the rules business. This is already happening on prolific Agile Teams (and on teams that don't call themselves Agile Teams): They just don't talk openly about it.

Thank you for reading my post. These are my first attempts to draw illustrative support for my words. All feedback welcome (including "Go back to drawing school!" - Sorry, I just started!)

Cheers,

Greg