Applying Scrum is hard, even though it is composed of a few simple rules. There are several reasons for it to be challenging, including company environments that aren't healthy for Scrum's transparent approach, or a lack of experience with Agile technical practices and with iterative and incremental product development. In other words, as is often said, Scrum is simple to understand but difficult to master.
Due to all the complexity involved, even though applying Agile through Scrum and other necessary practices has improved the percentage of successful projects, we still haven't reached a satisfactory rate. According to 2011 CHAOS report from the Standish Group, 14 percent of Waterfall projects are successful, and 42 percent of Agile projects are successful. Of course 42 percent is a big improvement over 14 percent, but shouldn't we be doing even better?
In Scrum, the ScrumMaster is responsible for ensuring that the Scrum team adheres to Scrum theory, practices, and rules. The ScrumMaster is responsible for acting as team facilitator. It sounds simple, but it is a lot of responsibility! There's a great deal going on during the execution of a software development project. Project requirements and assumptions change, other unexpected things happen, and there are people involved (always a potential source of all kinds of problems!). Not everybody is capable of being aware of everything that is going on just by "observing the team and the environment."
With all the advances in technology, why should a ScrumMaster only use his/her own perception, or archaic tools, to figure out what is going on with the project? With that in mind, I created a method that uses a generic model that can help the ScrumMaster detect problems with Scrum's usage in a given software development project. Why generic? Because I don't think it's possible to model every Scrum project. So I created a generic model that would fit the Scrum principles and rules and follow best practices recommended by respected practitioners, but that could be easily modified to suit the needs of a particular project.
The method is simple and fits with little effort into Scrum. It is cyclic, composed of four steps: (i) Analyze model, (ii) Feed model, (iii) Analyze model’s output, and (iv) Apply corrective and preventive actions. The cycles are synchronized with the length of the sprints, but they don't have to be the same. For example, one method cycle could last for one, two, or three sprints. The important thing is that step iii occurs during a retrospective meeting. The method is shown in a flow chart here:
During the first step, since the model is generic, the ScrumMaster and other Scrum team members analyze whether the model suits the team’s needs. If not, it is modified. During the second step, the ScrumMaster and other Scrum team members analyze the project's current situation and feed the model. These first two steps could be executed during a sprint and it should not take more than 45 minutes. The third step occurs during a retrospective meeting. During this meeting, the model's output analysis will serve as an extra source of information that will help the team identify and prioritize areas that need improvement. The output of this step, as should happen in a retrospective meeting, is a plan for executing corrective and preventive actions. The last step should be performed by the ScrumMaster, who should check whether the actions committed to during the retrospective meeting are actually being executed. This last step does not add effort for a good and dedicated ScrumMaster, because he/she should already be doing this!
The model’s idea is simple. I identified Scrum`s principles, rules, and best practices in the literature. Afterward, I validated my findings with a group of 11 practitioners with experience around the world (USA, Brazil, Europe, India). Afterward, to finalize the model, I published a survey (with the help of Scrum Alliance) and more than 40 practitioners around the world answered it. After some statistical analysis and testing, the model was considered done. (I am leaving out a lot of technical details for simplicity. This work was published at the Symposium on Applied Computing 2013, and you can contact me if you want to take a look at it.) The complete model, as a graph, is shown below:
So far, this method has been validated in one company as successful. It was identified that the effort to use the method is very low. During the first iteration that the method is used, because the team is not used to using the model, steps (i) and (ii) need more effort than during other iterations, but none of the meetings lasted more than 45 minutes. Given that and the problems that were detected, the return on investment is positive. Also, we found that it can help both experienced and novice Scrum teams. Experienced and novice teams can use it to check the project's status and detect problems. On the other hand, novice teams can use it as a reminder of things they need to be observing during the project.
In the future, we want to perform case studies in several companies around the world. We believe that applying this method can really help us increase our rate of successful software projects. If you would like to participate or add any additional information, feel free to contact me.