March 8, 2004 at 10:49 am
At my place of work we have three independent teams of developers. Each group uses their own programming language and tools. No group has more than 3 members (though we do have "full time" consultants that work on weekends and after hours). Generally, the groups have minimal interaction (maybe because of their different development environments). This fragmented setup has simply evolved over time and is not optimal or desired.
Three teams, three languages, three group leads, minimal interaction. I think we need a different development architecture such as a "master" project leader in charge of the group leads, a few less languages, and a comon code base.
Do you have any ideas for improving our lot?
Bill
March 8, 2004 at 12:32 pm
I think you already hit the solution on the head....
You need "one ring to control them". Putting someone in a broad overview position to assess projects and assignments, apportion out the workload, bring in a sense of teamwork by blurring the boundaries between the groups. This can be done by that one guy, he can look at what you have now, decide on a direction to take and start to lead everyone that way.
March 9, 2004 at 11:00 am
I think getting everyone using the same software would make a huge difference. You seem to hint at the different development environments being a main cause for the lack of interaction between the teams. One of the first things to do in any software engineering project is make the decision as to what software and tools to use for the project. You then stick with those tools unless something comes up with enough importance to override the previous decision.
If you want these three teams to be able to work together then on a technical level they need to be able to work together, if you get what I mean.
March 10, 2004 at 7:45 am
We have a similar situation at our workplace that includes various scattered development teams throughout the organization. It has evolved this way because the individual business units wanted their own priorities completed faster. The down side to this is more complex maintenance at the corporate level and duplication of efforts in some cases. If making a large organizational change with new reporting structure seems too daunting at first or doesn't get the agreement of all parties, perhaps setting up a regular meeting (maybe bi-weekly for an hour) with the members of all the teams together to discuss the projects everyone is working on. You may find that people start to see that there is a benefit to working together or things to be learned from the other teams, even if everyone is working with different languages/tools. Gradually people will begin to see that it makes more sense to try to work more closely as a larger team and will see the benefit of standardizing the develpment process.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply