Scrum Process | Scrum Problems | Scrum Detail | Scrum Challenges




 

February 2012
M T W T F S S
« Jan    
 12345
6789101112
13141516171819
20212223242526
272829  

Bug ageing – why it is important to follow in a software project – Part 2




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.



Bug ageing – why it is important to follow in a software project




First of all, what is bug ageing ? Well, in a very broad sense, bug ageing is the amount of time that a bug is with a certain person. A bug can follow many different paths during its history – the bug can be with a developer, pending for the bug to be fixed. The bug can be with the tester, pending some information to be provided to the developer or when the bug is marked fixed, or the bug can be with management, where they weigh the cost vs. benefits of the bug and decide on a future course of action. In a typical scenario, all these bug actions happen within a short period of time and the bug is resolved (fixed, deferred, or withdrawn) with a short period of time.
However, there are numerous cases where the bug is not fixed quickly. There can be multiple reasons for the same:
- The bug is with the developer, but the developer has a large number of bugs on their plate and hence is not able to give this specific bug the priority that it deserves
- The developer has been told to focus on a specific product area and hence is not able to focus on bugs from other areas, and hence these bugs remain unattended for some time
- The bug is marked in an area which is going to be handled at a future part of the schedule and hence the bug is marked to be fixed when attention is provided to the area further on in the schedule
- The developer wants to get the number of bugs on their plate down, and hence focuses on the bugs that are easier to fix, and tougher bugs have to wait for more time before they are given attention
- It is not easy to recreate the conditions in which the QE found the bug, and hence the developer, showing signs of inertia, is waiting and will push the bug fix when he / she had more time

Similarly, the QE could be having a number of reasons for delaying the bug fix. Some of these are:
- The QE is very busy in testing a specific area of the product, and is not able to spend time on the specific bug
- The bug may have been filed by somebody else, but is assigned to a specific QE because that is their area. As a result, the QE is not very enthused about the bug (no ownership feeling over the bug)
- The QE has a large number of bugs, and the scenario to resolve this bug means using a much older build (and installing the latest build and removing a later build takes time (with larger applications, this could mean as much as 1-2 hours just to install a build)); hence there is inertia in going ahead in recreating the bug

In all such cases, when bugs wait a large amount of time to get resolved, there is a pending time bug. One of the biggest problems in older bugs is that, when a bug would have been filed many months ago, the dev or QE lose track of the scenario in which the bug was filed (even though the steps would have been written down) and find it harder to replicate the bug as time increases.
I will write more about this case in the next post ..



Meetings – how to optimize the number of attendees in a meeting for middle management




In the organization that I work in, there is a culture of having meetings on the drop of a hat for discussion of issues. This is normally justified for the following reasons:
- Meetings avoid long winded email discussions where the point made by a person could be misconstrued or not understood properly.
- Meetings bring together all the stakeholders for a particular discussion, which can be difficult in an email or 1;1 phone discussions.
- A meeting ensures that the discussion can be a focused discussion, focusing on the points in hand, and ensuring that an outcome is available at the end of the meeting.
- When a meeting is properly run, there is a high chance that a lot of the outstanding issues can be resolved and this helps in moving the project ahead.

However, meetings have a cost. Consider a manager who decides that he or she needs to discuss something with their staff. Such a meeting will typically have all the attending people reporting to the person, and when the calling manager is a senior manager, such meetings can be a costly affair. I have seen cases of such meetings lasting for 1-3 hours or more, and when you consider that some of the senior people attending are those who are paid the big bucks, and yet are not involved in the issues that are being discussed, it tends to get problematic. Consider the case of the Vice-President of a group who has people reporting to him from different functional areas, and yet they get together to discuss issues that would be more relevant to the Dev area (in which people from the QE group, Documentation group, Support group, etc) are there without any valid reason and are only wasting their time.

For a company that was infested with such time-wasting meetings, one of the new enterprising managers came up with a suggestion. This was recognized as a problem, but nothing much was being done to tackle this problem. So when the suggestion came up to calculate the cost of such meetings and let the senior management know of the cost of such meetings that happened within middle management, it was welcomed as a brand new initiative that could possibly work. So what happened next ?

Well, a HR person was deputed to spend 1 month, with a few hours every week, to be invited to all such meetings that were held for people at certain designations at middle management. The HR person had access to salary levels, and since they would be there at the start of the meeting, could calculate the amount of money involved in every meeting by viewing all the people attending, and would also know the duration of the meeting. This helped calculate the cost of the meeting, and this information was regularly circulated among senior management.

Over time, and when some ridiculous meetings were found, things started getting better. For example, there was a certain meeting of middle management that was called because a particular group head was upset that equipment supplies were getting finished at a rate faster than he expected (items such as pens, notepads, etc). When the cost of the meeting attendees was calculated, it was as much as the cost of the supplies for that group for a couple of months, and drew a lot of guffaws in senior management, followed by some soul-searching in management, and led to the circulation of some guidelines for deciding when to call meetings. This was met by relief by a lot of people in middle management, who would be called to meetings where it made no sense for them to go, but it was not worth it for them to ruffle egos by not attending.

Successful Meetings: How to Plan, Prepare, and Execute Top-Notch Business Meetings Read This Before Our Next Meeting
Boring Meetings Suck: Get More Out of Your Meetings, or Get Out of More Meetings


Expanding the Scrum process to a larger team, some problems ..




We were successfully running Scrum on a team that was just at the appropriate size, with around 8 people in the team, all well trained in Scrum and believing in the way forward being Scrum. They understood how to use Scrum, and had developed a nice understanding with the managers of the team to ensure that they got the desired independence to estimate tasks and track the progress of the tasks. As a result, they were the team that everyone pointed to when there was a need to point out success stories and were also called to present to other teams that were planning on using Scrum.
Soon, there was a plan to take another team through the Scrum process, and with team members from the first team providing training and support, the plan was started. The idea was to get the division of the team done properly (since this was a 20+ member team), along with separation of the features into some significant areas such that multiple teams could handle each tasks separately, set Product Owners for these tasks. The thought was that this would be a smooth experience.
Well, it was not. Soon, within a couple of Sprints, the Product Owners started complaining that many integrated features were just not making it as the original plan, and the product was falling apart whenever integration was supposed to be happening. Soon, there was an emergency session on to figure out what was going wrong, since individual Scrum teams were working fine. After some analysis, the following were found to be some of the main problems:
- Coordination between the multiple Scrum teams was just not happening to the desired level. There were informal contacts between the team members, and the Product Owners met up on a regular basis, but the deep technical discussions that should have been happening were not present; this was primarily because the teams were too focused on their own specific work (and this was enhanced by the emotional attachment they had developed due to the process of estimation and assignment, as well as because of the Daily Scrum meeting).
- The teams were no longer thinking of the big project. Originally, you had the managers who would always have a conception of the big picture in terms of the integrated product, but after passing on a fair amount of the operational authority to the team members, the picturisation of the big picture when doing the regular daily work was getting lost. The only alternative that seemed to occur to the managers was to get more involved, but they also did not want to seem to interfere with the work being done by the team.
- Daily meetings. With the big teams being split into smaller teams, the management was getting very heavily stretched just in terms of the amount of meetings, and if they did not attend the meetings, the managers were not sure of being aware of status of what is happening in the project, and hence had to stretch to know more. This in turn prevented the managers from spending the desired amount of time that they would normally spend on other items such as optimizations, improvements, and looking at the big picture.

Succeeding with Agile: Software Development Using Scrum The Elements of Scrum
A Practical Guide to Distributed Scrum