|
|
This seems like a very odd item to write a software post about. However, this is based on a lot of experience that I have seen over the years, and also discussed with many other people (those that have seen problems where there was not enough infrastructure, and other cases where there was enough of this infrastructure). Consider a case where a company is running a traditional software development unit, where the development team runs into challenges often enough and needs to do a fair amount of thinking to resolve issues and work through complicated design and architectural solutions.
However, it is not as easy as it sounds. This is not routine work of software maintenance; in a lot of cases nowadays where people work on complicated stuff and try to be as innovative as possible, there is the need to do a lot of new stuff. New stuff means that you need some real good developers, those who can think of new solutions, who can work the things out. However, for this kind of work, you need people who do a lot of discussion with each other, trying out new stuff, working through architectural problems and looking at alternate solutions.
Now, what does this need ? I already mentioned the need for some people for the development team, but there are other infrastructural stuff that is needed to ensure that the developers have the right environment. A big deal for this is the need for place to discuss things, some good recreation stuff (such as games and the like), and so on. In this post, the focus is on the discussion. One empirical fact was that if you go to most places where developers are present and there are tough solutions, you will find a lot of the boards having discussions and architectural alternatives being discussed. Having enough whiteboards near the developer community enables these discussions to happen, also resulting in solutions and decisions.
Not having this sort of infrastructure in place inhibits the development team from these sort of discussions among the team, and does play a role in a resulting slowdown of the pace of solutions of issues. I have seen organizations where both of these situations were present, and there is an effect of having these infrastructure in place. I would recommend that organizations that have a lot of development work have enough infrastructure in place to support the development team.
This is a series of short posts about the scenario where a product that decides the future of the company is being released, and how it can be difficult to make a decision about release vs. delay when there are suspicions that the quality of the product may not be as desired. In the previous post (bug closure during the end game), I was talking about the bug closure rate near the end, and how the pressure near the end can be problematic for the people in charge of approving or deferring bugs.
In this post, I will talk about a horror situation where the management is not connected with the team (not connected enough to know about the current situation) and the pressure forces management to take hard steps which eventually blows up in their face, enough to shake their own careers. This is not a fictional situation, it has happened with several companies, and there are other cases where it has almost come to this, but the senior management has managed to turn things around and prevent the situation from going out of control.
Consider a case where the product that is going to be released is very significant for the company and there is a huge amount of market, stakeholder and executive pressure. The career of the key senior management stakeholders can depend on how well the product release has been handled, whether they have shown the necessary guidance and overall management to take their entire team along, and similar goals. So what happens when the pressure forces them into such a place that they get so committed to the release of the software, enough to ignore the pressures of the teams working on the software, and are only exposed when whistle-blowers in the team go right to the top to make their point known that the software is not yet ready for release.
An example of this happened a few years back in a large company (I will not take names deliberately, since the idea is to show what happened rather than only point out a specific example). The senior management felt that they had a good control of what was happening, and the pressure on them to ensure that the release happened on schedule was enough that they forgot the part about the release also being of good quality. So, at some point you had a situation where many members of the team had huge issues with some of the open items that were potential customer problems, while the executives felt that the team did not have the big picture, and these issues would be closed in time (and that some of them could be ignored since they impacted a minor section of the consumers).
This continued for some time, with the interaction between the senior managers and the more vocal of the team members not really reaching a conclusion, and the team members started feeling that their valid concerns were not being addressed (and since they had been with the team for many years, they were also deemed as significant stakeholders). And then the matter got raised to the CEO. This resulted in the senior managers (or rather, the key senior manager) being let got after some time because of the huge amount of communications gaps that were showing up, and because the situation that was fraught with huge risk was not handled in a way that seemed like the logical way to proceed.
This is a series of posts which talk about decision time when a major product such as Microsoft Office is near release, and the product is not yet stable (which means that the team that should sign off the release is uncomfortable with the current quality levels of the application). The release being on schedule is fairly important for the company because of the strategic, and revenue reasons, and delaying it will have an impact. The previous post on this topic (getting information up the management chain) talked about how there should be a process whereby the team does frequent status reviews, keeping upto date with their issues and risks, including the high end ones; and the ones that are more risky are bumped upto the chain of senior management with mitigation strategies and concerns. In addition, periodic status reports that can be summarised to showcase the important issues let senior managers get a good grip on issues that are not going away and which can cause huge amounts of problems.
One of the biggest problems that can be seen is about the rate of bug closure. During the development cycle, there is a certain pattern in terms of defect find rates and defect closure rates, with the expectation that as the team nears the end of the cycle, the rate of defect closure is better than the rate of defect creation. When this does not happen, things get tricky for the development team, since if the number of open defects do not come down, it makes it very difficult to trend down to the point where it is safe in terms of quality to start seeing the application as ready for release. At such times, a pressure to release the product sees the team getting ready to release the product even when they feel that it is not fully ready. In addition, if the number of new defects being found is not declining, it means that the application is still not ready in terms of quality to be released, and no amount of pressure will make the product ready for release. What pressure will do is to make it difficult for team members to admit that the product is not suitable for release (you will need somebody very determined and honest to make the point in front of the management team to argue about the product not being fully ready as yet).
All of these data in terms of the number of defects being filed, the severity of defects being files, the defect closure rate, any abnormal defect deferral rate can all be determined through defect metrics tracking, and it is very important that the team maintains such metrics, since that provides a lot of data that helps in determining whether the quality level of the product is good, or whether it is getting better, or whether there is still some time to go before the product could be good enough to be released.
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 (serious communication problems) ..
In this series, I have been writing about the problems that arise when a product (deemed very significant for the organization) are near release. In the last post (deferral of bugs near the release date), I talked about the rate of deferral of bugs in the end game, and how this time of the schedule means that bugs are evaluated much more carefully to review whether these need to be fixed or can be deferred (and there is a lot of review to ensure that bugs are not let through which could cause a risk to the release).
In this post, I will talk more about some of the measures that management should be having in the organization in order to ensure that there are no sudden surprises and information moves up the organization structure to the management chain about the current status over the period of time. If such a process is not in place, then the organization will keep on running into cases where they don’t know about problems that may be causing a risk to the release schedule of the application, and will be hit with those problems when they least expect it. And you certainly don’t want to be in such a position where the senior managers don’t know about potential problems and suddenly come to know about it. In such cases, the responses that you get from the management chain may be of managers trying to get a quick handle on the situation and how to address these problems, which is not at all a nice position for the team to be in.
So how do you prevent the problems that has been outlined in the previous post ? Well, the first and most important way is to ensure that there is a process for status discussions up and down the management chain to the level of the team involved in the actual execution of the application development. In addition, there should be a clear way for the managers involved in the chain of command to be able to highlight risk points and do this in such a way that more serious issues get moved up quickly up to the level of senior management. This starts right at the team level. The team should be having a regular status discussion where the current status of the application development (including the dependencies) is discussed within the management structure of the team and if there are issues that are deemed significant and could imperil the release schedule of the team, those should be raised up the team manager upto the next level of the structure, along with a background on the issue and potential mitigation steps. If there are no mitigation steps or is out of the control of the team (with external dependencies, or other issues such as resources), these also need to be emphasized along with suggested steps about what is needed to be done.
In addition to this, the team should be sending out a regular status report that is highlighted to senior management with a summary of the top issues and whether the team feels that there are issues that could cause problems. A combination of these steps at the various parts of the application could ensure that senior management knows about the issues and is not surprised when these pop up.
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 ..
|
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