Why There Is So Much Bad Agile Out There

There is a lot of bad Agile out there. We all know this and have seen it. There are a lot of reasons for it, but one that I think is a major cause of it is not discussed very much. That is that the way we teach it, as a series of steps to follow.

While this makes it easy to follow, it sets up people for not really understanding why they are doing what they are doing. I understand that people want to know what to do and we do need to give them tangible practices to start with. But the objective of what to do is equally essential and is often not discussed. Instead people talk about starting with mindful practice and then going beyond those steps to the next level.

Of course, how to do this is left unexplained. And, without understanding why we are doing the practice, it’s hard to consider viable alternatives. Instead, people often just get frustrated and stop doing the practice entirely. Many teams doing “kanban” started out as a Scrum team that abandoned sprints but didn’t pick up the kanban practices required to take their place.

The reason there is so much bad Agile out there is because people don’t know what good Agile looks like.  For example, something as ubiquitous as the daily standup has evolved into little more than a status meeting about the individuals of the team. This is not what it should be. Simply stated, the purpose of the daily standup is to increase collaboration, make a daily plan to increase focus, see if the iteration plan needs to change, ensure visibility is present and ensure impediments are visible.

These last two shouldn’t take any significant time because if they are visible no one needs to mention them. If they are not visible, their lack of visibility is a symptom of something else going wrong.

Note that if, in fact, we need a status report, it is likely that our board is not clear. But it’s worse than that. Talking about what each individual is doing (“I worked on this, I’m going to work on this, this is what is in my way”) has people focus on themselves and not the team.

For more see Challenging Why (not if) Scrum Fails. Understanding what causes failure can usually be used to facilitate success.