Since most readers of this blog are likely to be practicing or budding Agilists, replace "you" with "your coworkers" or "your manager" as appropriate.
Even remote team members should be in contact on a daily basis for Scrum/stand-up meetings and throughout the day over the phone/Skype/IM/email. On-site, co-located teams really have no excuse to work in isolation.
Often a consequence of #1. Scrum is a good way to report status efficiently, facilitate face-to-face communication, and make commitments to each other rather than management.
This happens if you're not doing continuous integration on a clean (not a developer's) machine at a minimum of once a day, but preferably whenever someone checks code in to source control. You are using source control, right?
Good old Waterfall, Big Design Up Front, and Cover Your A**. Instead, favor open, continuous communication with the customer or her representative, including continuous release/demonstration and feedback. This allows you to adapt to changing, or simply miscommunicated, requirements.
It's really amazing how many developers, including (especially?) senior-level developers, haven't grokked the benefits of unit testing. Somehow any practice with the word "testing" in its name is up to QA to figure out, if you're lucky enough to have a good QA department and process. Unit testing is a "white-box" (or glass-box if you prefer) test — leverage your knowledge of the implementation to fully exercise the code under test. QA typically operates at the black-box level, without understanding the fine-grained implementation details, like a user.
Sounds like #5, but a bit different. Everyone is responsible for quality, especially developers. The sooner a bug is found, the cheaper it is to fix.
No one knows for sure how long it will take to design, implement, and integrate a software component. But the person who is designing, implementing, and integrating it should be able to make the best guess and will have more incentive to produce accurate estimates.
A lot of architects are great. I've worked with a few that were hands-on and knew their stuff. They knew the environment, languages, libraries, and legacy code as well or better than most of the developers. But architects who don't get their hands dirty can be dangerous, especially if they opt not to consult with their lead developers on important design considerations.
Without continuous integration, a good test suite, and solid design, touching even the seemingly most innocuous line of code is a risk to distant, often unknown, relatives than depend on the behavior of that code.
Definitely related to #9, but that word "refactor" is especially scary to some, especially if you don't have a good test suite for a safety net. It's also scary if your team doesn't understand what refactoring is, and uses it to describe massive redesign — management is once-bitten-twice-shy when it comes to that sort of thing.