Development Team Progress

Recently I was reviewing the progress I had made with the development team (at work) since to took over responsibility for them around 8 months ago. It is actually pretty impressive (even if I do say so myself):

• Agreed and published a set of common / shared values and mission statement (gives shared ownership and a sense of responsibility)
• Upgraded to Visual Studio 2005 – providing them with the best tools to do their jobs (improves productivity).
• Migrated from Visual SourceSafe to Team Foundation Server which is much more stable and has better branching and merging facilities (improves productivity).
• Implemented an overnight build process and some ownership/responsibility for ‘breaking’ the overnight build (improves quality).
• Implemented a system that allows each developer to build in one click (improves productivity).
• Implemented automated testing of the overnight builds and any build version that leaves the building to go to customers (improves quality).
• Provided them all with dual monitor configurations and larger LCD screens (improves productivity).
• Automated the build/version number change (improves quality and tracking).
• Implemented new processes for how we ensure bug fixes are rolled into future version (improves productivity and quality).
• Automated most of the help / manual / documentation build process (improves productivity).
• Provided them with 64 bit servers for testing / virtualization (improves productivity).
• Implemented SCRUM (more like a watered down flavour of it) thus giving more visibility to deadlines/timescales and goals/objectives (gives shared ownership and a sense of responsibility)
• Documented a technology vision statement that outlines the technologies, processes and our ‘mantra’ at a high level while allowing the individuals to interpret the implementation at the next level down. (gives shared ownership and a sense of responsibility)
• Implemented a real bug tracking database (improves quality)

There are two things about this though:

1. When I say ‘implemented’ or ‘upgraded’ etc what I really mean is the team did it, my involvement in most of these items has been to question if we had it, how could we do it (better), did we need it, how did other people in the industry solve those kind of problems.
2. When I say ‘improves productivity’ this is purely based on a ‘gut feel’ measurement (and often general consensus from the guys working in/with it), some of the items I know for sure (like the time SourceSafe corrupted on us and two guys spent hours with print outs and pens ticking off the files as we manually merged them, and reducing the several hour version change process where we manually edited the version is 2976429865264264 files and the kicked off a build, to 20 minutes)

This is not me blowing my own trumpet; I didn’t really do much of this except ask the questions that kicked of the activity.

When was the last time you questioned what you are doing or compared it to what / how others in the industry are doing it ?