Geeks With Blogs
Lee Brandt's Blog You're only as smart as your last line of code

At least not by the FIRST definition in Merriam-Webster online.

“a body of methods, rules, and postulates employed by a discipline : a particular procedure or set of procedures”

To me, this refers to my development practices (Test-Driven Development, Domain-Driven Design, Pair Programming, SOLID principles, SOA, SOC, etc.). How I do software development. Kanban and Scrum do, however, meet the second definition:

“the analysis of the principles or procedures of inquiry in a particular field”

It’s a tool for inspecting your methodology. I think if it as a “method magnifier”, a way to see everything about your methodology from every angle and every level of abstraction. To shine a really bright light on every corner of how you do things. This distinction is important for two main reasons:

You Can’t Use Them To Do Anything

This is where I think most teams make their first mistake. It is definitely where we made ours when first trying to employ Scrum. We built our “software building” around the tenets of Scrum (Sprints, Stories, Stand-Ups, Retrospectives, etc) instead of using those tools to inspect our methodology.

These tools are meant to be ways of showing everyone where the “stuff we’re doing” is failing or causing problems. They aren’t meant to be the way we do those things.

You Can’t Change ThemMicroscope

There are endless religious arguments from the “Agile Suicide Bombers” that will ride a the principles of their chosen agile process all the way into an epic failure, believing all the while that the principles will deliver them from destruction. People spend lots of time and money studying and evangelizing the tenets of their chosen agile process. Lots of them will never admit that this piece or that provides no value.

Changing your methodology, however, happens all the time. You find a better way to do something, and you start doing it that way. It makes complete sense. People are less afraid to chuck doing something that is wasting their time. It is important to make sure you are really getting no value from it before you chuck it, but if everyone on the team agrees that it is cumbersome or painful with no real payoff, nuke it.

My Opinion (FWIW)

Having done scrum and failed a little and succeeded a little and also done Kanban and failed a little and succeeded a little. Here’s where I feel I am using Kanban right now:

  1. Do things the way you do them. If you employ TDD or Pair-Programming or Code-Reviews or Continuous Integration, keep doing it.
  2. Try pointing the inspection tool of you choice at your methodology. Put your requirements up in stories and track them across the process from planning to implementation and use the tool to identify the things that you do that cause problems, bottlenecks or provide no real value.
  3. Change those things that you do.
  4. Rinse and repeat.

It may seem overly simplistic, but my team and I are constantly reviewing how we do things and watching the Kanban board for signs of problems. As soon as we identify a problem, we talk about it, discuss ways to resolve it and pick one. Then we continue. It has been outright fantastic. Not only have we been better able to “predict” when we think we’ll be finished with the next “thing”, we’ve actually gotten better at building software. That right there is worth the price of admission, for me.

Of course, these are only my opinions, based on my own studies and my own experience. Most of all, they’re my opinions as of this moment. I’ll be very interested to read people’s reaction to this post and see how other people are using these tools.

Posted on Wednesday, July 15, 2009 7:31 AM | Back to top

Comments on this post: Kanban Is Not A Methodology, Neither Is Scrum

# re: Kanban Is Not A Methodology, Neither Is Scrum
Requesting Gravatar...
You read my mind, Lee. I had a conversation w/ a coworker, monday night, where we were discussing my statement of kanban being a form of process control. he eventually concluded that kanban is a methodology, and i didn't quite agree with that. thank you for clarifying my thoughts for me! :)
Left by Derick Bailey on Jul 15, 2009 8:34 AM

# re: Kanban Is Not A Methodology, Neither Is Scrum
Requesting Gravatar...
Hey Lee,
I agree with the concept your attempting to describe, but find the terminology reversed. In my experience many professionals outline the distinction as being between "methodology" and "practices". Practices are things like TDD/BDD, XP, unit testing, code reviews, etc. and are to a large degree independent of the methodology you use. Methodologies are the overarching processes used to complete a project - waterfall, scrum, kanban, etc. Any particular methodology can use or not use the varying practices.

I believe I've read Ken Schwaber refer to this in "The Enterprise and Scrum" book, how Scrum alone is useless without adding good engineering practices.
Left by Nolan Egly on Jul 15, 2009 9:34 AM

# re: Kanban Is Not A Methodology, Neither Is Scrum
Requesting Gravatar...
Hey Nolan:
First, thanks for taking the time to comment. I agree that TDD/BDD is a practice, but all your practices together make up your "development methodology". Scrum & Kanban are more "Project Mgmt Methodologies". They are ways to inspect your development practices, so that you can identify problems.

But the main point of the post is to warn people of the dangers of trying to use Scrum or Kanban to define your "development methodologies" from the outset. If that makes sense.

Left by Lee Brandt on Jul 15, 2009 9:44 AM

# re: Kanban Is Not A Methodology, Neither Is Scrum
Requesting Gravatar...
Hey Lee,

Exactly, methodology usually means "project management methodology".

Makes perfect sense and you're exactly right on the dangers of using methodologies (project methodologies) alone for practices (development methodologies). For one thing, not every methodology defines many practices and those that do are intended to be applied to very specific circumstances. Every project is different, and one size does not fit all.

Thanks for the good post and discussion.
Left by Nolan Egly on Jul 15, 2009 10:03 AM

# re: Kanban Is Not A Methodology, Neither Is Scrum
Requesting Gravatar...
I think another point of Lee's post comes from doing lean/Kanban. We've found a distinction between trying to get good at Agile and trying to get good at software development.

They are not the same thing. It's hard to see that unless you look at Scrum/Kanban as tools for inspection. Of course it's a bit easier with Kanban because it's designed for that. Scrum on the other hand is designed to get better at doing Scrum.
Left by Troy Tuttle on Jul 15, 2009 4:30 PM

# re: Kanban Is Not A Methodology, Neither Is Scrum
Requesting Gravatar...
@Troy: "Scrum on the other hand...."

I know flamebait when I smell it, and that, Sir, was flamebait. But I'll bite. Scrum is specifically designed for empirical introspection to the "processes", or what methods or practices you've chosen to employ at the application of tackling a problem, to determine where failures or inconsistencies exist, and draw the out so that the team addresses. At least that's how, when properly applied, it's supposed to work. Now if some folks' practice, that isn't how it turns out, it speaks more to either understanding or the application ( or lack thereof, I've found altogether too often) of the principles behind Scrum.

And Nolan is right, one of the underlying tenets Ken's outlines in the guide ( ) is that Scrum is there to help you in applying good engineering practices more effectively, not applying Scrum itself more effectively.

Left by Marcelo L on Mar 15, 2010 10:37 PM

Your comment:
 (will show your gravatar)

Copyright © Lee Brandt | Powered by: