On My Love-Hate Relationship With Tools

I don’t hide the fact that, given the choice, I’d rather have my feet swapped out for frying pans, than have to use Agile “management” tools. I make it clear to the teams I serve that nothing really beats what we’re finely tuned to be good at: face to face encounters. I keep away from software tools when it comes to working within the Scrum framework.

This resentment began, I think, when I was introduced to Jira. (My recall is foggy because my brain has put a lot of effort into erasing that moment.)

I was in the throes of becoming a Scrum Master, and was feeling particularly excited about the prospect of using big whiteboards and PostIt notes and marker pens and magnets. In fact, I may already have started using them. I’m not sure.The company I was employed by was rolling out Jira as a means of not only tracking defects but, God forbid, sprints.

No matter how hard I tried, at least one team refused to move to a physical board. It was a team of three, and they sat next to each other no more than 1m apart. Yet they insisted on using Jira to keep themselves updated. And just half a metre from them was a shiny new whiteboard on wheels, ready to be drafted into action at the drop of a hat. I’ve no doubt they probably used Google Talk to chat to each other too.

“Individuals and interactions over processes and tools.”

Tool usage in itself may not be a problem, but the tools themselves restrict us. For example, in the same company, the Product Owner wanted to see how the team was doing with her stories. For the aforementioned renegades, we had to arrange a Jira login ID (but we’d run out of users so had to boot someone off to make room for her) and then train her in how to use the tool. I’m not convinced we’d bought into Scrum’s “information radiator” ethics. Information coolers, more like.

But the issues aren’t just around visibility. I’ve used other Scrum tools that absolutely insist upon the users entering estimates against stories. But if you’re working with a team that has moved beyond estimation, the tool becomes unusable. The workaround? Type in any number against the estimate. This is fine for the developers, but I had one case where the stakeholders also had access to the same software and they raised concerns about the velocity of the team. The software told them that the team was going to be late on delivery based on the numbers they’d punched in. I’ll repeat that. The software told them. Not the team. Not the Scrum Master. But some software.


Physical boards give you the freedom to modify your way of working without waiting for a change request to go through to a team of open source developers spread across the globe. For example, I’ve recently been using Taiga. It’s a great looking bit of software and really easy to use. But hold on, what happens when you want to close a sprint? Well, normally, you’d make a note of the stories that didn’t reach Done, maybe note also the ratio of stories Done vs not Done, and close the sprint. But Taiga operates on the policy that a sprint closes when all the stories are Done. Until then, the sprint can’t be closed. OK, so I’d love my teams to get all their stories to Done. But in reality, this doesn’t always happen In fact, Scrum works on priorities, so sometimes you half expect the stories near the bottom of the sprint to not get finished. C’est la vie. Taiga, instead, operates on the fallacy that teams will get all their stories to Done. Always. The solution? At the end of the sprint, you have to move all off the not-Done stories out of the sprint and back into the backlog. The sprint then closes. Oh, but now the tool will tell you that you completed 100% of your stories in that sprint, which was zero. Gah!


Recently, I’ve found myself acting as Scrum Master for a team that’s located about 200 miles from me. I’m using agile management tools. It makes me feel a little dirty, but the team is getting some use from them. We were using Taiga (see above) with some manual note taking thrown in to cater for its restrictions. I can live with that for a while. But what about retrospectives? This is an area that I really enjoying indulging in. But that’s when I’m in the same room as the team, reading emotions, watching body language and, in many cases, veering wildly off course to cater for something crazy that pops up during the exercise. With a team that’s 200 miles away, I had to revert to tool usage again. I scoured the web for a cloud-based retrospective tool. I found some. I tried one for two retrospectives. It worked. But boy, by the end of each retrospective I was exhausted! Why? Because I had imagine the feeling of the remote room; I had to work hard to listen over VoIP to gauge the sentiment of the team. It was very very hard work. The tool allowed us to type things within certain columns (like Mad, Sad, Glad) but what was missing was that human touch. The unsaid.

I don’t blame the tool for this; it was making a good job of a less than desirable situation. But boy would I have preferred to be there, in the thick of it.

So, I’m no tool playa. I’m a hata. Word.

2 thoughts on “On My Love-Hate Relationship With Tools

  1. Hello Andy,

    we are (or were) in a similar situation here: I am the Product Owner of a team that is co-located 250km away. (Actually I am currently sitting in a hotel, because every sprint, I drive there for one day for Review, Retro and Planning on the same day.)

    And I wish for more tools.

    I am the kind of Product Owner that collaborates with the team on stories, before and during a Sprint. I want to be in contact, give feedback on results immediately, be available for questions, and keep up the Product vision and the business’ needs to help find the best Design and Architecture to meet those.

    I want to have a few conversations every day with the Devs, do some watercooler chatting, share insights, hear their latest discoveries.

    I’d love to use something like Sococo or some other virtual collaboration tool with crisp voice, good video and easy Screen Sharing for this, but instead I am refrained to Jira comments, (disrupting) phone calls and TeamViewer (“Uhm, what was your Meeting ID again?”).

    What I mean is this: If you are not co-located, or maybe even if it’s just the other floor, going full-out digital may be the best solution that stick to half-ass digital and half-ass in-person.

    Would love to hear your opinion and experiences on this.



    1. Hi Daniel,
      It sounds like you’ve been through something similar to me. And yes, I agree; some sort of tool to facilitate remote scrum mastery would definitely be essential in these scenarios. This is why I resorted to Taiga, for example. Of course, this was also backed up by phone calls. We did Skype too, which helped when trying to make a human connection with the team members.
      I think where I struggle is when tools are used regardless of location, even with co-located teams all sat within a couple of metres of each other! One of my clients has abandoned their scrum board, only to replace it with Jira on a massive monitor directly above the old physical board! Basically, they’re not getting anything extra by using the tool, and the immediacy of the physical scrum board (as an information radiator) has disappeared; the monitor cycles through other screens, so there’s no at-a-glance view of the how the sprint is doing.

      Thanks so much for commenting; it’s great to hear from others!


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 )

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