My current test organization has to deal with different development processes. This is what happen when you start building a software test organization on top of a company which has had a strong acquisition strategy for the past 10 years. It didn’t necessarily had to standardize the development process as the various products were not  integrated together. Things get a bit problematic when you actually want to take advantage of this integration to build better solution. When you deal with origination, customer management, fraud, collection, decisioning, score card analysis etc. you definitely want to mix and match the features to offer sales and marketing the largest range of options to meet customer requirement and, of course, cross-sell.

3 years ago I had to deal with all kind of processes: The no-process strategy (my favorite .. sight), heavy waterfall (I’m still soaked by that one …), home grown iterative process etc. Scrum was definitely only discussed during a good Rugby game.

New leaders, organization structure and a will to integrate better our products and our team brought us closer to a formal iterative process for most products. Still not as agile as I would have liked but in the right direction. In the meantime, I’ve setup a new testing organization in Kuala Lumpur, alongside with the development group responsible for a new set of products. As it was a new development center, we didn’t inherit any existing development process and it was decided to go with scrum. My colleague and development director operating locally was very knowledgeable about scrum and it made the most sense.

This is where it gets interesting (I realize this was a long introduction but I wanted to give you a bit of a background). A lot of developers and testers from other part of the world are engaged in delivering the new softwares but, for now, stayed on their own development process. There were good reasons for this but my organization ended up testing a software developed in multiple location, which is fine, but with different development processes in each location, which is definitely not fine ! If the development teams are independent, working on different products, I’m fine having to deal with different processes. But distributed development with different processes is a big no-no !

You’d think that we might have been better off standardizing on scrum right at the beginning of the project. Maybe, maybe not (we’ll never know). I actually see some benefits which could prove useful in the near future. For development and test teams working on non-agile processes, scrum might be a BIG cultural change which you probably have to introduce with care. You might want them to realize the benefit of scrum on real projects to get their mind ready. I see these few months where we’ve been on different processes as a first step to transition for a large development organization.

So you’ve got buy-in from executives management. You’ve got your developers, testers, product managers, a bit more comfortable with scrum. How do you ensure they don’t go wild and actually embrace and apply it properly?

If you already have people trained and experienced in scrum within the different groups, you might want to use them for internal trainings. They really need a first experience as a ScrumMaster so they can work with the team, the stakeholders, the product owner etc. Explaining the concepts is not the big challenge here. It can be done fairly easily. The whole challenge (and fun) is the implementation of the various principles and the proper use of all scrum artifacts. The person needs to set the dynamics, the pace. Ensures that everyone understand their new responsibilities and role and how they fit within the new process. The person doesn’t necessarily need to be the scrum master but need to be working daily with the team until stability is reached.

You need your ScrumMaster to be the cornerstone of your process, especially if you have to deal with distributed development were it will be mandatory for your local process to scale. You will end-up necessarily in a scrum of scrum. I was talking to Lisa Crispin during the SEETEST conference I’ve just attended and she has just started a new job where she has to deal with 28 scrum teams across the country ! Their daily scrum of scrum is 15 minutes, as it should be. Really impressive and inspiring !

So you can have internal training, getting help from certified scrum master to help you training your team. What else? Well, I’m a firm believer in self-training and we need to take advantage of all the resources around us. It’s not like we’re in the 60′s trying to learn something about a new subject. This is 2009, I can order whatever book I need on any given subject and have it delivered the next day, I can find tons of information on the Internet: White papers, ebooks, articles, training video etc. I can participate in specialized forums to engage in discussions, get answers etc. We have NO excuse. You just need to be careful and really scope your research for information as it is endless. You might want to give pointers to your organization to get them started.

I find this video quite useful as an overview of scrum. It can be given to everyone in your organization from your developers, testers, product owner, executives and also stakeholders. I would say especially stakeholders as they might not understand what the fuss is all about and how it’s going to help them get better softwares. They also have a role to play in the process and they need to understand it properly. Executives are also key people to “train” as you definitely want their buy-in and full support. Be careful, this is not a comprehensive training of course and miss quite important point but it’s still a good high level overview.

There are hundreds of books about scrum and I didn’t read them all. I read a few and I can recommend these two. Their short, comprehensive, easy to read and to the point.

Here is a also a short Powerpoint presentation which could be a good starting point to build a consistent presentation for your team. Click on the picture bellow to download it.

Changes can frighten some people: Fear of the unknown, afraid to fail, afraid to get out of their comfort zone. In my mind, changes are one of the best way to grow. You sometime want to be careful, plan properly, evaluate different options, have a plan B. But in the end, most changes bring benefits.

I will probably come back regularly on this subject as we’re right in the middle of the transition and I’m pretty sure this is going an interesting roller-coaster ride !