SCRU Mbol

Hi Everybody,

Unfortunately, my presentation for the session "Introducing XP in your Daily Job" at ESSAP08 took longer than expected (or maybe the pomodoro just lasted less than expected :) ) and I could not share some results of our experience. In trying to recover from my fault, I will share here some interesting findings.

Overview

During the presentation I talked about the Funambol environment and product not for mere promotion, but to provide some background about the complexity of our environment. I think it worth to summarize the crucial data here:

• international company
• team of about 30 people for product development
• remote development
• many components both server and client side
• in introducing SCRUM we split the team in four SCRUM teams working in parallel with a sprint of 4 weeks

Challenges

The first challenge we encountered is about writing user stories. Pretty much the whole team was really beginner in writing US and we faced a number of issues in finding the right size or making them self-contained. Plus, it is not easy to manage inclusion and dependency relationships. I believe this was the root cause of many issues found later in the process. Lastly, but not less important, at the end of the US definition phase we had more than 400 stories.... I could not find a board that could stick them all! :)) Jokes apart, when you have such a number of US to manage and maintain a tool is absolutely required.

Due to the fact that many US were too big, we had issues in estimating them and in respecting such estimates. Many US could not be completed in a single iteration and this gave a bad feedback about hitting the iteration goals. It made also difficult the iteration planning.

The other big challenge for us was the cultural switch from a model based on centralized responsibility (the server team lead was responsible for the committing and the deliveries of the features) to a distributed responsibility model (each SCRUM commits the US it feels can do). This was due to many factors, the most important one being the human factor. Too many times people talking about XP and agile put their self in the best position possible, where you have only teammates super motivated that do not aim to do anything else in life than pair with a co-worker... :) ... well, it is not always the case. Certainly it is not the case of my team. Ok, I will be more careful for new hires, but what about what can be done now? Agile and SCRUM require a lot of discipline and it is much harder than it seems (and evangelists tell you ;) ). Also the pressure on the teams was very high and some people has been feeling in a continuous release mode, under the psychological pressure usually associated to Ga release. This is the opposite of what agile is suppose to do...

In addition to traditional issues in applying SCRUM in an existing organization, I believe we have been challenged by the particular case of our development environment. Multiple teams, with people remote, many iterations in parallel, many deliveries. All this had to be managed and required coordination in all phases of development (design, coding, releasing, testing, etc). I think we can improve a lot in this area, but likely I feel this is the field where existing tools and methodologies help developers a lot.

Benefits

All the above said, I want to remark I am still a strong believer in SCRUM. The number of deliveries we have done in the last few months is just amazing. And the management cost of the whole process was really lower than I expected and much lower than a traditional process. Plus, the product management team was very involved in the product definition and appreciated the iterative nature of SCRUM. The planning game worked very well and I believe that estimating in story points is one of the best innovation in estimating techniques. I also think that we managed to reduce bottlenecks and made a more efficient use of our resources (thanks to frequent re-prioritization). In few words, I cannot think of a different process to do all what with do in the extremely competitive field we are!

Conclusion

To summarize:

• I am still a firm believer in the SCRUM process
• We have many areas of improvements
• SCRUM is less easy than it looks (and less easy than people tell you :) )
• SCRUM must be diligently managed

You can find my slides here.