No Wonder Agile Guys Shun Tools

I’ve seen a lot of attempts to convert Agile whiteboards like this into software…


And, in my opinion, they’re all crap.

Here’s an example:


Sure it looks nice. And looking nice is what fools you into thinking that it does something useful, when in fact it doesn’t. It adds absolutely no value to the manual whiteboard that you can’t get from an Excel spreadsheet, or a simple list in Notepad, and it removes a vast amount of value.

No wonder Agile guys shun software project management tools.

How did I come to realize this?

Because I built that nice looking screen as a prototype exercise for our Exia Process product. You can read about the ideas behind it here. I even got excited about it when a software guru friend of mine whose opinion I respect a lot, Barry Gervin from ObjectSharp, said it was fantastic. We both fell into the same trap of thinking that what we were really onto something not only cool and slick, but useful.

So what’s the problem?

The problem is what’s not there. And that, it turns out, is a great deal. Enough to drive the more hard-core Agile guys crazy trying to convince software tool guys that software project management tools should be banned, that they make Agile projects run amok, grind to a halt, go off course, and all manner of bad things.

I know because I’m one of those software project management tool guys, and I’ve seen firsthand an Agile guy go a little crazy at some of my suggestions for tools.

Trouble was, the Agile guy couldn’t tell me exactly what the problem was with the tools. So instead he made up some random stuff, and that convinced me he really was out in left field. Just another newborn Agile Manifesto evangelist spewing radical nonsense, I thought.

Sound familiar?

So I built my little prototype, convinced myself I was going to own the Agile tool market inside a year, and started playing with it.

Well, the experience really sucked, and it taught me a lot about the differences between tools and real life, what we tool guys should be trying to model and what we should not, and as a side note, why Apple is on the verge of global domination.

But I digress. Let’s get to the list of what critical information and features are missing from my prototype. Just what exactly does the whiteboard have that the tool doesn’t?

  • You can tell whose card is whose with a glance.
  • You can see the complete history of each card’s edits at a glance.
  • You can tell who made what edits by the handwriting.
  • Important things are bolded, underlined, or otherwise highlighted.
  • Unimportant things are small.
  • You can tell the age of a card by how worn it is.
  • You can prioritize by rank and by iteration with a single move.
  • You can move two cards at once (swap position).
  • It’s big enough for two or more people to discuss over. You could fit three to five. Try that at a monitor.
  • It can accommodate “extras” in the form of stickers, stars, fridge magnets if you have a metal board behind it, tacked on notes if it’s cork.
  • You can merge two stories by overlapping.
  • You can split a story by ripping the card in two.
  • A story can overlap an iteration border and you can have an agreed meaning for that.
  • You can delete instantly.
  • You can add nearly instantly.
  • You can undo any number of deletes.
  • You can stand up in front of it, which gets you up and gives you energy.
  • You can put things in the space around it.
  • You can hang a bottle opener off it.

… and so on, and so on…

The number of nuances that the physical Agile board has just goes on and on, and each nuance conveys some kind of information about the user story, the iteration, the project, or the team. It took me five minutes to think of 20. I’m sure there are another 20.

And to me, that’s 40 good reasons why Agile guys shun software project management tools.

About these ads

About nigelshaw

President of Exia Corp., Software Engineers.

View all posts by nigelshaw

Subscribe

Subscribe to our RSS feed and social profiles to receive updates.

