Why Agile Practices Fail

“Agile doesn’t work” pitfall #1: Organizations adopt practices, but practices are only effective when executed with the mindset (values, beliefs, and principles) that gave rise to them.

In the article Don’t Write Agile off Just Yet I mentioned three pitfalls that make it seem like Agile doesn’t work. This article takes a closer look at the first one.

In a bid to maximize its success in making a product/solution, an organization optimizes its way of working for specific values. These choices are based on beliefs about people, customers, and the work. Those values & beliefs give rise to principles, which in turn influence tactics (process, practices, roles, etc.)

When the prevailing set of values is the Agile four, certain principles are likely to be in play: collaboration, feedback, safety, transparency, getting to “done,” outcome thinking, and more.

When the prevailing set of values is the traditional one (get it right the first time, commit early, standardize), other principles are likely to be in play: plan the work and work the plan, pass work down from one specialist to another, organize as “hub and spokes,” and more.

Say you adopt the daily Scrum/standup. With folks operating by Agile principles, it’s likely to be a collaborative discussion about finishing valuable work together. People feel safe to articulate their impediments or to ask for help.

However, with traditional principles, the dynamic is a lot more subdued. Everybody provides an “update” about “tickets” to the perceived authority (SM, manager, etc.) Their answers to “What will you work on today?” are often known from the last planning session. And since the traditional approach doesn’t assume safety or transparency, the answer to the impediments question is likely to be “I’m fine.” It’s a daily status meeting.

OK, so what? It’s not just that one dynamic is more interesting and engaging than the other. The former enables adaptation and frequent value delivery, and invites everyone to apply themselves. The latter ensures tracking to earlier plans and reinforces a separation between doers and deciders, neither of which enhances agility.

Let’s look at the product backlog. Acting with Agile principles, its users keep it current, not too large, detailed only where necessary, and traceable to outcomes. It enables adaptation and early value delivery. Acting with traditional principles, its users likely make it large, promise all of it, and don’t populate it collaboratively. The same nominal “Agile artifact” is now a project plan and doesn’t enhance agility.

We can see this effect with every so-called Agile tactic. Here are three more examples:

Scrum Master: with one set of principles, a servant leader helping a team get great using Scrum. With another set, a process enforcer and project administrator.
Sprint demo: opportunity for feedback and adjustment, or for sign off.
Refactoring: an intentional practice for technical adaptation and keeping the cost of change down, or a penalty for bad early decisions.

Nobody’s mindset is purely Agile or traditional, so actual behaviours are not that extreme, but mindset shapes people’s tactics and thereby their outcomes. That’s why leaders must be intentional & explicit about the mindset they’d like their organization to exhibit, and help make it real.

(For a deeper look at the second pitfall, read Agile Values: You Need the Whole Set.)