One of the primary reasons that agile teams are “more productive” is that they work together closely to complete small batches of work frequently and continuously. The better the team is at working together, the better their productivity. However, teams struggle to improve their ability to work together, and so this becomes one of the most significant barriers to real agile success.
If you think about how work goes in a typical waterfall project, usually the first thing that happens is that the team decides what they are going to do and then very quickly they split into separate sub-teams to do the work. Generally the team does most of its coordinated work at the end of the project when they have to make it all work. This is the "hockey stick" effect of waterfall. From my days in waterfall I remember long hours, nights, and weekends working through problems with the rest of team. In fact I remember reconnecting with people that I had not worked closely with since the last “end of project march.”
Agile breaks this pattern by working closely together from the beginning of the project. The “end of project” style of coordinated team work in waterfall happens throughout every iteration. This is what makes agile so productive. However, “getting there” can be hard because working where your domain knowledge and skills are the strongest is where you want to work and where you know you will be the most productive.
As the software industry has progressed, software projects have become larger and more complex. With size and complexity, specialization typically follows. We have been encouraged to specialize in order to capitalize on our personal strengths and then use those strengths to produce better product capabilities. Specialized skills are critical so that we build the right solutions. However, learning new skills and increasing your technical breadth is also important. To make an agile team more productive, team members needs to be willing to broaden their skills so that they can help the rest of team get to “Done!” in addition to completing their own work.
This does not mean you have to become an expert at everything or even offer your help when it is not needed. When I was in school getting my Computer Science degree, our professors told us that “You are not a <insert favorite software language> developer, you are a software engineer.” We have to remind ourselves that, as engineers, we need to continue to expand our skills and knowledge, and be willing to try any job that needs attention. If everyone on the team assumes this attitude, the team will become more productive.
Here is the analogy that I think of when I am trying to explain this behavior. In the movie Apollo 13, after the initial oxygen explosion happens and disaster ensues, the mission commander asks that his team leaders to call in everyone on their teams to help figure out how to get the crew safely back to Earth. In the movie, teams that have not worked together are given hard problems to solve fast -- and they do solve them. This is the way very productive agile teams work together throughout the project.