27 Comments on “No Wonder Agile Guys Shun Tools”

  1. Dave Rooney Says:

    I agree wholeheartedly… except when the team isn’t all in one place. I’m the first person who would ask, “Why aren’t they in the same place?”, but as Agile moves into the mainstream we have to accommodate for less than perfect scenarios. In that case, your tool has value. I’ve worked with a couple that are OK, and played with several more. None have the same feel as stickies on a board.

    What’s interesting, though, is research like this:

    http://www.ottawacitizen.com/technology/Tech+explosion+just+touch+away/2695437/story.html

    …and this:

    http://www.microsoft.com/surface/en/us/Pages/Product/WhatIs.aspx

    I think there’s a future for these sorts of “virtual tactile” tools.

    In the end, though, face-to-face at a whiteboard or task board is much more effective.

    Dave Rooney
    Westboro Systems

    Reply

  2. Alan Cooper Says:

    Your list of missing attributes is excellent. However, all of those attributes could certainly be programmed into a software project management tool.

    There are only two problems: 1) It’s a lot of work to code up all that complex behavior; and B) It’s extremely difficult to make that complexity easy to learn, understand, and use in a GUI presentation.

    That’s why real-world interaction design is actually pretty difficult to do well.

    It sure would be great to have software that did all the cool things that software can do AND have it designed well enough to do all of the cool things that humans with pencils and postits can do. All it takes is good design, good programming, and lots of hard work.

    Reply

    • Vineet Sinha Says:

      Alan,
      Great points. It is just that we have not had many people who did the hard work needed to build such systems.

      Perhaps the challenge that we really have is that most software developers build tools only for their own needs. It might be the case that all we need is some teams building tools thinking about the developers who would be using it – including how easy it would be for them to learn and use all the features.

      Vineet Sinha
      Founder, Architexa (http://www.architexa.com)

      Reply

  3. nigelshaw Says:

    Thanks Dave. Yes, having an electronic version of the user stories has many benefits. We’re thinking very hard about how to manage that. The simplest solution, and the one we’re implementing now, is to make it so easy and fun to maintain the electronic version that one can maintain both. Updates from the physical board can be transferred to the electronic board in just a few minutes.

    Next, WPF and other highly graphical technologies make it possible to simulate real world artefacts much more closely. Suppose the electronic notes could age, stains appear, edges curl, etc. Suppose you could twist or adjust them a bit, move them across boundaries, move them out of the board area completely. Suppose you could stack them, rip them, scribble on them, stick various types of stars, pins, and accessories on them. Let’s say you could write on the board itself behind the user stories. We’re working on these ideas, but implementation is expensive and the devil is in the details.

    One thing that we almost surely will be doing is adding virtual electronic whiteboard capability. You will need a projector. We will supply a small infrared sensor, actually a modified WII game sensor, on a stand mount. You will be able to point the sensor at the projected surface and that surface will become electronic, so you can drag, move, write and so on, with a small IR pen that we will supply also. You can see this working here:

    Reply

  4. Siddharta Says:

    Well.. yes.. and no. Whats stopping anyone from decorating the electronic cards with details like colors, shapes, borders and patterns to highlight various things. Nothing says that the electronic card should be a flat yellow square with just the name on it. Now we develop kanban tools, so I have a certain viewpoint on this, but almost all the things you mentioned can be done electronically.

    Where physical really shines is that its big, its visible and so people tend to interact with it a lot more. You cant miss it as you walk in and out of the team room.

    All the ease of use, moving things around, colors and annotations… electronic can do that. Its the big, visible aspect that is not so easy. Teams using electronic boards can try to put up a big touchscreen monitor on the wall (or something like the video above). It’s not enough to just have it online and hope people log in from the desktop. Out of sight, out of mind!

    Reply

    • nigelshaw Says:

      Yes, I agree Siddharta. Thanks for the comments. I just had a look at your site and I see your feature: “Responsive tactile interactions, patterns and colors provide new insights that regular tools can’t.” So we are definitely thinking along the same lines. I see you have a whiteboard implementation under development and I’ll be very interested to see as you implement some of the more subtle features. Frankly, I’m scared of the cost at this point. We use WPF which is very powerful graphically, but still, getting the details right… It will get done eventually by someone but it will take time don’t you think?

      Reply

    • Brandon Carlson Says:

      You forgot one of my favorite features of physical boards. If the card hasn’t been touched in months and falls off the board underneath a filing cabinet we’ve successfully cut scope! :-)

      Reply

  5. Ian Chan Says:

    Great summary of your findings, I appreciate it. I am an advocate of a physical board, use one at my office and it helps out with the process significantly. Sometimes you just can’t replace a physical sticky with pen and scribbles on it.

    Also its a matter of visibility. It is so easy to minimize an incomplete project board when you don’t want to see it. Having a big board, in clear sight, allows others not on the team or project to even glance over and see how things are going. Again, great summary/findings

    Reply

  6. Vineet Says:

    Good points… And I am really glad to see this point being raised. But there is something important that you are not addressing:

    While the tool does not have a lot of things that the whiteboard does, the tool can provide other benefits. Most of the time these other benefits are not large and at other times the other benefits are hard to figure out, *but* thinking about these benefits and providing for them can really help software teams. And perhaps moreso than just trying to provide for all the benefits that are available in the real world.

    Vineet Sinha
    Founder, Architexa (www.architexa.com)

    Reply

  7. YvesHanoulle Says:

    I’m one of the agile people that think you should start out with a whiteboard and only when really necessary move to a digital board.

    Your list misses some important facts,
    -the interaction with a physical whiteboard.
    -the in-your-face of a whiteboard
    -it’s easier to change your process with a whiteboard

    A) One way to have a good standup is to make sure people manipulate physically the whiteboard. I can’t explain what happens, but somehow the energy is different when people are at the whiteboard and use the papers.

    B) Something that seems to happen with digital board is that people ignore the
    board. They don’t go to the website, they don’t care about the data etc; With a whiteboard that seems to happen less.
    One reason is they see other team members update the board during the day.

    C) Whenpeople have set up a digital board, they seems to bother reconfiguring it, even when the process needs to change. With a whiteboard that does happen, but at much smaller level. This is especially important in the beginning of anew agile team that is still trying to figureout how they want to work.

    If you can’t make it work on a whiteboard, it won’t happen with software.

    I have been there,I have used all kinds of tools.
    My advice to new agile teams:
    Start with a whiteboard, when you know how you want to work you can go to a digital board; Most teams then realize they don’t need it.

    @Dave: I hear you about distributed teams: and even there it is wurth trying wthout a digital board.
    http://www.hanoulle.be/2009/10/how-to-work-with-a-whiteboard-with-a-distributed-team/

    Reply

  8. nigelshaw Says:

    Yves, you raise some great points! Especially your point about people “caring” about the data. It’s true, people care about physical, personalized cards a lot more than they do about data. That’s one of the things we’re working hard on with our software… how to make it personal. Apple is doing a phenomenal job of this. One of the obvious things we’re going to be doing is releasing an iPhone and iPad app, so you can view and work with things like user stories with that great personal experience you get from the iPad. But that’s only part of it. No doubt we need to always go back to a core respect for the manual system and to keep asking ourselves whether the software is contributing value in a meaningful way.

    Thanks for posting.

    Reply

  9. Maurice le Rutte Says:

    Tools seduce you to work in the way the tool works – not the way you should work. Tools do not magically solve the underlying problems like communication. People start using tools too soon. If it doesn’t work they are likely to blame the tool or blame the participants. Without tools you have to focus much more on the conversation.

    I’ve blogged about some of this on http://www.scrummaster.nl/2009/11/14/scrum-tools/

    Personally, I wouldn’t want to do without a tool :-)

    Reply

    • nigelshaw Says:

      Thanks Maurice. The balance between the Agile process and the tools is really the essence of the problem wouldn’t you say? At Exia we’re focused on this balance a lot. I think everyone would agree there’s a place for tools, but how much tooling, at what point, and what for? We’re experimenting with ways to design the tool that offer more flexibility in the way you use them. But that’s not enough, because as you say, people will start to go down the tool path too soon. So we’re hoping we can develope nuance or detail of the tool UI that helps alleviate that problem.

      For instance, why don’t people get carried away with detail on a 4×6 card? They just run out of room. So creating a software system where you can type endlessly on the card perhaps invites the type of behaviour you’re referring to. People will start go down the tool path further than they would if the tool had the restrictions of the white board. It’s another characteristic of the white board approach we can add to our list: “The white board restricts the amounts of content.”

      With that thought in mind, we can probably think of many other ways that the white board is restrictive, and where those restrictions are good things that help the Agile process stay on track. So the software should perhaps be equally restrictive if it is to be successful. This highlights the problem we’re focused on at Exia… why don’t Agile and Microsoft Team Sytem get along? Because Team System has too many fields and places so few restrictions on what you can do. It’s an odd paradox… the paradox of choice.

      It’s the same reason we sometimes long for the days when there was just Crest and Colgate, and you picked one or the other and got the heck out of the supermarket a lot faster! Nowadays the Agile team wants the toothpaste that does the least damage to the environment and is the most healthy, while the development team wants the one that brightens your teeth, freshens your breath, disinfects your gums, combats gingevitis, and gets the girl, all at the same time! Amazingly they sell that exact thing.

      The difference in the problem space is this: software is expensive and toothpaste is cheap. If toothpaste cost the same as software and we had to make a collective decision we’d be stuck in the aisle for a week!

      Reply

  10. Tim Green Says:

    Best of both worlds – use a software tool to print out the tasks and stick them to the board!

    The developers get the tactile pleasure while the project manager types get the digital burn down charts.

    Reply

  11. YvesHanoulle Says:

    @Tim: having the developers create the burn down chart, makes them relise much more if they are going to make it or not.
    Having a digital burndown chart, won’t help them.
    (It wil only make a project manager type push/pull them more)

    Reply

    • Maurice le Rutte Says:

      A project manager type will push/pull regardless of the level of toolingness. I also have seen people work very nicely with digital burndows. So as always… ‘it depends’

      Reply

  12. Mark Levison Says:

    An interesting post – I will feature in an upcoming Agile Quick Links. As good as you make a tool displayed on a screen, it will still suffer from the problem that no one looks at the webpage very often. People walk past a physical story board many times a day, during standup they can touch the stories they worked on. Finally when someone comes up with a bright new idea for the board you implement it minutes with tape, PostIt Notes and white board marker.

    I wish you all the best with this project – it sounds like you have the right spirit.

    Cheers
    Mark Levison
    Agile Pain Relief Consulting

    Reply

  13. nigelshaw Says:

    Thanks Mark. Much appreciated.

    Reply

  14. Carroll Snow Says:

    Haha I’m really the only reply to your incredible read.

    Reply

  15. http://hbskmedia.com Says:

    hello there and thank you for your info – I’ve definitely picked up anything new from right here. I did however expertise some technical points using this website, as I experienced to reload the website lots of times previous to I could get it to load properly. I had been wondering if your hosting is OK? Not that I am complaining, but sluggish loading instances times will often affect your placement in google and could damage your high-quality score if advertising and marketing with Adwords. Anyway I’m adding this RSS to my email and could look
    out for much more of your respective interesting content.
    Ensure that you update this again very soon.

    Reply

  16. exporting olm to pst Says:

    If some one wants to be updated with most recent technologies afterward he must be visit this website and be up to
    date every day.

    Reply

