Everyday Kanban

Discussing Management, Teams, Agile, Lean, Kanban & more

Is your Agile agile?

I noticed today that I’m starting to channel people like Jim Benson without even realizing it – until afterwards. I found myself explaining to someone at work today that the tendency to prescribe to others how things should have to be done is pervasive, even in – or maybe especially¬†in – many “Agile” implementations (yes, that’s with a capital A). Upon reflection, I think it is a hallmark of many Agile initiatives driven from the top-down through standard command and control structures. You end up making a complete new command and control structure under a new name and the part that kills me is that you don’t even realize it.

There’s a misconception that standardization is a holy grail. If something works for one team – or maybe, its just the way someone decided to start doing Agile – then everyone should do it. What happened to self-organizing? … to agility? … to the ability for a team to recognize that they are doing something that’s suboptimal to their end goals and then change that thing? Should there really be sacred cows? A quote that stuck with me is that “standardization often inhibits optimization.”

I think if I hear too many more people say “that’s not the right way to do it” in regards to being agile with one’s work I might be tempted to holler. Yes, I’m Southern so y’all watch out. For example, the user story format of “As a <user>, I would like to <action>, unless <exception>,” or variation of that, isn’t the point. The point is that you are trying to ensure you discuss a request to get the right solution and the highest value. No one dies if you don’t follow the magic formula. We have to stop getting hung up on things that don’t matter! Just understand the point of a guideline and make sure you are working towards it. These formulas and what not are guidelines to help teach you a concept, not the goals themselves.

So, if you are writing your stories the “wrong” way and you point things based on hours and not complexity, don’t punish yourself. Chances are you can be more agile than someone doing Agile.

1 Comment

  1. Great post! I’m always wary of top-down mandated standardization. You lose buy in and ownership and lock yourself out of organic improvements.

    I’ve found it is best to take more of a coaching role when trying to introduce agile methodologies to a team. One of my greatest joys was to see the teams start creating and using their own task boards, and to find that they enjoy the daily stand-ups and find great use in both.

    I also gave up on forcing story points down everyone’s throat when I realized that, when doing project estimation, I could care less if you use apples or oranges as long as you stick to either using all apples or all oranges. Consistency is key and accuracy can be derived through consistency.

Leave a Reply