Agile, Kanban

Does It Matter What You Call It?

Imagine that the company you work for has decided that they want to be more agile. Great, right way to go. So they start a project to ease the transition. Not a bad idea really, make sure people use more or less the same terminology, help out with training and similar. To further ease the transition, management decides that all teams should use Scrum. Not a good idea!
With experience from both Scrum and Kanban, you know that it is not really about one method being better than the other. Rather, it is about choosing the right method for the environment you work in and being able to continuously improve.

Now, the team I currently work with has been using Kanban for about a year now, with some good results to show for it. The developers like it, our manager likes it and most importantly: The business side likes it. That doesn’t mean that we are doing it perfectly, far from it. But the members of the team believe in the evolutionary change approach in Kanban, and believe it could be a good approach for introducing agile in an organization. There’s one problem though. There is a common belief amongst the people in the agile transition project that top management will object to Kanban as a method. So what do you then, when management has limited knowledge of Agile, forces all teams to use “the one and only agile methodology”, and thinks Kanban is just IT’s latest fad of the month?

What Matters Is What You Do

Instead of focusing on what things are called, direct your energy towards the good things that you do and the things you want to do in order to improve. Instead of focusing your attention on theory and academic discussions, focus the attention around real world agile practices. Instead of fighting about which method is best, focus on values, principles and mindset.

So, to stay “below the radar” we decided to tune down the focus on names and rather focus on what we believed to be the most valuable principles. Starting with what the teams do now, we agreed that they should

1. Visualize the Workflow
2. Limit Work in Process
3. Measure and Manage Flow

You probably recognize these as the first three core properties of the Kanban method David Anderson wrote an excellent post about these principles a while ago, read it if you haven’t already done so! Together with a few other practices, some from XP and some from Scrum, we agreed that these ought to form the foundation for the teams to follow. While we respect that there is a need for some common framework for the teams, we also realize how important it is to build the framework on principles and values rather than on specific tools. How did we decide? By sitting down together and discussing what works and what doesn’t.

The Way Forward

At the time of this writing, the agile transition project is still in the early days. While some teams have been doing agile for some years, others are just getting started. It remains to be seen if the teams are able to gradually improve what they already have. We all know that it’s a lot easier to do the talk than to walk the walk. In an already complex environments, with teams located in all Scandinavian countries, I’m especially worried that the organization will fall into the trap of overcomplicating the setup. Worried that too many changes will be in progress at the same time, throwing the system into a state of un-stability. There are rumors that such creative initiatives already have taken place. I hope that is not the case. One thing is for sure. When changing the mindset in big organizations, patience is certainly a key ingredient.

To be continued….


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s