07 October 2010

Thoughts on SCRUM

Scrum is applied in many software companies in Bulgaria some of which I have been given the chance to work for. Such companies include Axway Bulgaria, Software AG, Nemetscheck - Buglaria etc. I also have been able to observe how it is applied in other companies such as SAP, VMWare, Microfocus etc.

Of course adapting the Scrum methodology has presented different challenges for each different company, but there have always been patterns that could be noticed everywhere. I personally believe that adapting Scrum has always been successful, although I took a different amount of time and effort depending on the situation.

Here are some of the typical issues that I have witnessed.

Lack of commitment from the team

Origins
Many developers find adapting this technology a "management" decision. Not given enough information and provided with no options it is only natural to react negatively. Scrum is also not the first attempt to change the way developers work and organize their teams. Many have failed and we all know how expensive adapting the newest technological or methodological "hype" has been before.

Ways to counter this effect
I know that developers tend to welcome change with much suspicion and skepticism, but since the methodology actually aims at empowering the team and removing any outside (and inside) obstacles, I firmly believe just about any developer could be convinced in giving Scrum a chance.
Managers that are involved in such changes have to completely understand the methodology and find ways in providing this information in the best way to the people involved in the process. Each person should know why each role is important, what their exact goals are. It is crucial to have a well educated, dedicated Scrum master as this is the person is vital to adapting the methodology in the best practical way. Such a person could help team members understand the process and in the same time adapt the process to the team members themselves.

Lack of commitment from the management

Origins
Sometimes the change is provoked from the teams themselves. In such situations not having the full support of the management could be fatal to the overall effort, thus making a team even less productive then before adapting the process. The Scrum methodology is flexible, but it does have some principles that could not be avoided. The team needs empowerment in order to improve itself. It needs to be able to change itself, otherwise the whole idea behind retrospectives and task estimation is useless. The team needs to have some notion of the basic team roles followed otherwise responsibilities would be vague and the overall process organization could not achieve the ideas behind agile development. These and other principles are vital to adapting Scrum and achieving something partial or incomplete could prove fruitless.

Ways to counter this effect
Obviously the management needs to realize that of adapting Scrum requires much effort, the investment of both time and money. There are many papers online on the topic whether or not a company should adapt Scrum and I do not intend to discuss this. The rule that I would recommend following is : either be prepared to commit to adapting Scrum or stick to the methodology that currently works best for you. Scrum is not simply a set of ideas that could be adapted on a case by case basis. It is an agile methodology with a set of principles aimed at making teams much more productive. It is unusually adaptive, but nonetheless it has some basics that need to be understood and adopted.


Various misinterpretations

Origins
It is sometimes hard to apply the methodology on a team, especially if the team has been working for years using some waterfall methodology or other ideologically different process. Many of the notions behind Scrum contradict to those of non-agile processes, such as the notion of having a shippable product at the end of each iteration. In such situations team struggle to change their ways and sometimes, not given the proper support and encouragement, they give up halfway before they achieve their goal. Not reaching their goal (such as the example above with the fully shippable code) could both lead to drop in performance as well as drop in moral and loss of confidence in the effectiveness of the process.

Ways to counter this effect
Much of the things I have already mentioned already. The role of the Scrum master is one of the most important ones and needs to be held by a very ambitious, well trained and patient team member. He needs to believe in what he is doing and have the qualities to encourage certain changes. Scrum is all about dynamics and change and this must be his top priority. Management support is also an absolute must. Trainings, lectures, consultants or whatever the team needs - these are all investments that would pay off in times their initial value.

Overall situation

From my perspective of a software developer I think the Scrum process is being adapted fairly well in Bulgaria and the world as a whole. It is building up momentum and perhaps one day it would be the most widely applied. As with any other methodology (or technology for that matter) it is often misinterpreted, partially applied or not given enough credit, but still there are many companies that have achieved both better efficiency and better team collaboration.