The managers of the team looking at reviewing processes before the start of every project / product cycle

One of the most critical factors in making a project cycle successful is the processes that are used by the team. What do processes do ? Processes define what the team is supposed to do in different circumstances, whether this be part of the regular routine work of the company, or whether this be involved with exceptional circumstances. Some of the most critical and regular processes that a team deals with and which define whether the team will be successful or not are:
- The process used by the team members for the design phase (whether this be the high level design or the low level design)
- Processes during the coding phase (code re-use, code marking and modification processes (such as commenting with the code, etc), code review process, etc)
- Processes used during the testing phase (process of filing a defect, determining whether the defect has indeed been fixed and can be closed, etc)
Like these, there are numerous processes that are used during the development project, and they play a critical role in ensuring that the work gets done efficiently, and at the same time, as desired. A team may be using processes that have evolved after a lot of experience, or could have been designed by a small set of people (for example, when we wanted to incorporate a component from a new third party vendor, we had to define a process for testing, defect logging and communication with the vendor that worked for the vendor and for us, else things can go real haywire).
When the team is doing one release after another, the processes that they are following are typically those used in the previous release project, and since people are used to these processes, it is pretty easy to follow these processes. However, it is important that the management of the team spend some time in collecting information about how well these existing processes have worked, whether there is a need of modification of some of these processes, and whether some new processes need to be added.
One of the prime examples of collecting such information is the post-mortem meeting. One of the discussion points can be the processes being used in the team, and whether the team feels that there needs to be some modifications in the process being followed, or whether there needs to be any new processes to be created (and such a discussion cannot just start in the post-mortem meeting, but the team needs to be informed that the topic of the new processes will come up in the post-mortem meeting, and that gives them more time to bring the points for the meeting; in fact, the team managers should think through some seed points for such a discussion and include this in the earlier communication, and that will encourage the team to think through this in even more detail).
But this cannot be just restricted to one meeting. If required, specific agenda groups within the team need to be formed to explore some of these processes (for example, every cycle we set up a team to discuss improvements in the coding processes, including the code review process to see what are some of the improvements that are possible and whether some of the processes are no longer applicable and need to be dropped).
The managers can also play a critical role in such a discussion. Each manager can hold a similar discussion within their teams and figure out what are some of the improvements or changes that the team is looking for. When there are processes involved with the external teams, it is important to do a discussion with the external teams to figure out tweaks with such processes as well. There is not a single step to modify such processes, it can be incremental, taking several weeks or even months, but there has to be clarity that initiating such a process of review needs to happen.

Ensuring a proper kick off and knowledge transfer to external teams that also work on the software ..

When you consider the software team, you would have a development team, a testing team, designers (including the user interface designer) and also the management team (and one could include the product managers or the product management team in the set of managers). When you consider these set of people, they have a lot of knowledge about the product and the features in the product, especially the people who are working on specific features. There are a few other people who have the same amount of knowledge on specific features. Given their level of knowledge, they take this level of knowledge as granted when they have a discussion with other people who are not on the team, and it can be difficult for them to realize that other teams do not have the same kind of knowledge that comes from working on the same product for a long period of time.

Any product team will need to work with other teams that provide services such as translating the software into other languages, do the documentation for the software and other related services that the product team will not do. The problem with this concept is that people working in these teams do not have the same kind of knowledge of the product that the product team has, and this can be a source of friction in their interactions. In some of these cases, the software team would do the right thing, find out the level of knowledge of these external teams and prepare time to ensure that these teams get a ramp up of the software program. But, even in these cases, it is a fair approximation that they will never reach the same amount of knowledge as the product team, and expecting such a level is what leads to frustration.

In my experience, the frustration comes when the product teams work with external teams that have little or no experience with the product (and this can happen often enough when dealing with external teams, since these teams typically cannot afford to have dedicated people for handling products, and their attrition rate may be different from that of the product team). So, the product team has some amount of knowledge transfer with the external teams, and assumes that there will be some questions that would come from the other teams. However, it may turn out that it takes time for these new people to understand the product, and the queries only come later in the timeline, and this is unexpected for the product team.

