I was having a conversation with a developer the other day about working on different areas of a project. The subject came up after I made a comment about how the person that breaks a build should be the one to fix it. His immediate reaction was that he shouldn't be responsible for fixing something that wasn't his "area". And that it would be much more productive if the developer working on that specific area were to fix the problems. This isn't the first time I've had this conversation. In fact I've had it many times with many developers.
There is a general tendency in believing that distributing up a team of developers and have each one focus on one area and only one area during the lifetime of the project is a good thing, that it is more productive. If Jack learns everything there is to know about WPF and handles all the user interface during the whole project, whereas Joe works on all the back-end, that is good. Each know their part inside out and can fix a bug before someone else from a different area can even reproduce it.
I mean it makes sense right? It's pretty reasonable thinking right? Well not everything is black and white.
Productivity can vary based on surrounding circumstances. Let's say a project is delivered to a customer and after three months, a bug is reported. Jack can fix it fast. Productivity is high since Jack works fast. However, Jack is on holiday. Customer is waiting for a fix. It's hurting his business. Jack will be away for another two weeks. There is only Joe left, and now needs to get up to speed on what Jack's been working on and try and fix a bug. Productivity has dropped to an all-time low.
In principle, that doesn't seem that bad. The productivity ratio can still be better than having everyone know all the system from day one. If a bug comes in and Jack is away, Joe will learn. And once he's learnt, he'll know it. If it ever happens again, he's already learnt it. Sure, it takes maybe 2 weeks instead of 2 hours to deliver a fix to the customer, but it's still ok. Problem is that it's not that simple. We're looking at a two-man product with two areas. As the system grows, the numbers grow.
The problem gets worse when we're not talking about a bug fix, but delivering a project. That's where the bus number commonly comes in: how many members of your team would have to be run over by a bus, for your project to fail? The higher the number, the safer your project is [This is a metaphor, not some cynical sick project manager that cares more about the project than his team members being run over].
I've been on both sides of the fence. I've been the stakeholder behind a project that has a very low bus number, and I've been a developer on a project with a low bus number. And I can tell you, neither of them is a good thing.
From a stakeholder's perspective, it's risky. If you have a project with three guys, and each has his/her area of speciality, you can suffer and your business can suffer if one of those guys decides to leave.
From a developer's perspective, it's bad also, and the longer the project, the worse it is. Working on one area and/or with one technology can cause stagnation, which in turn can lead to lack of motivation.
Coming back to the initial paragraph, as developers we should not be afraid to work on any part of a project. If you are working on a user interface screen and you need a certain piece of functionality that does not work or is not implemented yet, you should be able to work in it. If you don't have enough knowledge of the project/l.o.b. to be able to work on it, that is another problem waiting to surface. Solve it. The later you leave things, the worse it will be, both for you, the team and the project.
I can understand that people that are not "software orientated" find it hard to understand. They assume it's like anything else. In most industries, if one of the members of the team leave, and they are specialized in a certain area, it's not hard to find someone else to replace them. Soldering steel, fitting steering wheels, etc. have pretty much non-existent or very low new learning curves (you can pick up how to fit a steering wheel in a Ford in a very short time if you've done it for a VW or a Toyota). With software it's different. You not only need to know the technology, you need to get learn the domain of the project and get up to speed with the architecture. It's not as simple as pulling one guy out and putting another one in his/her place.
Knowing this, the best thing we can do on a project is have the ability to temporarily replace one person with another. It isn't so much about being agile, but about having common sense.