Some Innovation

Some years back, when I was leading a team of testers, there was this talk of adding even more value to the client by providing even better solutions in lesser duration leveraging the vast collective knowledge on the domain and innovative solutions which will result in increased productivity and a faster delivery of an outstanding solution. So I thought that I will also do my bit. It was not all that self-less also. I needed to have something to put as my contribution to the team, outside my stated scope of work. So, with this in mind, I thought about automation. Most of our projects included a functional testing of the solution which is developed by the team. Since we have no automated testing tools with us for the green-screen environment, the testing folks spend a considerable amount of time to manually navigate across screens, input the data values, take the screen shots, navigate to the next screen, input the values, and compare values across screens and repeating the same stuff over and over again as per the script. I realized that input of data and capture of screens were totally non-value adding activities and they were the ones which took considerable amount of time while executing tests. With some research on the web I figured out that this can be automated. I discovered the PSL (Powerterm Scripting Language) which can run on the Powerterm emulator and do most of whatever I wished to automate as per the commands. After 2 days of digging into it, I developed about 5 generic scripts to take input values for different functionality of our application, take screen shots in word documents as per the navigation rules specified and so on.

Jubilant on my discovery, I sent a mail to everyone in the team about this new way of doing things which could save innumerable dog hours of effort. Some people also stopped by my desk to figure out what I was talking about. Some of them were impressed. I thought that this thing was so good, that if everyone in the team took upon themselves to develop at least one such automated script, we can reduce our long hours drastically. But nothing of that sort happened.

No one was interested to learn it. As time went by, some of the team members approached me to automate certain of their activities. There was a request to post about 500 transactions. Someone wanted to change the names of about 100 account holders. Someone wanted to take about 600 pages of screen shots and they would come to me and ask if that could be done. I would belt out a script in an hour and then their job would be completed in matter of minutes. For example, the 600 page screen shot job took just about 44 minutes to complete, whereas it would have taken days if the person would have manually taken the screen shots. However, with all these benefits, still no one wanted to learn how to prepare these scripts! I am still thinking why it turned out this way. May be people were averse to change! But one thing I learnt is the need to publicize whatever one does so that people around you take cognizance.

On Processes - Part IV

Let us take a break here. What was going on? The team definitely had some process. Even though it was not well documented, still the team members followed them. People were accountable. They were responsible for their part and the product manager used to get the work done at the end of the day. But what was done wrongly was, the big bang way of introduction of process / methodology, which senior management felt was conducive to product development. Also the senior management was not certain what it wanted and was probably doing a lot of experimentation. Again, the same was not being followed through. Thus nothing much was achieved. What could have been done is to document whatever process the team was following and make minor changes to the same so as to formalize the same. Since the team was anyway following the processes, it would not have had the resistance to it. The next step would have been to introduce minor changes into the process and mandate collecting metrics. Continuous smaller changes over a period of time would have achieved all the objectives which the senior management failed to achieve with big bang changes. Now, had it been a new team which is being formed, big bang changes will work as no process would have been institutionalized.

On Processes - Part III

Then someone in the senior management said that the product team is eating up too much of cash. Let us figure out a way to measure how much value the company is earning. The Earned value method was rolled out. Product managers were expected to find out the EV for their product. Till that day, they were used to track projects through excel. Now they had to use Microsoft project which was mandated by the company. So be it. Weekly and monthly reports started to pop out with the EV, BCWP, ACWP, ACWS figures etc. These were Greek and Latin to many. Many of the product managers just figured out how it is calculated and mechanically found the same by taking the figures from Microsoft project. There was no value add. Very few people knew how to interpret it. Even if someone interpreted it, it just told how you are doing. It didn’t tell where you have messed up. Our development team still persisted and kept on rolling out releases, may be slightly behind schedule.

Then the EV fad also worn out and the senior management declared that the company is going to adopt a new project management software. This will be an integrated software which will take input from each of the team members on the work they actually performed. So this also kicked off.

On Processes - Part II

Thus a QA person was assigned. He started to ask various questions on why this was done this way. What are the processes being followed. Where are the metrics. The product managers thought that this person was kind of intruding on his domain. He felt that he need not be answerable to the QA person. The team leads on the other hand told that they have been doing things in their own way, which they said is the process. But when confronted with the question of metrics, they asked what are the company guidelines on collecting metrics for product development. Since product development was not the forte of the company, there we no models developed for the same. So senior management thought, it would be good to have a methodology for product development and a team was formed to work on it. In the mean time, our development team continued to work in their own way. Processes to be followed were hand-me-downs through word of mouth. Same anarchy ruled. But each and every milestone was being met. Hence no one bothered.

On Processes

It was a happy go lucky team. They were working on a software product, which had been acquired by the company. The product functionality was complex but the team had some heroes who had managed to pull it along each of the major milestones defined by the powers to be. There were some rules and regulations to go about everyone’s work. Some basic work habits which every one of the 35 odd team members had in a way reflected on the processes they followed. Oh Yes, the company had a complete website dedicated to different software methodology to be followed. It was created when they wanted to be a SEI-CMM level 5 organization. All employees were given courses and training sessions on the same and this site was regularly updated. But as per the hit counter on the site, it was rarely accessed, except by the process management team which set up the processes. So our team worked on, doing their work, which was not well defined in the process website, but clear in their mind. Then the senior management thought that it would be good to have a process quality assurance personnel oversee the work going on in this product development environment.