A couple of weeks back, I became aware of a fact about electronic tools that gives a large drag to using it. I see lots of teams struggle with electronic tools. Most of the times these work with a raped bug-tracking tool used for – well, I think – status reporting towards their ScrumMaster during the daily Scrum meeting. That’s broken on so many levels – at least that’s what most team members reported to me when a particular tool was inflicted on them. The infliction usually happens either by sunken cost syndrome (“we invested XXXXX amount of money in that, you need to use it!”) or other self-imposed factors causes (“we work on twelve different planets”, “this paper thing is too touchy for me”, “we are green here, we don’t kill trees”). Let’s explore some of the reasons behind that, and try to come up with clues on why these are broken, and what I think the worst thing about these is.

Transparency

Empirical evidence trumps speculation – every single time. That is why Agile methodologies invest so much time in empirical process control. Empirical process control necessitates three key ingredients: inspection, adaptation, and transparency. You need to have transparency on your product, your process, and your current working plan on a daily basis in order to make the right decisions regarding the best actions to take next in order to inspect and adapt. If you don’t have transparency on the thing that you try to inspect, you will only receive a blurry picture, and can only improve that blurry picture. (And sometimes the best action to take is to unblur the situation.)

With electronic tools, the last thing that happens, is transparency. Usually during meetings – where transparency for inspect and adapt is most needed – there is one guy sitting in front of the mouse and keyboard, dominating the whole transparency by wildly scrolling and clicking around, or totally slowing progress of the meeting down to an unreasonable level by being the only typist in the meeting. I have rarely seen less effective ways to waste money.

On the bottom line, you get costs for installing, running, and maintaining the tool, time wasted in meetings by being less effective, and time wasted due to less transparency. Good job.</sarcasm>

Plugins

I think the great invention of our age lies in – drum-roll – plugins! You can dynamically plug in behavior to every software today. Just as you could theme everything 15 years ago, now you can plug-in anything that you need to do. That’s why there are lots of plugins for the available electronic tools. I think at a point in the future we will need a plugin to manage our plugins more effectively.

What stroke me most a couple of weeks ago had to do with a tool where there was an “Agile plugin” promising that you could manage all your “Agile work” with it. It had an Agile backlog, it had an expedite lane, it even had Enterprise Java Gems!

Funny thing, I talked to the ScrumMaster and ProductOwner after a standup about the tool. They used the Kanban view for managing their bug tickets, and the Scrum view to have an insight into the current state of the Sprint. I asked why they kept on switching between the two views, and whether there wasn’t a combined one, so that they could easily see the amount of planned and unplanned work on one page. “That’s not possible.”

A couple of minutes later into that talk, I found out that another ProductOwner in the same room had created a dashboard to overcome that short-coming of the plugin on top of the tool that was really in place to track bugs. I mean

SERIOUSLY?

The whole transparency could be solved with the customized dashboard alltogether. I am quite sure that they wouldn’t need the plugin AT ALL. Thank you for providing that piece of junk, making everyone install it, getting confused about it, while never solving any real problem.

Filters

In the end, I noticed it boils down to this: filters. A year ago I worked with a team that used a tool that was heavily using filters to provide different insights into the product backlog, the sprint backlog, and the current state of the development.

The problem was that everyone had different filters. The bigger problem was that everyone had different technical filters in combination with their personal filters. So, everyone had a piece of truth on their mind whenever they entered a particular meeting. All of them together had totally different truths. Of course, all the meetings took a lot of effort to reach a common ground for all those different truths around.

We are all facing personal filters. For example, there are certain people that I will stop quickly listening to. Most of the time that effect has to do with personal history, personal experiences with folks, and at times also my coping-stance with the signs I see in a particular person – or maybe even just how likely that guy reminds about that dork back in my high-school years.

The same goes for various tools that we use on our computer. The problem comes from different filters that distort our reality. Every filter takes away some complexity so that we can more easily deal with the situation. There are personal filters that we develop over time, and there are technical ones that we use.

While working with an electronic tool, you have two filters while working with your teammates: the personal ones, and the electronic ones. When working with a physical board, you remove one set of filter that might distort your reality from the one of your colleague. Thereby you have an easier time to reach common understanding, and fewer opportunities that lead to shallow agreements.

The biggest problem

When it comes to electronic tools, I think the biggest problems arise from the various levels of filters involved that distort our truth from the truth of our colleagues. We should be sensible for it, and we should remove the tool whenever we notice problems with it. In the long run I never faced a situation where a physical tool was not better in bringing more transparency for a better inspect & adapt cycle, had fewer work-arounds to take (think plugins), and led more easily to a shared understanding of the situation. That’s why I think that electronic tools – despite the fact they were most often built for different needs – are ineffective, and therefore useless in a fast-paced environment.

Your mileage may vary.