The Long Walk

Last Friday we have finished our first SCRUM sprint, so to speak. Looking back, one can conclude that, although we are just taking our first steps with this methodology, the overall result is positive.

SCRUM is a development methodology in which the application is built in iterations, called sprints, where a set of use cases are due to be implemented during the iteration’s life span. The goal at the end is a finished, functional, better or more featureful application than the one from the past iteration.

This method introduces, at least, two major advantages: the client’s involvement, and a scale against which the development can be measured. With SCRUM, the client is always aware of the progress of the development and the quality of the resulting applications. This allows him to change the order in which new features will be implemented next sprint. On the other hand, the development team manages, easily, to control what has been done and what has to be done.

The SCRUM methodology requires that the developer assess, at the beginning of the sprint, the estimated time for a particular use case to be implemented. As a programmer I know this is not a straightforward task. To analyse the task and, on the spot, predict how many days it is going to take to implement, can not be done without a great amount of practice. This leads, and it is perfectly normal, to under or over estimated sprints. As a consequence, there are use cases that will never be implemented or, on the other hand, there is the risk that part, or even all, of the development team gets nothing to develop before the end of the sprint. The second case is not so “serious” as the first one is, because the methodology allows that new use cases be incorporated at he middle of the sprint. Nonetheless, this situation must be avoided.

At the end of the sprint, a demonstration of the results is required and, of upmost importance, a sprint postmortem must be done to reveal what went wrong and what went right. This postmortem, that takes the form of a meeting with all teams involved, is to understand why, if any, some of the use cases have not been implemented, to do some fine adjustments into the process and to share experiences among teams. In our case, as it would be expected, there were some tasks under estimated. However, the number of well estimated tasks was much greater than those under estimated.

There were three reasons for the existence of under estimated/unfinished tasks. First of all, SCRUM hasn’t been implemented at full strength yet. Some of the projects don’t have an external client and/or a client that attends the preparatory meeting. This leads to a misinterpretation of priorities between use cases, which may not match those from the client. The amount of unplanned tasks generated by this situation suppresses, by large, the time reserved in each sprint for them. In the current sprint, we have tried to get beforehand, from the client, which use cases were more important.

The lack of knowledge over a task, which happens mostly in those that require investigation, is another reason for under estimating the required time for implementation. Since the estimate is done with the knowledge at the time, the estimate is done more with by guessing than with by reason. To overcome this, in the present sprint, this type of tasks where not estimated, although the time required to implement the use case did, since it is mandatory by the methodology. When the allocated time is over, if the task is not fully completed, it can be dropped out in favor of another task with greater importance.

Last, but not least, the third cause to the existence of under estimated/not concluded tasks was, and still is, the need to use the same working individuals throughout several projects. Ideally, each worker should be in just one project at a time, so he can be completely focused. Since this situation is not possible, extra time is required for the context switch. This situation is not avoidable in the meantime, but the problem is identified and there in future there is a tendency to create teams for that don’t share human resources.

Above all, the implementation of SCRUM gave to the development team a sense of work done. At the end of the sprint, each one of us had the opportunity to see his work, and our fellows’ work, fully functional, since this is the main pillar of the SCRUM methodology. The mental image of the final product that resides on the mind of each individual in the development team, during the months required for the development in a more traditional methodology, is replaced by a visible, usable and, of most importance, testable product at the end of each sprint.

Let us see how this sprint goes, of which I will talk about at the end of it.