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.

14 thoughts on “Tyranny of the Tools

  1. Dave

    I almost fell into this trap on my first full-time SCRUM project. I looked up at all the post-its and thought, “What if a few of them fall on the floor and are lost, forgotten? Our SCRUM master’s handwriting isn’t so readable! Hmmm, I wonder if there’s a nice SAAS solution out there, BaseCamp for SCRUM…”
    Luckily, I only did a cursory Google then forgot about it, and ended up actually doing work instead of looking at tools. The project was delivered more or less on time.
    It’s always good to be fully aware of the reasons you’re choosing to use a certain methodology. Great post.

    Reply
  2. Aaron

    What I have read about work process at 37Signals and Github indicates that they have very tool driven work processes. General market perception is that their work processes are going quite well.
    Do you have any insight into what makes them different, from the teams you’re coaching? Are they just more experienced developers? Or are there more specific attitudes or processes that avoids the pitfalls you mentioned?

    Reply
  3. DanielBMarkham

    Hi Aaron,
    The one thing that nobody ever talks about is the composition of the team. Teams full of great guys make things happen no matter what system you put them in (Although they might be very unhappy doing it.)
    As another commenter pointed out, by automating, the best you can do is break even. That means that a great team using a great tool will more or less perform as before.
    But that’s an unusual situation. I’m not familiar with the companies you mention, but I have learned to be very careful about the difference between spin and reality. I’m not saying these guys are spinning you. Just take all third-party stories of wild success with a grain of salt. it’s very common in this industry (Agile) to pump-up stories of team’s success beyond what the actual team members might say if you had a beer with them at a bar somewhere.

    Reply
  4. Mark Frankel

    Daniel, I loved your article.
    As a tool maker for schools and non profits, it’s an important insight that a purpose of tools can be to communicate and not necessarily to enforce a process.
    However, it is important to point out that in some situations, perhaps not in agile, an enforced process can bring good results.
    I’ve worked (and still do some business) in corporations for over 25 years and I mostly live in the start up community these days. Your lack of familiarity with 37 signals and Github show how far apart the corporate and start-up communities unfortunately are.
    The start-up community takes your ideas one step further. They are agile and focused on delivering a product to a customer that wants it. The main difference is that they have a different set of processes to achieve that goal, summarized well by Eric Reis in his book The Lean Startup.
    I would highly recommend you take a look at http://37signals.com/about and at their books Getting Real and Rework.
    You can benefit greatly from seeing what might be beyond Agile and introducing even leaner processes into the corporate world.

    Reply
  5. DanielBMarkham

    Mark,
    Thank you for your kind words and gentle chiding. As it turns out, I’ve been a huge startup fan for several years now. I read Eric’s book almost as soon as it came out, and I have a site dedicated to sharing tools for startups, I firmly believe that the Agile community has a lot to learn from the startup community — and vice versa.
    What I found especially funny was your assumption that somehow I come from the corporate world. Yes, my clients are mostly corporations which want that small-team performance. But I spend much more of my time with my own startup than I do with BigCorp.
    As for my familiarity with 37Signals and such, let’s just leave that one alone. I don’t want to be in a position of attacking them — they’re great guys — and I don’t want to put you in the position of defending them — I’m sure they have faults, as we all do.
    Thanks again for the comment. And for all those Agile readers out there, Mark is dead-on: learn you up some lean startup goodness. Startup guys have been working in small cycles to provide immediate value for at least as long as we Agile wonks. Lots of great stuff going on over there — it’s where I spend all my time.

    Reply
  6. James A Rosen

    What do you suggest for widely distributed teams? Does each person keep their own storyboard in their office? That would certainly give each developer the benefit of seeing the tasks. Unfortunately, it means that there’s no visibility. Nobody else — not the project manager, not the other developers — can see the status of tasks.

    Reply
  7. Mark Frankel

    Daniel, It’s great that you have your feet in both worlds.
    My funny assumption that you didn’t came from your statement:
    “I’m not familiar with the companies you mention”
    Which led me to believe that you weren’t actually familiar with 37signals which is pretty unheard of in the start up community.
    And the fact that you work in the Agile “industry” led me to believe that you have corporate clients.
    No blood, no foul, and it just proves your thesis that tools (like this blog) are no substitute for being in the same room together. Hopefully some day I’ll have the pleasure of meeting you in person.
    Thanks again for your insights!

    Reply
  8. Matthew Skelton (@matthewpskelton)

    Daniel – very well characterised.
    We only have to look at the success of Etsy to see how much humans need/want to make things by hand and interact with the “real” and bespoke rather than digital or generic.
    Ask any experimental psychologist whether they think humans would be as capable without being embodied, and most would give a resounding “No” in reply.
    The act of walking to a physical board to move a post-it to complete a task is likely an important part of the process, which clicking a link in an online tool can never replace.

    Reply
  9. Stefan

    I think you are right and wrong.
    Some tools are only there to make people busy instead of productive. But when tools make stuff more accessible (online/mobile apps) or give you more information without searching (context) they can help you doing your work. For example github give you issues and a code commenting tool that make it easy to work together. You have all info in one place, online and this tools are not blown up with stuff you don’t need.
    I believe my computer is here to do ugly stuff for me and help me to collaborate. That’s why I wrote a tool to automate all other tools used in software development. Because most workflows can be fixed.

    Reply
  10. Sebastian

    A timely post as we finish our sprint next Tuesday and will do a post sprint review.
    This is sprint seven and at the end of each sprint we ask the same question.
    Should we switch to using the supplied Agile Tool or do we stick with the spreadsheet?
    So far the main concern is always, we know how the spreadsheet works, it’s hosted so we can access it concurrently and remotely, its really quick to update. Oh and everyone, client, management and code monkeys can access it.
    So every time, despite the wonderful automation, tracking and reporting, we could have at our fingertips the spreadsheet survives for ‘one more sprint’.
    Reading the blog above makes me think that it’s survival is probably no bad thing after all.
    It’s a spreadsheet because parts of the team are away from site for four or five days at a stretch and it allows them to quickly update their ‘progress’.
    yes I think our ‘low-tech’ spreadsheet will continue to serve us well.
    Cheers
    Sebastian

    Reply
  11. Michael Dubakov

    Argumentation is valid, but there are exceptions:
    1. Distributed teams in different locations
    2. Large teams (which is quite often equals to distributed teams)
    3. Visibility and statistic. Yes, sometime you can remember why this took so long, but you can’t reveal hidden patterns and problems without data.
    The top problem of many agile tools is that they are quite rigid. They force you to follow their way, while you have your own way. SO FAR there are NO tools on the market that are flexible enough to suit everyones needs.
    No-tool approach works great for small teams and small companies. I don’t think it is a viable option for all.

    Reply
  12. DanielBMarkham

    Michael I think we completely agree.
    My discussion was limited to a co-located team working in a common area only. I also pointed out that the tools are very good for communicating, especially with large and distributed teams. They just easily divert us and distract us from the actual work that happens inside the team, and that’s what makes them so bad.
    As far as statistics, I didn’t go into that. Anybody who is interested in release planning and organizing longer and larger efforts quickly needs some form of record-keeping and statistical management.
    Even then, I’m not sure how much buying something off-the-shelf helps or hurts. I’d argue that you could run up to 50 or so Agile teams just using ad-hoc statistical tools. More to the point, that if everybody had a role in developing and using these tools, you’d get more usefulness out of them than if you just bought something and tried to plug it in. That’s because the organizational conversation around just what you need and what you are going to do with it is like a thousand times more important than simply having a feature available.
    Too many times tool vendors purposely confuse the tool and the process. If you spend a million bucks for an Agile tool, you are nowhere nearer being Agile than before you spent that money. In fact, in most cases you’re actually going in the wrong direction. Your focus is on exactly the wrong spot.
    Thanks for the comment. As you note, it’s important to understand that I’m not making the case against all tools. Instead, I’m pointing out that you need to have a healthy relationship to the tools you decide to use. And everybody that’s bigger than just a couple of teams ends up doing something with tooling. You have to in order to communicate. If you are one of those that absolutely has to have Super Agile Tool 2000, then that’s perfectly fine. Start with a very minimal configuration, enter only the barest data possible, concentrate on using it for communications and statistics, and go very slowly. That’s all I’m saying. The tool you focus on the tool and “implementing” it, the more you are actually hosing up your Agile adoption.
    Somehow I think this post probably disqualifies me from working for a lot of cool Agile tool vendors in the future. Oh well. Most of the good ones will tell you this stuff anyway.

    Reply
  13. Pingback: Agile Tools and the Importance of Physical Interaction | Matthew Skelton

  14. Pingback: On Agile Tools

Leave a Reply

Your email address will not be published. Required fields are marked *

* Copy this password:

* Type or paste password here:

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>