A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Ensuring that the tools you use are responsive and fast ..

The topic of this post is something that seems so obvious, but the problems that come up on a regular basis if the tools that one users are slow is a big issue. In the periodic retrospectives or the post-mortems that we did, the speed of using a tool was one of the biggest problems that was reported. The other big problem in this area was about recognizing that this is a subjective issue, although you can have some criteria for defining the speed. How often have you heard a team member say “This bloody tool is slow”. But, have you heard yourself also say that ?
Having a tool that is slow breaks the flow when some work is happening. But before you jump into purchasing a new tool, consider that there might be some reasons why the tools that you are using perform slowly.
– One of the biggest reasons for a tool being slow is that there is some kind of configuration issue. If the tool is web hosted, there could be some firewall issue or some other issue that is causing the tool to be slow. If the tool is located on some local server, the server may not have the power to handle the load that you are throwing at it, or there might be some optimization needed to ensure that the speed is better.
– There was a weird case where the tool would be slow for 2 hours when team members would be using it the most, and that caused a lot of problem. Solution – we did some research and found that the tool had a backup cycle that was happening at around the same time that we were using it, which was causing speed problems. We changed the time of backup to one that had nobody using at that time period (or if you are located at different geographical points, then figure out a time with the least impact). This caused a dramatic speed increase in the usage of the tool.
These were just a set of sample points to first figuring out whether the speed issue is related to some problems that can be solved before you go in for expensive upgrades or new purchases. However, if have done all of these and know that there are some problems, then it would not wise to continue with slow tools, especially for the team. Some reasons are:
– A slow tool causes an immense amount of frustration. When you are asking people to enter data into the tool, they will try and enter the bare minimum data or try to group data entry at a common time rather than enter data as and when required.
– The actual loss of productivity can be high as well. We were using a defect management system that ran off the web, and it would take more time to actually move from one defect to another rather than entering the data. As a result, when we could deal with processing of 25 defects per hour, we only managed to get around to doing around 15-16 defects per hour, which was a huge loss in productivity.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>