Any insight into merging 2 IT Teams (one agile, one traditional) together successfully after M&A exercise?
CIO in Finance (non-banking), 10,001+ employees
Great ideas. In my experience, you also have to be very sensitive to the change management and HR challenges. For example:1) What are the training opportunities & requirements for both teams?
2) What does the combined org look like?
3) How are roles in the new org determined - skills, experience, interviews, etc.?
4) What options are there if someone is not a good fit / not interested in the new organization?
Good luck.
Board Member in Healthcare and Biotech, 1,001 - 5,000 employees
Did this a long time ago in an M&A, so here's what we did:1. Starting point, acknowledge the different operating models and list out what has worked and what has not for both teams. The buckets will help them understand different perspectives which they may not have experienced.
2. Seek alignment to individual goals when they become part of the merged team. What they do to what would be expected of them. Better to do that now rather than find that they leave quickly after the integration. In my case, some of them declined to join the new team and left, I was however able to retain some of the key members including the CIO
3. Divide the roles in a way that there is appreciation of each skill and work. New age developers who are used to sprints and agile find waterfall and operations uninteresting. Have also seen dialogues like, "Development is over, its for you to deploy and maintain" or "My job is to provide operational support, you ....".
4. Take the team out and mix them up in an offsite if possible, they may be uncomfortable to begin with, but will probably tolerate each other before some semblance of bonding happens with some of the members.
5. Finally, be prepared for conflict, it will happen and test your patience. Pick the leaders from both teams to thrash it out, mediate only if absolutely required (assumption: you are the senior-most person in the group).
Best of luck !
PS: if you would like to have a chat on this, do reach out.
IT Director in Education, 11 - 50 employees
Without question I would say paying attention to each other's strengths and weaknesses would be at the top of my list. Each team is going to bring different skills, perspectives, opinions and likely a good idea of what works well and what doesn't. Capitalizing on these differences would be paramount in a successful transition.Evaluating processes and procedures from both sides should lead to good compromises and discussions going forward. The biggest barrier would likely be loyalty to each person's "side" and not wanting to change.
A traditional approach to IT would provide stability and predictability while lacking adaptions to more current structures such as remote computing and virtualization. The more agile team would be able to bring these new technologies to life adding a much needed boost saving money and helping workers to be more productive.
Senior Director of Engineering in Software, 501 - 1,000 employees
From my experience the first question that needs to be evaluated is:- do both teams need to align in agile or traditional methods?
If the answer is no, that's fine. I worked in a company that a critical system was developed/maintained in waterfall and non critical systems were developed/maintained using agile. It works surprisingly well. :)
If the answer is yes, then you'll need to go through change management, hire Agile Coaches, promote a cultural change (it takes years), educate stakeholders and provide the right tooling and practices in order for a team to be able to do sprints.
I intentionally wrote sprints since Scrum is the best starting point for teams to begin their agile journey.
It will take quite a long time but it will pay off.
AVP and Deputy CIO in Education, 10,001+ employees
It may seem basic or "old school" but I always start with MVV, mission, vision, values. How does the IT team align with the mission of the organization? What is its purpose? What are the internal values and how does that align with your mission, vision and values for the IT organization and how does that align with the new organization? What business problems are you trying to solve? You'll want to build a single team, which will likely result in turnover from both teams. That can be a good thing, depending on the strengths and weaknesses of the existing teams.MSP & IT Director in Services (non-Government), 2 - 10 employees
There should definitely be some form of integration / collaboration between these two teams but still acknowledging the different strengths of both teams and giving them the room to excel at their strengths and goals.IT Director and Software Producer in Software, 11 - 50 employees
I'd bet that each team has something to learn from the other. Don't be too quick to dismiss the "traditional" as antiquated or behind-the-times.IT Director in Education, 11 - 50 employees
Without question I would say paying attention to each other's strengths and weaknesses would be at the top of my list. Each team is going to bring different skills, perspectives, opinions and likely a good idea of what works well and what doesn't. Capitalizing on these differences would be paramount in a successful transition.Evaluating processes and procedures from both sides should lead to good compromises and discussions going forward. The biggest barrier would likely be loyalty to each person's "side" and not wanting to change.
A traditional approach to IT would provide stability and predictability while lacking adaptions to more current structures such as remote computing and virtualization. The more agile team would be able to bring these new technologies to life adding a much needed boost saving money and helping workers to be more productive.
Manager in Education, 501 - 1,000 employees
Proceeding under the assumption that you will be adopting Agile for the newly merged team, the bulk of your energies will obviously be spent in evangelizing and training efforts to compel the traditional team to adopt Agile -- the more established the trad team, the more time and effort you'll expend to win converts.As an Agile project manager, I've repeatedly encountered foot-dragging and patronizing dismissal of the methodology's roles, rituals, and expectations, primarily from resources with extensive work histories (whose careers were born and built in a world where waterfall was the only way to manage a project). This can be a difficult nut to crack, as you need to take care not to alienate these folks, while still compelling them to get with the Agile program.
I recommend that you work closely with each team's leaders so that the traditional lead doesn't feel at risk of being marginalized in deference to the Agile lead (who should be encouraged demonstrate the spirit of servant-leadership by supporting and empowering the traditional lead in their adoption of Agile practices).
Business customers of the traditional team will also need to be educated and inculcated in the ways of Agile project management, as they will likely be far more involved in the process than they were previously.
If you are planning on moving your Agile team over to traditional waterfall management, my advice is simpler and more direct: don't be surprised if you experience attrition with the formerly Agile team, as many resources will seek to maintain an Agile workplace.
Content you might like
Reduced costs27%
Faster deployments58%
Improved security standards46%
Improved scalability47%
Fewer errors30%
Improved consistency30%
Improved visibility12%
No configuration drift6%
Improved stability6%
391 PARTICIPANTS
CTO in Software, 201 - 500 employees
Without a doubt - Technical Debt! It's a ball and chain that creates an ever increasing drag on any organization, stifles innovation, and prevents transformation.Community User in Software, 11 - 50 employees
organized a virtual escape room via https://www.puzzlebreak.us/ - even though his team lost it was a fun subtitue for just a "virtual happy hour"
Budget/Investment31%
Staff44%
C-Suite buy-in14%
Cyber Security9%
Time1%
225 PARTICIPANTS
A group working session where the two teams identify their purpose, what value they provide and a candid discussion about their history (heritage) and things that are sacred to them is a good starting point.
From there, performing a SWOT analysis of the team will help understand strengths and opportunities for collaboration. Next, a forcefield diagram exercise where both the teams identify headwinds and tailwinds for success will outline the challenges and help them develop countermeasures.
Once these two are done, the next step is to work out a teaming agreement on how to achieve the business outcomes of the team. This is where processes, approaches, rituals, etc., will be discussed.
Starting with the why and then moving to the how not only empowers the team and helps them empathize with one another, it also entrusts the team to figure out how they can be successful and reduces sentimental attachments to prior process (this is how we did things, our agile is the only way, etc.)
PS: There are several nuances involved, but I feel that this is a good first step to start things in a collaborative and empathic manner, rather than with contention.