I had a moment of clarity last night and came up with a software development analogy that really rung true for me. Maybe it's because we're 5 weeks into football season. More than likely it's because my group has gone through another re-org recently and we had our first all-hands meeting yesterday. [Quick aside: it's a joke around here that if you keep track of your managers and offices over your MSFT career you'll end up with a pretty long list ] In the all-hands meeting, our new director discussed wanting to unify the processes being used by the many development teams now in his group. More detail isn't really necessary, just suffice it to say that it started some conversations and got me thinking about development practices.

That's where football came in. I started thinking how the positions on and off the field correlate to the different roles in software development. Here's my take on it...

Assumptions. Every project or business plan should start with some explicitly stated assumptions/assertions so I'm going to do the same thing here. I am making the assertion that a single football game is equivalent to a single development project.

And the positions...

• Offense. This is the group that scores the points, or in the case of software gets the stuff produced and ready for consumption. In software development, making progress (milestones) on a project feels like scoring points and is what defines whether you've won the game or not. Collectively, a software development team's offense consists of the developers and PMs.
• Quarterback == Lead Developer
  • I'm going to start with the most coveted, popular, visible position on the field, the quarterback. The lead developer might not write a lot of code [score points], but they're constantly meeting with the various groups [huddles] to help guide the project.  They direct the developers' priorities and areas of focus within the project [calling plays], constantly re-evaluating the team's progress. Sometimes the lead dev will jump in and write some code like a quarterback that can't find an opening and runs the ball himself, but most of the time they pass or hand the ball off.
• Wide Receivers, Running/Full Backs & Tight Ends == Developers
  • These are the guys on the field that score the points. The developers write the code to get the project done [win the game]. Sure, the lead developer guides them [calling plays], but these guys have to write the code [move the ball] that results in a class, method, object or entity [score points].
• Offensive Line == Project Managers (PM)
  • Without an offensive line the quarterback, wide receivers and running backs aren't going to get anywhere as the defense will quickly run them over. The PMs are an essential filter [blocking] between the developers and everyone outside of the development group such as requestors, virtual teams, operations groups, etc. The PMs should be face-to-face [line of scrimmage] with all of these other groups making sure that the development team doesn't get randomized or thrown off track [tackled], but can focus on getting the software written [scoring].
• Defense == Testers
  • Just as I said in "the best offense is a good defense" a game can be decided by the defense instead of the offense. Your quality assurance (QA) team should be validating the developers' code throughout the project. This would be like how a football team practices against itself day-in and day-out, pitting their offense against their own defensive line. This is invaluable for the developers [behind the offensive line] as the testers [defense] are able to find bugs [tackles]. This allows the developers time to fix the bugs before delivering a product [game time].
• Coach == Architect
  • In The Mythical Man-Month, Frederick Brooks talks about how one person should own the vision of the project so that it has cohesion and unity throughout the complete development process. I see the architect filling this role since they are often involved with projects long before the developers. Think of off or pre-season while the players are doing their own thing the coaches are consumed by planning for the next season and the myriad of teams they will face. In software development, when the developers, testers and PMs have just finished a project and are going to training or getting miscellaneous stuff done they are not necessarily focused on the next project. Meanwhile the architects are involved in high-level discussions around infant projects [games next season] and how to approach them.
• Owners == Management
  • NFL team owners make the money decisions which involve business planning and hiring, but are pretty hands off in the day-to-day processes of running a football team. That's the role I see management filling. Management makes high level business decisions like staffing [player recruiting and trades], other resources and overall group direction. Management rarely gets involved in the low-level details of individual projects because they are focused on all of the projects as a collection [game records over multiple seasons].

Putting software development in this analogy helped me set some expectations of the people in my group. It seemed to simplify the equation for me. Instead of trying to figure out every little thing each person should be responsible for I was able to create a visual picture in my mind. It really clicked for me. What do I expect my PM to do? Well, they should be running interference for me [O-line] so I can get my job done [run the ball] and deliver the parts of the code I'm responsible for [score]. My lead? Should be guiding my priorities [calling plays & getting me the ball]. Our tester (SDET in MS lingo) should be poking all the holes [tackles] he/she can in the code I deliver [carrying the ball]. Our architect isn't actually writing code, testing or such [on the sideline], but they are extremely important in guiding the overall efforts of the project [coaching the game]. And management is not too involved in my day-to-day work, but they are looking at the high level stuff that's out of my scope.

I'm a simple man because, honestly, I felt a little better after thinking this through last night.

~tod

tags: software+development