The way to handle this is to have a line of managers who understand that new people take time to understand the functionality of the product, and these people will never get the time that people in the product team have. So, there are 2 processes on how to handle this - prepare an effective training program that provides as much information as possible without over-doing it, and equally, learn from the teams that have gone through such an experience and learn what steps can ensure that the external teams learn faster, and what are some of the common problems and frustrations that can crop up in such a relationship. 

Risk Planning - Look at bug curves for previous projects and identify patterns - Part 4

These are a series of posts that I have been writing the process of risk planning for the project. For a software development project, one of the biggest risks relates to the defects that are present during the software development cycle. These risks could be because of the number of defects are more than expected, or defects are of a much higher severity than expected, or that some of the defects are getting rejected with the fixes either being inadequate or totally problematic. Typically, for software or for projects that have been going through several versions, there is a lot of information available in terms of the data for the previous versions of the software projects, with this information being very useful to make predictions about the defect cycle during the current version. However, at the same time, my experience taught me that not everybody even considers looking at previous cycles and figuring out problematic areas that may turn up, and how to handle those. Being to able to predict such problematic points and then figuring out how to resolve them is an integral part of risk planning.
In the previous post (Looking at bug curves for previous projects and identifying patterns - Part 3), I talked about how the bug graph analysis from previous projects indicated that there were a large number of open defects soon after a point when the development team had completed the handover of all the features to the testing. This was essentially because a number of the big ticket features came near this date, and this was the first time that the testing team was able to test these. But this overload of defects was something that was causing a lot of pressure to the team, and it was unhealthy for the project. We had to resolve this, but we would never have even actually realized this problem if we had not mined the data from previous projects.
In this post, I will take another example of what we did using the mining of the data of looking at defects from previous cycles and then doing some analysis of that data. There can be many such cases, and I will take up some of these cases that were important to us in these posts, but you can extrapolate these to as many cases as you like and then gather the data and do the analysis.
One of the quests that we had for our team was to figure out how to decrease the time period that a defect was open with a developer - or more accurately, the time period in which a developer first looked at a defect. One of the biggest problems was that there would be defects which were not looked at by a developer for many weeks because of the load that the developers had, and when they got the time to look many of such defects, the tester did not accurately remember the conditions, or the software application had been changed many times since then because of all the developers checking in their changes, and it was not easy to resolve such defects. In short, the quest was that defect ageing be reduced from the many weeks that it was currently, and everybody agreed that we had to do something. However, before we proceeded to do something, we needed to know the extent of the problem, especially at different parts of the development cycle.
For this purpose, we again needed to refer to the defect database for data for previous versions, set up the query for this, and then get the data. To some extent, we also compared the data for multiple previous versions to see whether there were patterns in the data, and we did find some patterns. The analysis for how to reduce this, and what this involved in terms of changes in terms of defect management was something that took effort, but there were rewards for the same. But the most important part remained that we could only do all this analysis once we had the data for the previous cycles, and this was recognized as an important of risk management.

Read more about this in the next post (Risk Planning - Look at bug curves for previous projects and identify patterns - Part 5)

Risk planning - Look at bug curves for previous projects and identify patterns - Part 3

