Ahh, New Year's Resolutions...
Lose ten pounds.
Stop smoking.
Add code coverage to the continuous integration server.
Wait, what was that last one? That's right, I'm talking about New Year's Resolutions for your development team. You see, this is the time of year when we start thinking about our goals for the next year at my company. Not only our own personal goals, but our team and department goals as well. Every year about this time, all of our developers and I sit down and talk about what we'd like to accomplish in the new year. This may be an improvement to our infrastructure, such as adding additional metrics to our continuous integration server, or something more process oriented such as an commitment that we'll start introducing security reviews into our standard code review process. 
Whatever it is, setting it down on paper and becoming accountable for it will help you reach these goals. And, if you choose the right goals, then these goals can dramatically help your team. Odds are that you already have something in mind that you'd like to improve about your team or your process. Or something that you really had planned to do this year...but just never got around to. Well, here's your chance to make it a real goal for 2009.
Here are some tips for choosing and sticking to those goals...
- Measure It!
Make your goal something measurable. At the end of the year, there should be no subjectivity as to whether or not you met your goal. For example, "Get better at unit testing" is not a measurable goal. Instead, you may want consider a more defined goal which relies on a metric, such as "Increase the test coverage of our legacy code to 80%". - There is no 'I' in team.
Don't choose your goals in a vacuum. Even if you're the lead developer for the project, these are your teams goals. Sit down with all of your team and make sure that everyone has a voice in the selection, because everyone will be accountable for seeing that they are met. Also, make sure that you choose goals that the team must work together to complete. Individual goals are important, too, but this is not the place for them. For example, "Ensure Bob completes his MCTS database developer certification" does not belong on this list. - Be flexible.
Be prepared to revisit your goals on a quarterly basis. Things change fast in our industry, both with platforms and technologies and with our own product lines and goals. Goals that you set today may not make sense 6 months from now. Make sure you're working towards your goals because they actually help your team and your company, not just because you need to complete them. If a goal that you set originally no longer make sense for your team, then replace it with one that does, or don't be afraid to drop it altogether. - Hang them out for the world to see.
Remember what I said before about accountability? Being accountable for these goals well help your team reach them. Don't just write your goals on a sheet a paper and shove it in your desk drawer. Write the goals, discuss them with your manager, and then hang them out for all of the world to see. On my team, we hung our goal sheet at the entrance to our cubes so everyone that came in to "dev alley" could see what we had set out to do, and judging by the checkmarks, they could see how we were doing. Next year, our goal sheet will hang with our information radiator so all of the company can see how we're doing.
Setting and sticking to goals can be a great way to ensure your team is continuously improving. Making these goals public to everyone around you can make sure that you and your team are invested in completing them. Now's the time to start fresh, decide what you want to improve, and to act on it.
Here's to a great 2009!
Look around your current team. Do you have 'the database guy', 'the UI guy'? How about 'the business logic guy'? Odds are pretty good that you do. How did it get like this? Maybe you specifically hired your database guy to do your database work, or maybe this guy just had a knack for databases so he just kind of fell into it. Regardless of how he got there, this guy quickly became you go to guy for all of your database design, your stored procedures, and your data access layer.
What's Wrong with a Layered Team?
Regardless of how it started, it likely has worked out so far or you wouldn't have continued to pigeonhole him as 'the database guy'. Great. What happens when your database guy takes a two week vacation right before one of your critical stored procedures breaks? Who do you have that can jump into the fray and take over? The UI guy? Maybe, but he hasn't worked with anything but javascript and CSS for months, he has no idea how the data access layer works, how it relates to the code, or even where the stored procedures live in source control. Maybe your business logic guy? Well, he may be a top-shelf C# developer but his SQL skills have gotten pretty rusty as of late since he's been lured into a false sense of security by allowing the database guy to do all of his data access work.
Let's look at another scenario. Imagine your UI developer and business logic developer are hyper-productive developers and burn through their parts of the new feature in half of the two weeks that they had originally estimated. Great! Now they can move on to the next feature one week ahead of schedule, right? Well...not quite...the data access layer is taking a bit longer than your database guy originally thought. In fact, instead of the two weeks he originally estimated, it's likely going to take closer to three. OK, that's probably not his fault and we've all been in software long enough to know that it just happens. The real problem, though, is that now you have to figure out what to do with your UI developer and business logic developer for the next two weeks while your database guy wraps up. Sure, you'll keep them busy, but we all know that they'll be doing what effectively amounts to 'busy work' such as 'cleaning up the code', 'adding comments', or 'investigating technologies to be used on the next set of requirements'.
Both of these are scary thoughts, and neither is definitely the best use of your team's time, but how do you fix it? By Vertically Stratifying your team. You see, the doomed team I've been talking about so far has been Horizontally Stratified. This means that the team arrangement closely mimics the architecture of your application.
Vertically Stacking Your Team
With Vertically stratified teams, the team layout looks a little different. You see, you no longer have a dedicated 'database guy' or 'UI guy'. Your team members are assigned to specific features, not layers. In a vertical team, 'Joe' may be responsible for implementing the new Employee Editing Screen from top to bottom. This means that not only will he design and build the UI for the form, but he also implement all of the business logic and the corresponding data access layer. In parallel, 'Steve' will be implementing all three layers of the Account Details Screen.
The advantages to this are two-fold. First, Now both of your developers understand the entire structure of the application from top to bottom. They have a grasp of each layer, and more importantly they understand how each layer interacts with the others. This means that if a bug is found in the UI of the Account Details Screen while Steve is on vacation, Joe will be much better positioned to jump into it and fix it since even though he's never seen that specific code, he's written similar code in his own feature and he understands how the entire app fits together. In fact, since he's worked in all three layers, he's equally well qualified to also fix any bugs that may happen to crop up in the business logic or the data access layer of the Account Details Screen.
Furthermore, since your developers work largely independent of one another, the rest of your team is less likely to be slowed down due to a drop in velocity of one team member. What happens if the data access layer for the Account Details Screen takes a little longer than Steve thought? Well, from Joe's perspective not much at all. Since he's working on his own feature and is responsible for all layers, he's much less likely to be slowed down by the new hitch in the Account Details data access layer. Sure, there likely are some places where the two features interact that will need to be put on hold, but the entire feature doesn't have to grind to a halt for want of a data access layer.
Does This Mean Don't Hire Specialists?
Am I telling you to stop hiring specialists? Definitely not. I think teams really benefit from having a solid mix of skills at hand. Even if you don't try, you're likely to end up with that one person on the team who has a knack for laying out flashy UIs. Or one person who really likes to tune databases. Should you stifle that? Not at all. But you should make sure that each of those guys gets a lot of exposure to other parts of the application through their own features. Don't allow one person to pigeonhole himself as the 'database guy', but do allow him to be there to help the other team members with particularly thorny database problems.
The problem is that teams naturally evolve toward a layered structure. Each member finds some part of the application they're particularly good at and they naturally want to work more and more inside of that context. It's your responsibility as a leader to make sure that you challenge each team member to step out of their comfort zone and work with parts of the application they may not have otherwise. It'll make your team stronger, more responsive to change, and it'll make team members better developers at the end of the day.
First of all, thanks to everyone who came out to last night's Prism Presentation and a special thanks to PGH.NET for arranging and hosting the presentation.
Please find all of the code examples, the PowerPoint deck, and my talking points here. If you have any questions concerning any of this, please don't hesitate to contact me.