|
|
The topic for this post came up from a recent discussion that we started having. The managers of the team were astounded when, at yet another weekend, when members of the team were called for work (since yet another milestone was approaching), almost 90% of the team came up with excuses individually, and finally, the managers were shocked and decided to not call the team for the weekend. This particular episode led to some soul-searching about what is the right thing to do, and what this mean for the future, since the team is in a group which believes that hard driving is something that is part of the job.
So, there was a discussion that was animated about the reasons, and whether this is part of a trend. This was also true because overall, one could see that the number of leaves that people were taking had also increased (people never seemed to be able to fully use up their leaves, would go in for cashing in of the remainder of the leaves, and now suddenly, we had more cases of people having to be docked part of their salary since their leave balance was getting to be very high).
Following were some of the points of the discussion, and what we ended up concluding (and if employees / managers of other companies are reading, and are in a familiar position, do let me know through comments, since we are looking at modulating some of these points and seeing whether there is something we are missing).
There was an immediate conclusion that probably we were pushing very hard. Around two years back, we had got some feedback from top management that analysis had shown that our group had a productivity level that was in the lower half of the company, and this was hurting revenue (and also hurting margins, which is a big issue). Based on this, there had been some changes in middle management, with more aggressive managers drawn in, who proceeded to light up a fire. We actually called several meetings of team members to show them data, show them the analysis about costs and revenue, and compared this with other groups and across the industry, always with the unsaid announcement that such lower productivity levels cannot go on, and the company might be forced to go in for harder steps.
We started monitoring data around productivity much more closely, and there was a realization that we needed to see multiple quarters where the productivity levels of the group went on increasing. Hence, managers were pushed to keep on pushing their employees, and for some time, people kept on working with this trend, since the information about the previous low levels of productivity remained in their mind. The attempt was to use this information to push the group into a higher performing group within the company, a group that would star appearing in company reports as a group to emulate, the one that would win awards within the company for its performance.
And, this worked. People were pushed for their performance, people were pushed to do better, were pushed to spend more time on getting things done. Maybe, the rush to make these changes went without a check limit, since the team started feeling strained, and you could see people getting more listless, less enthusiastic when somebody suggested that there was an immediate deadline around the corner that had to be met.
Will continue this in Part 2 ..
| Outswim the Sharks: How to Quadruple Your Team’s Productivity with Kindness |
How to Unleash the Collaborative Genius of Teams for Increased Engagement, Productivity, and Results |
Visual Meetings: How Graphics, Sticky Notes and Idea Mapping Can Transform Group Productivity |
|
|
|
In previous posts (bug ageing and processes), I have been talking about the importance of bug ageing, and in the previous post, I talked about some of the reasons for tracking bug ageing and ensuring that bugs do not delayed in terms of when they are finally seen by the development team. In this post, I will talk about more reasons for ensuring that bug ageing is critical to monitor for the team:
- Morale. We have found that it makes a lot of difference to the overall morale of the team, and specifically of the QE members of the team. Consider the case where a member of the team does his / her job, finds bugs and like anybody else, expects that those bugs will be seen. However, when a number of bugs are not seen for many weeks or months, the QE starts feeling dispirited. In one particularly bad episode, we had a situation where as many as 30% of the bugs were only getting looked at after around a month. The QE manager was finding it hard to control issues of morale where the QE team started feeling that their work was unimportant, and even regular assurances were not making any difference. You have a happy team and good team dynamics when team members feel valued and feel that whatever work they are doing is respected.
- Attrition and bugs devolving on other QE: We felt this most critically in a couple of cases, at a time when attrition rates had gone up. In such times, for some critical bugs, by the time that the Dev team members had started looking at the bugs, they found that the QE who had filed them had actually moved off the team, and the time it took to resolve these bugs was at least double the time it would have taken if the original tester had been looking at the bugs, rather than somebody else who had to go by the steps and assume that whatever was written was the correct sequence in trying to reproduce the defect. This problem has led to bugs not being found again when they were attempted to be reproduced.
Based on the factors described in this post and in the previous posts, it should be clear that bug aging is an important factor that any development team should take into account as part of their bug tracking processes.
| Software Testing |
Lessons Learned in Software Testing
|
Introduction to Software Testing |
In the previous 2 instances of this post (Bug ageing and software processes), I have been talking about the need to measure how much time it takes for the bugs generated by the QE team to get fixed, and to see whether taking more time for fixing such bugs is seen as a problem. In almost every case, you need to ensure that these bugs get fixed within a definite period of time and not keep on lingering on.
One of the important questions is about how soon bugs should be fixed and not kept hanging. It is not easy for a group to define the time period within which bugs should be fixed, and not kept pending. I have tried that, asking a group of development and quality mangers to agree to a time period in which bugs should be fixed (or a bug that is not fixed after say 120 days should be escalated to a bug review team); and there was no agreement even after several rounds of discussion. In the end, there was a proposal that just took an average of the different proposals and we agreed to monitor statistics related to bugs.
What came out very critically from this entire discussion was several points that I will layout in this ongoing discussion:
- It is important to differentiate between bugs depending on their severity. So, a bug that is of higher severity or priority (say an application crash or some problem that related to data loss / corruption) needed to be fixed much earlier than a bug that had a small problem which a user may or may not ever face. Set different standards for these different types of bugs; and trust me, the team will totally agree to the logic (if you don’t do it this way, they will get totally confused about how different bugs whose critically are so different are treated the same).
- Do an analysis of bugs where the age of the bug is higher, and whether those bugs were actually fixed or had to be withdrawn. Our statistic showed us that when a bug is not fixed within a short number of days after being created, then the chances of the bug never being fixed are also higher. This also goes back to the previous post where I outlined some problems in terms of reproducing bugs when the bug has been open for a longer period of time. Do this analysis on your own project, and you might be able to see this pattern (and should worry you, since that means that there are critical bugs that you could have got fixed, but were never fixed).
Contd.. in the next post …
In the previous post (Bug ageing and software projects), I talked about the concept of bug ageing and why it is important. In this post, I will continue on that topic and write more about this area.
One of the biggest problems with bug ageing is that the more time there is between when a bug gets filed and when it finally gets seen, the sequence of steps gets lost. I have seen people insisting that if you document all the steps that you take while filing a bug, you will be able to reproduce the bug. Hogwash. This may not work in every scenario. For example, when somebody is writing the steps for a complicated crasher bug that happens once in a while, there are a number of factors at work that could have caused the crash in the application. It is only the perfect person who is able to reproduce all the twists and turns that they took which caused the crash. Suppose you have an application that allows you to add text, images and sounds while creating a greeting card, a crash that I have seen came during a specific situation when a sound was added, then a video, then text, then the sound was changed, and the text was modified. Now, when you increase the number of steps, it is going to be harder to reproduce such a crash, especially when you are called upon to do so many weeks later. As a result, we set the condition that all crashes need to be looked at within 48 hours of the crash being reported, so that we don’t lose it. The tendency is simple to let the crash go out, since it came in a complicated scenario; but guess what, with so many people coming online to express their opinions, things get very complicated. For a crash, which seemed a low scenario, we had a user lose around 1 hour of effort, and the amount of feedback in user forums was incredible to see; and we use that scenario as an education to people about how not to let such significant items such as crashes go by.
The other major problem with taking time to resolve a bug is due to environmental factors. Suppose a crash is reported, and part of the problem is the interaction of some components on the machine of the tester with some components inside the application. Over a period of time, with system updates, other applications getting modified, or other environmental conditions, this crash or bug is not longer visible. The developer does not have a reproducible scenario, but has to fix and resolve issues. In this case, most of the time, eventually the bug is let go as not reproducible, and we end up with a possible user crash scenario that we could have fixed, but were not able to find because the base environmental factors changed in the meantime. All of these end up with some costs that we have to pay later.
|
Software Jobs If you have the following profile, and are looking for a job in India or in the US, please send an email to getitjobsindia@gmail.com
1. Software developer in Java / C / C++ / C# with experience more than 2 years
2. Software quality tester with experience more than 2 years
3. Product Management for a software company
4. Program Manager / Project Manager for a software company
5. User Interface Designer / Graphics Designer / Visual Designer
6. Tech Writer
7. Software products support
|
Recent Comments