This has been a series of posts on doing some risk planning by focusing on the defect management side. There is a lot that can be done to improve the defect management in the current cycle by looking at the defect trends from the previous cycles (in most cases, there is a lot that can be learnt from previous cycles; it's only totally new projects where nothing can be learnt). In the previous post (Looking at bug curves and identify patterns - Part 2), I took more of a look at ensuring that the defect database is properly setup for getting the information needed for generating this data. Unless this sort of data can be generated for the current cycle, it cannot be used in the next cycles. Hence, there is a need to make sure that required infrastructure is in place for the same.
In this post, I will assume that the data is there for previous cycles to interpret and hopefully generate some actionable items. In the first post in this series, I had already talked about some examples that can be used such as identifying a phase in the project when there have been more defects rejected in the past and then try to change that. There are clear benefits of doing such kind of work, and the project manager should be able to get some clear improvements in the project.
The way to use this kind of defect data from previous cycles is to be more systematic in terms of analysing it, and then identifying some clear patterns from this analysis that will help to identify improvements. So, one clear way of starting on this line is to take the entire defect curve from the previous cycle (charting the number of open bugs against the time axis, and doing the same for other bug stats as well (consider the example of rate of defect closure, the number of defects that have been closed, the number of defects that were closed by a manner other than fixing, and so on).
Based on these various defect stats, there is a lot information that can be generated that can be used for analysis. For example, we used to find that the number of open defects used to shoot up to its highest figure soon after the development team had completed their work on all the features, and this was basically a number of the features would come to the testing team near the final deadline for finishing development, and this was when the testing team was able to put in their full efforts. They were able to find a large number of defects in this period, and as a result, the peak in open defects would happen around here. This was a critical timeline in the project, since the number of defects with each developer would reach their maximum, and cause huge pressure.
Based on the identification of such as pattern, we put in a lot of effort to see how we could avoid a number of features coming in near the end. We had always talked about trying to improve our development cycle in this regard, but the analysis of the defects made it more important for us to actually make these changes. We prioritized the features in a different way such that the features were we expected more integration issues were planned to be complete much earlier in the cycle. None of this was easy, but the analysis we had done had shown how not changing anything would lead to the same situation of a large number of open defects, as well as the increased pressure on the development and testing team. Such pressure also led to mistakes, which caused more pressure, and so on ....


Read more about this effort in the next post (Look at bug curves for previous projects and identify patterns - Part 4)

Risk planning - Look at bug curves for previous projects and identify patterns - Part 2

In the previous post (Looking at bug curves for identifying patterns - Part 1), I talked about how the defect curves for the previous versions of the software product should be reviewed to look for patterns that will help in predicting defect patters in the current release. As an example, if there was a phase in previous cycles where the pressure caused a greater number of defects to be either partially or completely rejected, then this was worrisome. Such a problem area is something that should be focused on to ensure that these kind of issues are reduced or removed totally altogether, and the benefits can be considerable.
In this post, I will continue on this subject area. One of the biggest problems that teams face is that they are so worked up in terms of what is happening in the current release that they use previous versions for help in estimation, and do not really use defect management and analysis to the level they should. One of the critical focus items in terms of project management and risk planning is about understanding that one looks not only at the current version of the software development cycle, but also at future versions. There is a lot of learning to be had from current releases and one should ensure that we are able to gain from this learning in the next release.
The Defect database should be set in such a manner that while it provides you the functionality to do your defect management for the current release, there should be the ability to store this information. If for example, your defect database is not able to store the data that defects have been rejected, or capture the fact that defects did multiple rounds back and forth between the developer and tester, you are losing out on data that is pretty important. We actually ran into such a situation, where we wanted to determine which defects are going back and forth between the developers and testers, or even between multiple people on the team. This was a way to figure out which defects are taking more time, and it seemed like a good place to start. The concept was that if we could figure out these from the previous cycle, and were able to get a figure on which sets of people do not work well together (too much back and forth between people over a defect is certainly not useful, you would expect people to collaborate and resolve issues rather than doing discussion in a defect).
However, things did not work as well as we expected. The defect management system did not have such a query or something even similar to it. It was possible to get this information once we got access to the tables in the database, but this is not something that is easy or quick to do. We needed to get hold of people who had some expertise in how the database was structured, and also needed access to people who knew how to manipulate the database and get us the report that we wanted. It took a fair amount of time, and in the end, we got what we wanted. The results were interesting. They showed that there was a person in the team who wanted every bit of information to be in the database, even something that was clear could be asked and did not add any value to the defect information. But, the defect was passed back to the other person, and then it would depend on the time and defect load of the other person. However, since the person did not have the defect on himself, normal statistics would not show any problem.
We took some action on this one in terms of some counseling for the person from the manager, in a non-threatening way, and resulted in improvement in terms of defect handling. However, it was difficult to quantify the time saved, but we were satisfied in terms of the results we could see, and felt that there was improvements we made in the defect management, and would help in terms of reducing the load due to defects.

Read more about this effort in the next post (Look at bug curves for previous projects and identify patterns - Part 3)

Risk planning - Look at bug curves for previous projects and identify patterns - Part 1

As a part of the risk planning for projects, defect management is one of the key areas to handle and handle well. A large number of defects may not be a problem if they are expected, but if unexpected, they can cause huge problems to the schedule of a development cycle. As an example, if the number of defects is much higher than expected, there are many problems that occur:
- The amount of time that is required to be devoted to resolving these defects and testing the changes will cause a strain on the schedule.
- And it is not just the effort change, a sudden high number of unanticipated defects will cause the team to wonder about the quality of the work done,
- Most important, will cause a lot of uncertainty about whether all the defects have been found, or are there many more to be found ?
- When more defects are found, the overall cycle of analyzing the defect, figuring out the problem, doing an impact analysis of the change, making the change, getting somebody to review the change, and then testing the change will cause a lot of strain.
- Some of these changes can be big, and will require more effort to validate the fix, and in some of these cases, the team management will decide that they would not want to take a risk and would rather that the defect get passed onto customers.
The above was just an example of what happens when there are a large number of defects that suddenly crop up. However, it would be criminal on the part of the team management and the project manager if they have not already done a study of the kind of defects that come up in different stages of the development cycle. The best way to do this, and do some kind of forecasting, is to look at the bug curves of previous cycles (which obviously cannot be done if the data about defects of previous cycles is not taken at that time, or stored at a later point of time).
We had started doing this for the past 2-3 years or so, and this helped us determine what points of the development cycle had the highest number of defects that were found, as well as closed, and even which were the times when there was the highest chances of defects not being fixed (either being partially fixed or being rejected totally by the tester). Now, even though every cycle would be different, there were some patterns that had a high probability of being repeated (and this even true when one project differs from the other, although it varied from project to project).
Let us take another example. There was a time in the project when defects had a higher chance of being rejected, and a rejected defect can be very expensive in terms of time of both the developer and the tester. As a result, during such stages that had happened in previous projects, we would ensure that there was higher focus on impact analysis and code review, and had even borrowed some senior developers from another project for around a month just for the additional focus on reviews. This paid off, since the number of defects getting rejected went down considerably, which per single defect did not amount for much, but our analysis showed that the total saving of effort because of this additional effort was around 25%.

Read more about this effort in the next post (Look at bug curves for previous projects and identify patterns - Part 2)

Open up the feature planning and tracking to the team for improvements ..

In the previous post on this topic (Risk planning by looking at confidence level of estimates), I talked about the difficulties posed due to discrepancies between the original estimates done at the time of planning, vs. the actual efforts spent on the work when the features are in development. Tracking these discrepancies and working out some kind of logic about these discrepancies is very important for the project manager. Typically, the estimation is done by the senior folks on the team while the person who works on a specific feature can be anyone on the team (if the work is specialized, then it would be allocated to somebody who has more experience in that area, but that person could still be different from the person who did the actual estimation).
So what do you do ? Well, you would typically track the estimation against the effort, and try to figure out whether there is some kind of logic. Sometimes, there is a possibility of generating some logic to figure this out. We had a case whereby the person who preparing the estimates had a person situation during the time that he was working on the estimations which was very distracting (but not enough that the Project Manager could figure out that here was a problem). So, soon after the actual work started, some data analysis about the discrepancies resulted in figuring out that the actual effort was about 25% more than the estimates where this particular person was involved, and this helped us in re-estimating the remaining features and also making a decision that a particular feature needed to be stripped down, the scope of the feature reduced for getting everything in the time frame.
However, what was interesting was that this logic was actually seen by a member of the team who pointed this out, and though it seemed a bit strange at first, more analysis helped. Some speaking to the people who had already worked on the features that this person estimated tended to confirm that they believed that the features were under-estimated. What this incident showed was that this provided us (the leads and the project manager) that we should get the team more involved with the risk planning and analysis that we do, such that sometimes it would be possible for them to identify a pattern that we might miss. There were other smaller cases that we could see.
One problem that was told to us before we started was that it was supposed that this would distract the team members from their regular work, and, many of them might not be interested in being involved in such kind of analysis. We did find people who were not interested, but we did start out with the entire team, making them involved with the process we did for identification of risk factors, gathering the data and then doing the analysis. About the time it took to do this, we figured that overall this would take an hour per week, but getting team members involved with stuff such as this would help give them a better perspective on some important processes that team leaders go through and when they could see the problem, they had a closer perspective on some of these risks and could figure out solutions for a percentage of these cases faster than we could. This helped save time overall, and after a couple of rounds, the people who elected to remain involved were appreciative of the learning they got from such exercises.

What is an Agile Process Improvement?

A process improvement program is successful only when the meaning of the word ‘process’ is clearly understood. Process means work. So when one improves, the other one also improves. The quality of the software depends a lot on the process. Whenever a change is introduced, a temporary drop in performance is always recorded. In most cases what happens is that the organization stops the implementation of changes fearing the disruption in the normal work since so much effort is required. To avoid such situations, the changes need to be adaptive. It is the agile process improvement that makes this possible. You might say that such a way of iterative improvement is not new. Well, the agile techniques introduce discipline in the whole program.

Stages of Agile Process Improvement

The following are the stages of the agile process improvement:

1. Initiating:

Ø  Stimulus of change

Ø  Set context

Ø  Build sponsorship

Ø  Charter infrastructure

2. Diagnosing:

Ø  Characterize current and desired states

Ø  Develop recommendation

3. Establishing:

Ø  Set priorities

Ø  Develop approach

Ø  Plan actions

4. Action:

Ø  Create solution

Ø  Test solution

Ø  Refine the solution

Ø  Implement solution

5. Learning:

Ø  Analyze

Ø  Validate

Ø  Propose future actions

- The improvement cycles are meant to be followed systematically so that the results might be obtained in time ranging from 2- 6 weeks.

- The whole process lets you maintain a balance the workload as well as the improvement. 

- The flow of the process is as follows:

1. Prioritized list of improvements
2. Detailed plan for the current cycle
3. Implemented improvement
4. Feedback

- After this process, the following becomes possible for the organization:

1. Identification and resolving of the issues earlier in the cycle.
2. Learning process regarding how to tackle difficulties and working of this process.
3. Adaption to the business needs that keep changing.
4. Giving response to the feedback.

- The sponsor holds the responsibility for prioritizing the improvement backlog at the start of each sprint. 

- Also, he is the one responsible for ROI. 

- Prioritization is a good tool for the sponsor to direct the change. 

- Using prioritization, the goals and feedback can be revised from quality assurance. 

- A focus can be kept on the benefit received from each improvement cycle. 

- PPQA deploys and evaluates the improvement in organization in every sprint. - The improvement package consists of 4 sprints namely:

1. Prototyping
2. Piloting
3. Deploying
4. Evaluating

- Active participation and leadership is required for a change to take place. 

- An endorsed vision and status quo is required for the beginning of the process. 

- Both of these are established via SCAMPI and CMMI. 

- The change is led by the management on an everyday basis.

- An excellent description is provided by the generic practices of CMMI for the leadership purpose.

- Similarly participation is a key element that is facilitated by the change team. - A vision is required for initiating the improvement project. 

- The initial improvement backlog is defined by 3 things namely scrumMaster, change team and the work owner i.e., the sponsor all based up on an assessment. 

- The organization is facilitated by the change team.

- With each sprint a tangible improvement is delivered. 

- The change is led by the management in a sprint.

- The effect introduced by the change is evaluated at the end of each sprint by PPQA. 

-The new improvements are defined by the work-owner who is also responsible for adding those in to the backlog of improvements and prioritizes it.

-Commitment is supported at the end of the sprint by appraisal.

-The improvements can also be continuously integrated in to the organization’s way of working.