ScrumButs are the downfall of agile

I normally am in good agreement with Jurgen, but not in with his new article. The ScrumBut Ken argues against aren’t targeted towards mature agile teams.

The fundamental problem we have – in Scrum, in XP, in Crystal – is that teams don’t want to even *try* the practices.

• “There’s no way I can sit next to someone all day”
• “Our code is too complex to write tests first”
• “We don’t need stand-ups because we’re already communicating well enough”

It’s about context. If you’ve tried the practices, and have valid reasons why it doesn’t work for your team, and how you overcome that, then you are likely at an organizational maturity level past that which is the target of ScrumBut.

Further, there is nothing wrong with dogmatism when it is for the sake of learning and gaining context. Saying to a team, “I realize that we do X, but why don’t we go all out and try Y, since the XP book says that it is a good practice” – is that really a problem? It is being dogmatic, and then you use inspect and adapt against it.

My recent post about the CSM being the VB of Agile applies here. What gives the software development industry a bad name? It’s not the time to solve a problem. It’s that we don’t pick the right problems to solve, and when we do solve them, we can’t maintain or tweak them. That comes solely out of people not taking the time to actually adopt clean code practices.

Such is the case with the agile software world. What gives the CSM a bad name? The people who take a two day course, go back and cargo cult adopt Scrum in their organizations, don’t follow the practices (especially the one that says “Inspect and Adapt”) and then – and here’s the kicker – go to their conferences and say, “We do Agile!”

This is utter crap. When you are experienced, you know where to take shortcuts, where things won’t bite you. But when you don’t – and I’d venture to say that’s where a majority of Scrum people are – taking shortcuts isn’t just detrimental to your whole team, it’s detrimental to our industry and the goals to improve software development.

So yes, the “But” is a vital part of maturing as an organization. But (pun fully intended) saying, “If you aren’t tweaking Scrum then you aren’t doing it right” is, in my opinion, actually a harmful statement without the context of “once you’ve tried the practices for several iterations, and reflected as a team about what is working and what isn’t”

Now, does that mean a team shouldn’t start with a Kanban board? No. Not at all. If your team can level stories properly, can discuss flow states and is willing to give it a try, you are already past the maturity levels of a large majority of teams. I still think you should try both to be able to compare and contrast, but hey, if you don’t, I’m not going to fault you.

I’ll close this out with this. As a former Firefighter/EMT, there were plenty of times when we or our Paramedics had to stray from the norm to solve out-of-the ordinary solutions. But you only strayed once you had the experience and ability to understand the consequences of your decision. And until you had that, you trained and experimented and trained and reflected and discussed and trained until you did.

So I find nothing wrong with the default and general advice to be not to tweak until you have the context necessary to be able to tweak. And for mature teams, that may be early in. But you don’t know until you try, and saying you should tweak without trying I think has led us to the exact situation we’re in – an industry of unmaintainable, untestable, low quality, low value crap.