List of agile best practices

Question

I am trying to define which agile practices we are going to use, and I am having difficulty defining the list of agile best practices. I would like my list to be more from a technical point of view (the engineer's angle of view), and should define how SW engineers should approach the development. The list should be related to the management as least as possible.

If it matters, we are programming in c++.

It is fairly easy finding lots of best practices, and this is the list I managed to form so far :

1. Refactoring
2. Small release cycles
3. Coding standard
4. Collective ownership
5. System metaphor
6. Planing game
7. Whole team
8. Scrum daily meetings
9. Pair programming
10. Test Driven Design
11. Behaviour driven development
12. Continuous integration
13. Code and design reviews
14. Active stakeholders
15. Document late
16. Extensive use of design patterns

We are already using some of the practices from the list. Some we are not going to use.

Are there good agile practices that I could add to the list?

PS I can add a small description of the practices, if requested.

EDIT

As I said, we are already using some agile practices (mostly the practices that proves to be the best) :

1. Continuous integration - this is very good practice. Getting the fast feedback on the latest check-ins is very useful. Having a down time because someone broke a build can be very frustrating, especially if it last longer.
2. System metaphor - it helps little, because having descriptive class and function names helps understand the code better
3. Code standard - we created the coding standard before getting into the coding. Using uniform code style is good, because anyone can take another's code and work on it like on it's own.
4. TDD - before started coding, we set up the environment to easy create unit tests, but only until recently we started adopting the TDD principles. I personally tried it several years ago, and it didn't go so well, but now I love it. Unfortunately, not all team members are doing it - only half team.
5. Scrum daily meetings - we tried daily meetings and they didn't go so well. As well as on my previous job, daily meetings usually turns into 30+ minutes discussions. I guess we missed good scrum master (or leader, how is it called?)
6. Refactoring - we did refactoring, but only if someone from the team creates a change request. We didn't do it like on purpose : "Lets sit now, and reduce our technical debt".
7. Small release cycles - right now we have huge release cycles (6 months), and for next release we are planing to break the cycle into 4-6 inner releases.
8. Code and design reviews - we did the initial design review (like 5 years ago), and few designs reviews of some minor sub-components during this period. We did code reviews of some classes
9. Document late - we did it for this release. Only required documentation means writing documentation less and more fun coding. Developers are loving it :)
10. Use of design patterns - we are already using design patterns where appropriate.

Because of the structure of our organization we can not use other practices, but as you can see the list is long, and you can not pick everything. Also, now we are only 4 SW developers, each maintaining approximately 80 kLOC and working on new stuff. Therefore we can not do for example pair programming, or collective ownership.

Answer 1

First, go read the Twelve Principles of Agile Software.

Second, figure out from what you know how to achieve the principles that are most important to you.

People constantly make the mistake of expecting Agile development to be a Silver Bullet or a rigorous set of processes that you need to adhere to that will make your software development successful.

That's not what it's meant to be. The fact that you already have a list of 15 "Best Practices" scares me a little. Don't take it too seriously and don't over-think it. If you find that you missed something...get it in the next iteration.