Productivity is often confused with velocity. They’re related, but they’re very different things.
Velocity is the amount of work that you/your team can do in an iteration. In economics terms, productivity is defined as “the ratio of what is produced to what is required to produce” (source: Wikipedia). So, a person who can carve ten statues out of a lump of granite is more productive than a person who can only carve eight statues out of an equal size lump of granite.
At this point it’s understood that we can’t measure productivity when it comes to building software because there’s no good, consistent, accurate way to measure output.
However, while we can’t measure our productivity, we can often improve it. Without measurement we won’t know how much of an improvement we’ve gained (or how much we’ve regressed), but we can measure improvements in velocity, which can indicate corresponding productivity improvements.
Productivity is not improved by adding people. You might increase your velocity by adding people, but productivity often suffers when a person is added to a team (at least until the team adjusts and the new member is running at full speed). At best, productivity will remain the same when people are added.
Productivity is improved by simply being more efficient. Automate tasks that are repeated often. Know your tools and the shortcuts (small automations) that they provide. Reduce waste — don’t solve a problem unless it needs to be solved. Identify blocks and remove them as soon as possible.
Agile and XP practices are, for the most part, about increasing efficiency, focus, and productivity. Automation, including continuous integration and automated unit testing, is important. Pair programming is a good way to learn about the tools your team uses. Test-driven development and pair programming help keep the focus on adding business value. Scrum-style stand-up meetings are a good place to bring up blocking issues and identify the best person to help remove blocks.