Generalists

This week I sat down with Davis Frank of Pivotal. He's part of a contractor shop that does projects in Ruby and Java, but it's exactly the kind of shop that you wouldn't think could exist. They help a company work on a project, but at the same time they also teach that company how to be Agile (XP specifically). When you sign up for Pivotal's services, your engineers pair up with Pivotal's engineers. When the project is over, Pivotal gives you their project management software, Pivotal Tracker, and you're on your own.

One of the things Davis said was important in an Agile shop is to hire generalists. He admitted that no one is ever even in all areas (database, class libraries, UI design, client-side scripting, etc and even other non-tech areas like, um, communication), and that by the nature of being human we all have "specialties" but that the employees that work best in Agile are the ones who can do it all - there's no barrier preventing them from working on any particular task, especially when paired with someone else.

It doesn't make sense though. If you want a killer database, you have to hire the database zealot who has never come out of his Oracle cave, right? There are some projects where that will be true, where you need the specialist. But when it comes to the web, we're not talking about single platform applications. Knowing how to design a decent table structure that'll lend itself to your business objects that get passed through web services to be displayed on desktops, mobile phones, and video game consoles is a bit more practical.

We used this at Passageways to it's full advantage. No one person was ever on "the critical path", rather, the whole team was on the path. There was a bucket of tasks, and they were assigned to the team as a whole, and an individual took them when he or she was ready to work on them. So if I finish making the schema for the new reports, and then I jump over and add some themeing to the control for the new chat feature.

Sounds great? There's a cost to being able to do this. The cost is that everyone involved in that bucket of tasks has to understand "the big picture for all of the user stories that those tasks relate to. If there are ten user stories in a sprint, then all the developers (and testers) need to be part of that design process for all ten stories. This means that the first few days of a sprint, you'll have to sit around a white board. It also means that you'll disagree, and it'll be frustrating at times. But you'll also have fun. You'll learn from each other, and you'll learn how they think, and you'll come to trust them over the long term.

In the short term you'll know exactly what your fellow teammates are expecting a feature to look like. You'll be able to grab a task off the stack and get going without too much time of "getting caught up" and having to have your fellow team members repeating themselves.

Otherwise you're a bunch of people working in the same room, but you're not a team. A team agrees on design, a team knows where a feature is going, and where it is at all times. Imagine a soccer game where, before you could pass the ball, you had to tell your team mate where the ball had come from, how he had to move the ball up the field, and what the goal was. It's a pretty dysfunctional picture, and the same applies for software. You have to be involved and agree from the start so you can easily jump in half way through.