There are certain concepts that take a lot of time to seep through, especially when all previous experience has been on one type of methodology. For those who have long experiences of working on Waterfall or other methods, getting into being comfortable with the usage of Scrum is easier said than done. One comes across hilarious experiences where people have still not managed to wrap their heads around the change that has happened in the development methodology and revert back to their previous experience, but then are brought short when they are reminded that they are now part of a Scrum team and a different methodology.
One of the most critical items that I have seen in teams working as per the Waterfall methodology was about the decisive role of the Project / Program Manager. The Manager would be the key person to figure out improvements in the process or the workflows (even if somebody else has seen the changes and approached the Manager); it would typically be implemented through the leads or other managers in the team, and would be informed to the team in most cases about the changes that are supposed to be happening.
However, the process of bringing about changes in the way that the Scrum team operates cannot happen in this way. It is very likely that even though the change sought to be implemented may seem logical and something that should happen in the due course, it cannot happen that the Manager (who would have become the Scrum Master in a number of teams) should try and bring the issue into the team in a direct and controlling way. The empowered Scrum team is the one that decides the processes to follow, the improvements that should be made and whether there are changes needed in the workflows.
So how do such changes happen ? Well, the normally correct assumption is that the Scrum team will naturally take up items that seek to bring about improvements, but these would happen after these changes have been discussed within the Scrum team. The Scrum Master (or somebody else) can bring these improvements to the team during any of the review sessions, or even discussed during the Daily Scrum meeting, however ensuring that this does not take too much time of the Daily Scrum meeting and can be discussed in a separate meeting. It is essential that the team bring in any changes only after they have been discussed in detail during the meetings where the issue is supposed to be discussed. It is also possible that in some of these changes, the team can suggest modifications that would act as an improvement or point out some impediment that the Scrum Master or the proposer had not taken into account, because of which the proposed changes could not be implemented, or implemented only after discussion.
There are typically 2 types of defects that are fixed during any software development cycle (well, actually there are more than 2 types, but for the purpose of this post, let’s assume that the 2 types are the ones that I am going to write about); these are the defects that have existed in the software before the present software development cycle an were either not found earlier, or were found earlier and deemed not worthy to fix; the other type is a defect that has been introduced into the software during the current work cycle (and this can happen a lot during software development as people who have experience in software development would be able to testify). However, it is important that teams ensure that their rate of defect generation is low, not in terms of the number of defects that the testers are able to come up with, but that the developers are able to write as much of defect free code as possible (or in real terms, try to reduce the number of defects that are present in the code that they have written).
Now, when the team has written code and defects are generated, there is a certain amount of time that would be spent in fixing these defects. During the course of initial testing and unit testing, some defects would be found and marked for fixing, and would happen almost before that particular feature has been marked as done. However, there are many other defects that will certainly roll over into the next Sprint cycle or the one after that. They do need to be fixed (or atleast a significant number of them would need to be fixed), so should they be assigned as a feature along with other feature work ? Well, many Scrum Masters who I have worked with (and this is also recommended during one of the training that I had attended) was that that major defects should certainly be estimated, but not marked as one of the User Stories for the Sprint Cycle.
Why so ? Well, the User stories during the Sprint cycle should be reserved for the work done as part of feature building, even if it is background architectural or design work. Defect fixing is more of a work that has gone in for correction of an error, and would actually detract from the measurement that the team would get of work done during the Sprint cycle. If this happens enough, or if there are more such defects marked for testing, then this will also be obvious during the review meetings during the Sprint cycle, and would need to be discussed and corrective measures taken. This should also help provide more accuracy when some amount of time has been spent on trying to estimate the time spent for fixing these defects.
For those who have been through various development methodologies of the software development process, there is a prime focus on metrics. One needs to obtain a lot of data, since it is analysis of this data that would help in finding areas that need improvement. After all, when you are looking at the productivity of a team, how do you measure it unless you collect data such as amount of time a person has worked per day, the amount of code written, the number of defects in the code, and so on. Once all this data is collected, many organizations have dedicated systems and teams to number crunch this data and derive some action items from this data. This kind of analysis can determine who moves up the pecking order, who gets the higher raise, and who gets urges to improve their productivity. One of the prime examples of such data is in terms of determining the amount of effort spent per feature, per task, and even in terms of lines of code (in terms of per unit of time). This data is used to determine the efficiency and productivity of individuals. So, when you take a typical Waterfall project, the more theoretical teams would be taking the feature set, breaking them down into number of Function Points, or use some kind of past knowledge based methods to determine the timeline and amount of effort required (which is pretty critical in some cases, since it determines when the project is under- or over-staffed).
Now let’s come to the case of Scrum. During training, team members can be taught (depends on the training though) that it really does not make sense to capture the effort per individual or even per the team. The number of objections one gets at that time can be pretty strong, all geared towards the point that unless one can determine the productivity of an individual, how does one do improvements ? Seems pretty reasonable, right ? Well, if the trainer then tries to convince them that even though improving productivity is desirable, comparing the estimates vs actual effort is not really recommended, it can be a tough sell.
So what I write may not seem realistic to many of you, but let me try to give a reason for that. Or rather, a bunch of reasons.
– In Scrum, the concept is to let the team be the self-organizing and executing capability. If a developer is slower than the others and could be better, it will come out in the Daily Scrum meeting where the amount of work done would seem different from that done by the others. This itself acts as a sort of self-correction method
– The team is expected to do the estimation. In such a case, when there is an attempt being made to also calculate the actual effort, it will have an impact on the people who are doing the estimation, since it will lead them to believe that at some point their estimates will be questioned. This in turn can have an impact on their behavior during the estimation process, and that is not a path you want to go down.
– In Scrum, the emphasis is always on the amount of effort left to be done, and whether this will fit in the Sprint cycle and if not, some corrective steps would need to be taken.
Scrum works on the basis of team work, of the Scrum team working together as a team. However, this concept is getting badly shaken with more organizations trying to take a strict line in terms of measuring the performance of their employees, and granting rewards in terms of stock options and salary increases based on the overall performance of the employee. This gets tricky when people start to worry about the appraisal process, and on focusing their individual accomplishment. It might be hard to think that people could get so focused on maximizing their achievements that they hesitate to help others. I have seen this happen in different teams, and seen developers talking back to their manager during the appraisal, asking questions relating to their achievements. In a subset of these cases, have heard some of the developers complaining that their acts of helping other team members when they run into some problems is working against them, since that means some of their time is getting lost, which reduces the accomplishments that they could have achieved. It was hard to believe that somebody could say something like this, but the developer was also troubled by the organization focusing more and more on an individual and even setting off one against the other; he stated that this policy will have an impact on how team members help each other.
This long paragraph above is to illustrate the perils of tracking the velocity of individual team members of the Scrum team. After all, one is trying to maximize productivity, and how can this be done unless the velocity of each team member is measured and based on these measurements, feedback provided (may include awards during the appraisal season). However, it seems that even though this principle seems fine, it is actually not fine. In the case of Scrum, we call this a self-organizing team, that runs the operation during the Sprint cycle. They handle the tasks, the estimation, and work closely with each other. The minute you start measuring the velocity of one of the team members, the suspicion will come that the eventual aim is to use this velocity to provide feedback and link it up with the rewards system.
In a subset of the cases, you will find individuals focusing more on their own work in order to ensure that their work gets completed, rather than spending time in helping some other team member. This can quickly feed off each other, since team members are pretty perceptive about their inter-relationships, and can lead to team members being more focused on their work. What this results is that, instead of encouraging team members to work with each other, one is setting atleast some of them against the others, and one can be pretty sure that this is not the goal, but it can still happen. It’s not worth the return in trying to track the velocity of individual team members, but be sure to do it for the team as a whole.