Friday, November 11, 2005

 

A tale of two teams

One of my customers has two teams (about 20 developers each) working on different projects in the same domain. Projects tend to be rather long (in modern speaking :-), taking from 6 to 12 months to complete. Both teams have a somewhat defined development process, though they don't use formal documents. They both use UML, GUI prototyping, a separate testing team. The use different programming languages, but this is probably just marginally related to the difference between the two teams. Because there is a difference.
Team A is approaching new projects with a somewhat long preparation. Marketing is providing sketchy requirements, and they have to do their best with that (as it's unfortunately common, they don't seem to get along well). They will build prototypes several times before the user interaction is approved. They will analyze the problem in depth, build design models, then go ahead and implement the system, with some degree of iteration between design and coding, trying to avoid requirement creeps.
Team B is approaching new projects with a shorter preparation. They are not using an XP or agile approach. Quite the opposite, they will have a solid design as well before they start. The team, however, can afford a shorter preparation because they did some part of if during the previous release. Of course, that means they didn't went in the larval state of coding for as long as Team A did. They resurfaced often, thinking about the next product, experimenting with new technologies, talking with marketing guys about what could be next, trying to influence marketing as well, and so on. There is definitely less conflict between Team B and marketing, although it must be said that they talk to different people than Team A does.
The teams didn't chose their style. They are, I believe, the natural consequence of the personality, beliefs, and attitudes of their managers. However, members of one team are much happier than the others (guess which? :-). Now, I understand happiness may not be concern #1 in most work environments, but it should be. If you're not happy with your job, there is no way you can perform at your best. Multiply this by 20, do a little math, and you'll see how much money is being wasted (both current money, in terms of salary, and future money, in terms of revenue from what they're building).

Comments:
which is the happier team?
I did not understood...and why?
 
Team B is much happier.
This is only partially due to the more relaxed interaction with marketing. Insted, it is largely due to the process they use. Team A is unhappy because a long preparation, followed by a long development phase, is no longer aligned with the outside world. The world is changing too quickly.
For instance, Team A is largely unable to constantly catch up with technology: during preparation, they can spend some time on new technologies, but during development, they will simply go larval and code. They'll find themselves left behind as they emerge later. This dynamic alone is worrying to say the least.
Team B is enjoying a level of freedom and flexibility unthinkable for team A. This is also due to the level of trust within the team, but that would be another long story :-)
 
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?