Learn Software Development » Manager

What happens when your product is not stable close to release date ? – Part 3

ashish — Wed, 09 May 2012 20:16:20 +0000

In the previous post in this series (Getting advice from the team about status), I talked about the importance of making sure that feedback from the team is not crushed, and that people are not put in a position where they feel that they are doing something against the organization when they report status that is not comfortable, or where they say that according to them, the product is not in a good position.
Now, for a large product, there will be several layers of organization that will be working on the product, and it is good to remember that all of them have some fact and some information that may be relevant or may not be. In fact, in today’s world where user forums are a quick way for a problem to be reported and then more me-too’s to quickly join in through social networking, it is very hard to determine which issue is a huge problem and which is the one that can be safely ignored. It may seem strange to those outside the industry, but it is very much possible that a defect in the program that may be irritating to that specific user or cause some problems may not be something that the team considered worthy of fixing.
The next few lines will not be about the decision making, just more about what goes on as the team nears the release date. As the product gets closer to release, and the situation is not such that there is absolutely no chance of release (if the team is indeed in such a bad situation, it will be visible to everybody and decision making will be much easier), the status with regard to defects in the application will become much more complicated. It is a known part of the software development process that when the team gets near the release date, selecting which bugs will get fixed and which ones will not be fixed (or will be deferred from the current release) gets tricky. Closer to the release date, the problems associated with enhanced risk for every defect that is fixed become critical. What this means is that unless the defect is evaluated to be sure that this is needed to be fixed, and that the actual fix will not end up destabilizing something else, the team may well decide that the problems sought to be taken away by fixing the bug are not worth the risk, and a larger proportion of bugs will be deferred (and not fixed).
Deciding which of these bugs need to be fixed and which one needs to be deferred is critical. However, this should be an independent decision by the Bug review committee having the Product Management representative, and (to emphasize), it should not be under enormous pressure to defer bugs in order to meet the schedule. What this means is that it can happen easily enough that the management team relays the pressure down to the team that it needs to increase the rate at which bugs are being deferred in order to meet the schedule. This tactic runs the risk of letting through such bugs that can be bad for specific sets of users and bring about a lot of condemnation on user forums and among user groups.

Read this book for some more advice in this area: Judgement Calls: Making Good Decisions in Difficult Situations –

More about this in the next post (link) ..

How does the role of managers change when the team starts implementing Scrum ?

ashish — Thu, 16 Jun 2011 18:29:48 +0000

This is always a tricky question, and one that I have seen emerge in the minds of managers many times. Once a team starts implementing Scrums, one of the biggest issues is about the role of managers, what they are expected to do. I have seen reactions from managers, once they start seeing the task estimation (and Planning Poker), and the Daily Scrum meeting; they start feeling that they lose control over what their team is doing. This is even more critical for them since they are held responsible for the working of the team, for ensuring that the team delivers as per expectations, and they are the ones who are pulled up if the team does not deliver as per expectations.
So, how do you beat such cases ? How do you avoid cases where the managers start feeling that their role is not clear ? Well, one of the biggest items is to get managers to understand the Scrum methodology, make sure that they are comfortable with the changes, with the new role that the team also has. So, it is required that the managers understand what their role would be in terms of the Scrum methodology:
- The managers provide all the infrastructure in terms of machines, software, good working environment, organizational issues, etc. This can be pretty critical since it is important that morale issues be addressed, and morale for a team can be impacted by a number of organizational issues. A manager in other methodologies is expected to handle such issues, and the same remains valid in Scrum.
- Coaches team in Scrum practices. There can be several issues in Scrum, such as people not being able to easily adjust to a daily meeting where they provide an update on what they have done (some people can consider it humiliating, especially when they are unable to complete items that they stated the previous day that they would). In such cases, the manager can provide a lot of support and coach the team members about how to handle such issues, keeping their morale high, and so on.
- Provides support to the Scrum Master. It is typically the manager of the team member who knows the person, knows their strengths and weaknesses. A Scrum Manager would not know the team member to that level; so when a manager goes through the meetings and sees some areas where there are conflicts, or when a team member is not behaving upto expectation, then it is the manager of the team member who can work in the background, working with the Scrum Master and the team member to resolve issues. This can be a very useful role for the manager and lead to a very high level of contribution for the project.
- Providing reviews. Typically, most managers have a high degree of experience in terms of the artifacts of the project such as the design, architecture, etc. The manager can still do reviews of these, and provide feedback to team members that can actually work to benefit the project, and also help the development of the team member.

Properties of a test / QA / QE Manager

ashish — Wed, 28 Jan 2009 18:49:39 +0000

Testing is a vital and critical part of the overall software development process, and is very important that the overall testing environment have the right mix of aggression and thoroughness. A large amount of this attitude comes from the person who leads the testing team. So, what makes a good QA or Test manager?
There are many attributes that a good test, or QA manager should have. Here are some of them:
• The test manager should be very familiar with the software development process. This is the only way that the rest of the testing team can develop the feel for when they should be doing what activity.
• The test manager has be able to ensure that the overall enthusiasm of the team remains high, and promote a positive atmosphere, despite what is a somewhat ‘negative’ process (e.g., looking for or preventing problems). People should be made to feel that they have an important role in ensuring that customers get a software that works well.
• The test manager should be able to promote teamwork to increase productivity. Teamwork between the members of the testing team is critical, given that each of them may handle a separate area, and may have several elements of intersection. In addition, each person can have a different field of specialization, and together they can cover a large area.
• The test manager should be able to promote cooperation between software, test, and QA engineers. This is not so easy sometimes, but is very critical. It is a close interaction between dev and QE that results in a deeper understanding of where software can go wrong.
• The test manager have the diplomatic skills needed to promote improvements in QA processes. Sometimes software and hardware can be expensive, and management may not really understand or appreciate the need for such, and it is in such cases that the test manager can better explain.
• The test manager must have the ability to withstand pressures and say ‘no’ to other managers when quality is insufficient or QA processes are not being adhered to. It is the test manager who is responsible for quality.
• The test manager must have people judgement skills for hiring and keeping skilled personnel
• The test manager must be able to communicate with technical and non-technical people, engineers, managers, and customers.