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 Them
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:
- Do things the way you do them. If you employ TDD or Pair-Programming or Code-Reviews or Continuous Integration, keep doing it.
- 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.
- Change those things that you do.
- 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.