| || |
Merging Test Projects
Does anyone have any experience in merging separate test projects into one combined test team? I currently manage a test team with 5 people and 4 products and there is currently discussion about merging with another area which has a test team of 3 and 1 large product which is already live. I would be running this combined team, with senior testers leading certain areas. The resources will be shared and swapped between the products though.
Anyway I have many ideas about how to go about this, but simply wondered if anyone had prior experience of this sort of scenario. The two areas have been almost completely separate up until now, so do not share any processes, but they do both have the same defect tracking and automation tools, so that will help. It's the build/release/defect etc processes that I am looking for info on, as they will be different and we'll need to move towards shared processes.
Any opinions, experiences etc greatly appreciated. Especially what not to do....
Re: Merging Test Projects
I am going to suggest that in the first instance that you do the hardest thing – Don’t change anything at first. Whenever you take over a team of people, whether you be new to the team or, as in your case, taking on an additional team, the temptation is to change things to suit what you know. That can be a total disaster.
I have been faced with this situation a few times and the approach I take are as follows (and, by the way, this is not invented by me, it is a consultancy technique, called the “7P Model”):
1) Purpose – find out what the purpose, mission or goal of the team is. You may have some idea already of this, but what do the team think their purpose is? Does it match with your perception? Does it match with the company perception?
2) Positioning – How does the team fit with its environment? How is it perceived by its customers?
3) Plans – How are tasks organised? What is the structure of the team?
4) Power – What is the power basis? What is the sphere of influence?
5) Processes – What are the internal processes? How are those processes communicated? How flexible are they?
6) People – What knowledge and skills do they have? How do the people relate to each other and to their customers?
7) Product – What is the service/product that is provided by the team? What are the delivery mechanisms? Do they effectively serve the purpose?
What the 7P Model boils down to is find out what currently happens and how, then evaluate how appropriate it is. If you already know how your current team works against these 7 items, well and good, if not, it is worth doing the same exercise for your current team.
Once you have done this (and we are not talking about a lot of time, a couple of days should be sufficient), then is the time to start looking at what needs to be done to integrate your two teams. Here you have four possible approaches:
1) Change everything your new team does to match what your current team does – by far the most tempting option!
2) Change everything your current team does to match what your new team does – by far the most unpalatable option!
3) Merge the two teams’ processes to get the best of both – at the risk of getting the worst of both!
4) Keep two separate sets of processes – by far the easiest option, at first.
I can’t tell you which of these options is the best for you without knowing more about you, the company and the teams, so you need to work this one out for yourself, except to say that Option 4 will give you the most headaches and Option 3 the most amount of work.
With any of the options. you will then have to manage the change – even Option 4 requires managing as you are still changing the management of the test team, i.e. you are a change to the new team.
Looking at it from the company perspective, there will be a change for the customer. He/she/they will be dealing with a different person now, they are used to dealing with the team in one way and now they will need to deal with it in a different way. You need to smooth that path. If the team is already a successful one, there will be concerns that the success will be less. If you change the way that builds are done, the way that defects are managed or whatever, then you will need to sell this change, you need to get the customer on your side.
Looking at it from a human perspective, there will be an element of nervousness amongst the people you are taking over. They will be wondering what you are going to be like as a boss, how well will they work with you, how will their objectives change, what will it mean to their career. Change concerns people. It is your job to make the change as painless as possible for them.
To manage that change here is another acronym for you – EDICT, which I have always thought to be an unfortunate acronym as it implies dictatorship, which is not what change should be about.
E – Entry. This is about getting into the new relationships that you have, both inside the team and outside. You need to establish the working relationship, understand the common ground, establish your credibility. This is done by another technique, called “talking to someone” . Set up formal and/or informal meetings and listen. At this stage, listening is the most important thing you can do. You need to find out where any barriers, problems, distractions might derail anything you try to do.
D – Diagnosis. Understand attitudes, issues, the flexibility of people to change, what problems need to be fixed, what is working well.
I – Intervention. Float your proposals for change, educate those who need educating, show how the change will be managed, the timescales, the activities.
C – Contracting. Gain agreement to the change. This has to be from all the stakeholders, i.e. the customer, the test team and your management.. Show how you have listened to others, what you want to do about the points they have brought up, who will do what, when, how and how much cost/effort.
T – Transition. Do it. But don’t just do it in isolation, make sure everyone is fully informed on how the change is going, what obstacles you are encountering and how you are overcoming them.
Hopefully the above explains my very first statement “Don’t change anything at first”. I realise I haven’t answered your question specifically, because I don’t think I can do that without knowing more detail, but maybe I have given you some pointers as to the way forward.
Re: Merging Test Projects
Merging your team is a great idea, however success depends on the test process each team uses. IF you have a process are they the same? If not choose the best of both, could be determined by checking with management of both teams for teamwork, activities, tasks, responsibilities and deliverables. If neither of the teams have a process in place this would be a good time to consider one before the merge. The TMM (Test Maturity Model) is a good process to assess what each test team has in place and which is the better of the two. If you need professional assistance call Illinois Institute of Technology and maybe they can help you with an assessment.
Remember, two unorganized test teams will double the consequences, one organized test team will be successful.