Verbing the Noun: A Hammer is Not Hammering, or, A Post About Separating Tools from Processes

The other day (read: several months ago) I was sitting outside talking shop with David Laribee.  We started discussing kanban and some things he does on his team, and I thought I’d finally caught him on something:

Me: But wait…you do daily stand-up on your team.  That’s a scrum thing.  So would you say you’re doing scrum-ban?

Dave (nonplussed, and without hesitation): Daily stand-up is a tool.  It has nothing to do with scrum.




Tools are not processes.

Tools can be used in any context, if they help you.  Don’t limit yourself to using only things prescribed for your particular methodology.  I’m no Jainist, but I’m still not going to kill a bug (except for that palmetto bug that I ironically attempted to kill with a copy of the Bhagavad Gita the other night [read: weeks ago], but that was life or death.  That thing was the size of a pony).  If something fits what you believe in or how you work, do it.

Prime example: Kanban is not a board.  The board is a tool used with kanban.  But how many times have you seen people get hung up on the board and focus explicitly on that as actually being kanban?

You don’t need to follow everything to the letter if it’s not working for you.  Using scrum for us was like trying to fit a square peg into a solid piece of obsidian.  Daily stand up sure helped though.  We were able to strip out things we liked from scrum and cut the things that didn’t work for us in order to improve our process.

What you do need to do is make sure you are understanding what you are working with/preaching/living.  If you said kanban was a board, maybe you need to do a little more reading and research.  And in doing so, you will surely find a lot more information that will help enhance your processes and give you a better understanding of how these things can help your team.  Maybe you’ll even find something better.

My recommendation is not to get hung up on making your team fit with a methodology or process (either because it’s the hot thing in development or because someone is cramming it down your throat as The Law); if some of the related tools are not working, drop ‘em.  Find something better.  Make your processes and methodologies fit your team.  Make up your own stuff.  Don’t feel pressured by the Kanban Kids or the Scrumies (Scrumites?) to work in rigid ways that don’t work for you.  We got a lot of crap when we started dropping things from scrum, but then “scrum-but” became a thing, because, well…scrum works for some, but it’s not ideal in every team/project scenario.

I’d love to hear more on this in the comments.

No comments yet

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

%d bloggers like this: