I found this bit (screenshot at the left) a couple of days ago as I was going through a Business Analyst reference. It lists some common examples of improvement opportunities that a BA is likely to identify. But I think it extends to any role, after all, continuous improvement can and should be everyone’s business. Sometimes when I’ve got time to kill at the office, instead of visiting Facebook, 9gag or other time sinks, I make it a point to think about my work and my team’s work to reflect on what can still be improved. I try to leverage on “laziness” to look for ways to do things faster or make things simpler. 😉 Looking into the common examples given in the list can be a good starting point.
Automate or simplify the work people perform.
For instance, in a previous project, there were SQL queries or Unix commands that I had to run frequently. What I did was to tie them all together into scripts so I just need to run the script and then review the results afterwards. Another example is the sharing of shortcuts or other quick workarounds to the team during our test team meetings. If there are tedious tasks – especially those that have to be performed repeatedly – these could be something worth reviewing or automating. If you come across a tool that could help you do your work faster, share it.
Improve access to information.
Consolidating references into a repository that is accessible to those who need them is an example. Another example is generating reports from our defect management tool which captured information that we had to focus on (e.g., number of days the bugs remained open). In both cases, you make the relevant information easily available to those who need them. If there are things that are hard to find or hard to retrieve, yet should be available to the team, then this could be an area for improvement.
Reduce complexity of interfaces.
For most of the tools deployed to a previous team, I prepared a README reference to hopefully make it easier for them to use the tool. Another example is creating a view for our defect management tool which displayed only the fields that were relevant. The default view displayed all fields which could look a bit daunting as there were so many columns. If there’s something that looks far more complicated than it should be, then this could be something that needs to be worked on.
Increase consistency of behavior.
In my old team, there was a tendency for meetings to start late – so folks who actually come in on time end up penalized since it’s their time that gets wasted the most. This wasn’t the consistency I wanted though. What I did was I took ownership of the test team meetings and made it a point to start on time and with a prepared agenda. Another example is preparing a set of standard test cases for checks that are needed across certain applications. Without this in place, the tendency is tester X tends to miss out on some stuff, while tester Y covers them but misses out on other stuff. If there’s something that has to be done consistently, support it by reinforcing the behavior behind it or by providing some structure to reinforce it.
In one project, a colleague and I did a review on test cases and we managed to eliminate some overlaps. There was tester X who worked on A, B, C; and tester Y who worked on C, D, E. They might not have been aware that they were working on C had it not been for the more holistic review. Another example is we had a couple of scripts that functioned quite similarly. One summed up a couple of fields from a text file, while another did the same thing but with the ability to do groupings. I asked a volunteer to merge them so that there’ll be only one script to use and maintain. If two folks are working on the same thing, then that might be a waste of effort; their energies could be diverted into something more useful or worthwhile. If you have more than one working solution, it could be worth examining whether the cost of maintaining them all outweighs the benefit.