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

This text summarizes all agile best practices (with links) :
Requirements
– Product Vision / Vision Statement
– Product Backlog
– User Stories
– Use Cases
– Usage Scenarios
– Personas
– Planning Poker
Requirement Prioritization
Design
– Architectural Spikes / Spike Solutions
– Domain Driven Design
– Emergent Design / Evolutionary Design
– CRC Cards
– Design by Contract
– System Metaphor
Construction
– Coding Style / Coding Guidelines / Coding Standard
– Test Driven Development
– Behavior Driven Development
– Pair-Programming / Pairing
– Refactoring
– Collective Code Ownership
– Daily Builds / Automated Builds / Ten-Minute Builds
– Continuous Integration
– Code Reviews / Peer Reviews
– Software Metrics / Code Metrics & Analysis
– Source Control / Version Control
– Issue Tracking / Bug Tracking
– Configuration Management
– Frequent Delivery / Frequent Releases
Testing
– Unit Testing
– Smoke Testing / Build Verification Test
– Integration Testing
– System Testing
– Exploratory Testing
– Test Automation
– Storytesting / Acceptance Criteria / Acceptance Testing
Process
– Timeboxing / Fixed Sprints / Fixed Iteration Length
– Release Planning
– Iteration Planning / Planning Game / Sprint Planning
– Sprint Backlog
– Task Board
– Definition of Done / Done Done
– Daily Stand-up Meeting / Daily Scrum
– Velocity
– Sprint Review / Iteration Demo
– Value Stream Mapping
– Root Cause Analysis / 5 Whys
– Burn Down Charts / Burn Up Charts
– Big Visible Charts / Information Radiators
– Retrospective / Reflection Workshop
Organization
– Small Team
– Cross-Functional Team
– Self-Organizing Team / Scrum Team
– Colocated Team / Sitting Together / Common Workspace
– On-Site Customer / Product Owner
– Scrum Master
– Sustainable Pace
– Move People Around
– Scrum of Scrums