Trackbacks/Pingbacks

  1. Tweets that mention No Wonder Agile Guys Shun Tools « Nigel Shaw's Blog -- Topsy.com - April 27, 2010

    [...] This post was mentioned on Twitter by Kevin E. Schlabach, Bonnie Aumann. Bonnie Aumann said: And one of the frustrations distrib teams face RT @kschlab No Wonder Agile Guys Shun Tools (yes, yes, and yes) http://ow.ly/1DF7C [...]

  2. uberVU - social comments - April 27, 2010

    Social comments and analytics for this post…

    This post was mentioned on Twitter by kschlab: No Wonder Agile Guys Shun Tools (yes, yes, and yes) http://ow.ly/1DF7C

  3. uberVU - social comments - April 27, 2010

    Social comments and analytics for this post…

    This post was mentioned on Twitter by davenicolette: RT @duarte_vasco: Tools enforce crappy processes: RT @most_alive: RT @ipreuss: bookmarked: No Wonder Agile Guys Shun Tools http://bit.ly/b4899a

  4. Agile Quick Links #14 – nemrac.com - May 6, 2010

    [...] Shaw writes: No Wonder Agile Guys Shun Tools in it he lists some of the many ways that agile tools fail in their attempt to mimic whiteboards. I [...]

  5. 敏捷社区对使用工具过于敏感 | chainding - March 21, 2012

    [...] 但是坚持使用索引卡片、白板和面对面沟通的敏捷人士,他们强调使用这些工具和技术的好处胜过使用软件工具。关于实物敏捷看板和软件工具哪个更好,Nigel Shaw在2010年写过一篇文章,在细微处对比了实物看板和虚拟看板,介绍了使用实物看板比之软件工具具有的优点。他列出了一份清单: [...]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: