Tag Archives: kanban board

Tyranny of the Tools

As an agile coach, it’s been both a privilege and a pain to watch groups of extremely smart people blow themselves up.

The sad thing is that you can explain how this is all going to happen, you can plead with them not to head down this path, yet they do it anyway. What could have been a kick-ass team instead becomes a boring slog down old project management road.

And it all begins with automation.

That may sound strange. After all, we’re technologists, damn it. Our job is to take repetitive manual jobs and make the computers do them, right?

When I train people, we use post-its and index cards. We use painter’s tape on a wall. If we have a token for work that is to be performed — a story or a task — we jot a title down and plop it on the wall. This is called visual process control. It’s the result of decades of research and experimentation.

Or to put it bluntly, when my wife wants me to mow the lawn, she can ask, she can email, or she can make a bright red note and stick it on the refrigerator where I have to look at it every time I get a snack. Guess which one gets results. Make me look at it — even when I’m doing something else — and I’ll figure out a way to make it go away.

We find that things we look at — even in a casual, off-hand manner — are the things we think about. We also find that as we see things, we work on them in our mind in the background. We make a lot more progress letting our subconscious mind work on things while we’re busy with more important stuff, like technology development.

Still, there’s nothing like the gleam in a programmer’s eye the first time he sees a story/kanban board and physical risk/issue list. Note cards! On a wall! It’s like 1960 or something in here!

Then the gears start turning. Watching, I feel a terrible sadness, as if thousands of man-hours all screamed out at once, then were suddenly silenced.

There’s a reason why there are 40-thousand software implementations of Scrum/Agile on the web. Everybody who’s ever sat in a team room looking at the wall wanted to “fix” it.

Obviously a spreadsheet could handle all these lists and totaling up of things. And it’s not too hard to make a replica of a storyboard using some HTML5 and AJAX tools. Heck, given a few days, we could make a thing of beauty out of this — and make it easier to use too! Hell, I could be adding and completing stories on my iPhone! Taking some old, cranky, ad-hoc system using bubble gum and bailing wire and replacing it with a database and a decent front-end? This is the entire point of modern life! This is what we do! Why suffer?

Sigh.

So then — if we’re lucky — somebody does up a spreadsheet. Then everybody has to update the spreadsheet. Notice how the focus has moved. Instead of sitting in a room doing other things while the status of our project beckons us on the wall, we’re sitting in our cubicles filling out a spreadsheet once a day. The focus is on remembering to update a tool, not thinking about the status of our project. The tool starts running the project. It becomes the central source for finding out things. Not the people.

If we’re not lucky somebody writes a check for a more “powerful” tool. “Powerful” Agile tools usually have all sorts of fields, checkboxes, and whiz-bangs. They promise all kinds of benefits for teams — track your actual time! Track code changes against tasks! Roll up dozens of projects in a single bound!

So the job becomes completing the tool. Stand up? Well, that’s a reason to verify the tool has everything updated. Sprint closing? A detailed check to make sure the tool is in sync. Retrospective? A time to talk about updates to the tool. Do we need new fields? New reports?

It’s not us working the project. It’s us working the tool. Meanwhile, we still have the project to deliver. Agile becomes just another way to micro-manage and control.

Of course, I’m no Luddite. I love tools — as a means to communicate. There’s no better way to look at a team from a distance (when you can’t actually walk into their team room) than some sort of easily accessible online tool. So the team still works like it always has, using bubble gum and bailing wire, and each day somebody takes the stuff on the board and transfers it to a tool. The tool is never used except my remote workers as a way to visit the team room.

This is all just extreme fantasy on my part, of course. I’ve never seen a company that bought a tool that didn’t end up servicing the tool instead of actually being Agile. But I continue to hope.

There are people who love tools. These are the people who build them, sell them, or have a full-time job to maintain them. To them, tools are the answer to everything. How could you not love something that organizes so much data so easily? Weird thing — these people are also not the people who are actually doing the work.

When we create Agile teams, we create teams of real, live people. That means our control and communication systems must be built around the qualities and capabilities of people, not robots. We are doing much more in a team room than simply transferring abstract pieces of metadata around about a project. We are gaining a common emotional understanding of the problems and the players, getting a deep feeling for what might go wrong and what we need to worry about, adjusting our work patterns, our communication techniques, and our problem solving skills to this particular team, this particular problem, in this particular situation. There’s a hell of a lot of things that don’t appear on the walls — but that the walls remind us of. An Agile team isn’t a team that moves stories across a wall. It’s a team that looks each other in the eye and talks about things the Product Owner wants and how they’re going to give it to them. It’s a team that munches down on hot dogs and the conversation reminds somebody of something important so they reach up to add a new task on the wall. The stories, walls, and data are all just props to facilitate ubiquitous in-person human interaction. We take the ubiquitous in-person human interaction part out of it, we’ve killed the very thing we’re trying to improve.

If you’re looking for more balance and traction in your Agile team, take a look at the book I wrote on beign a ScrumMaster.

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.