views:

144

answers:

3

I work for a large company currently going through a merger. We are working on several projects involving and not involving the merger. One problem I'm noticing is that many of the groups of developers are very fragmented, even though they mostly support many different projects within their own realm of the business, and the databases we all work on seem to reflect that as well. I am not too confident in the accuracy of much of the data because of it.

Are there any models or standards out there that have been successful in managing these types of changing environments? What are good ways to communicate those changes to the users? Are there ways to create redundancies so if a change is proposed on one part of the production, it gets communicated up and down the pipeline?

Edit: making this community wiki due to its subjectiveness

+1  A: 

Your large business sounds like every other one. How many of these characteristics apply to you?

  1. Diverse eco-system of servers, operating systems, systems, languages, databases, etc.
  2. Duplication of systems (e.g., both companies in the merger have systems that do the same thing in slightly different ways).
  3. Many redundant databases; no one source of truth.
  4. Data shared by multiple applications.
  5. Lots of complexity and dependency that makes it hard to test code.
  6. Lots of complexity caused by "practical" efforts to work around limitations.

I don't think common sense or professionalism or any magic is going communicate changes up and down production.

duffymo
Yes they all apply. I find it difficult to live with this as an acceptable current state.
mandroid
A: 

One thought is to have a group of people that oversee the projects to make sure they are in alignment with the business. It takes some leadership to keep things from becoming a train wreck.

I know in Scrum, there is the concept of Scrum of Scrums. Basically, a representative from each team meets each day (or less often in some cases) to tell what the team has been up to, what they are working on today, and discuss obstacles (which may be the other team(s)).

Also, agile practices in general address exactly your problem in that they anticipate change.

So, if management is not keeping things on track, there is going to have to be some really good communication and leadership from within.

Greg Ogle
+1  A: 

Dedicated resources for process oversight, migration and creation.

We have gone through merger and unmergers, then we bought other companies and are in the process of integrating them in our "process". I quote process here because, in my opinion we still do not have any to speak of.

Where we will eventually succeed I think is that we have dedicated resources in creating a process that works and that is company wide. Scrum is all good but it does not necessarily apply to the billing and marketing cycles of the enterprise, however it would works wonder in our dev, R&D and implementation teams (maybe even make a single team out of all three!). So how do we come up with the best process and practices for each to work efficiently in their areas of expertise while keeping it all tied in together ?

Our magic bullet here is that we have someone dedicated to this very task, he looks at how it is now, looks at what is needed and draw plans to get there and then executes them. He will work with the departments, with IT and whomever is required to get it done. Most important of all, he has the leadership and backing from the big heads to give him the proper leverage to get the big heavy boulders rolling (I'm sure you have these, any company big enough eventually gives a nice comfy chairs to whomever has exceeded their Peters threshold). Once the process is defined there comes the task of tooling the process appropriately and migrating all the data from all the different systems adopted ad-hoc by each teams - companies prior to the definition.

To do all this while you have to do your other tasks is but impossible, I know nearly got fired trying to do just that (stepped on one to many of them boulders), is why you need dedicated resources to this internal structuring. If you do not have this yet in your company I would make this my first field of battle.

To make an analogy what we got here is a Chef d'Orchestre that knows what a process is and that has the pants to get it done. This cannot be CE* type persons they are too busy for this but someone not in the critical path of any projects. That way he remains objective and can take a step back and look at the big picture without being constantly sucked in the zoo. I find that someone with development background that has experience in both agile and formal process paradigms is best suited for this job. The development process is most likely the hardest one to really nail and get going, if he can do this, the rest should be easy, least on paper.

Ever since we got this here changes come, it comes slow but it comes and so far it is a god send every times. Every changes made brings to light how the rest is inefficient and gives him more ammunition to get it done. This way I find it easier to live with the inefficiencies knowing someone is working at it and they will, eventually, be ironed out.

I wish you luck, it is not impossible but it is definitively doable.

Newtopian