The ‘Agile Technical Practices’ or ‘Agile Programming Practices’ all come from work carried out or developed from other ideas by eXtreme Programming practitioners;  They are not part of Scrum or any other Agile framework but have been adopted by many, if not most, Agile programmers as a ‘toolkit’ of ‘BEST practice’ for producing minimal, ‘clean’ and maintainable code.  The list of practices, with explanations, is as follows:

• A common "war-room" style work area – Where Team members are co-located, they should occupy an area that they can call their own.  

There will be many artefacts that are best displayed on a wall and it is best to keep them in one place.Also, the Team members can obtain ‘osmotic communication’ just by being in the same area as OTHERS having conversations.

• Sharing the codebase between all or most programmers – Individual programmers do not ‘own’ their own code; it is a shared resource between all programmers.  

Because nothing is considered ‘finished’ the first time through (it may meet the Definition of Done for the current SPRINT but may have to be modified for other functionality in a later Sprint), other programmers need access to all the code in order to update it when necessary; if they do not have access, they may write redundant code. 

• A single coding standard to which all programmers ADHERE – Just as sharing the codebase is an important practice, having a common coding standard reduces the time that a programmer needs to understand code that another has originally written.
• Pair-programming – The simplest practice to implement, it requires that no line of code, production or test, is written without 2 people being involved; one typing at the keyboard, the other reviewing what is being done and suggesting alternatives.  

Contrary to some beliefs, this practice does not double the cost of development because the resulting code will be virtually bug-free thus reducing rework time considerably

• Simple Design – most things are simple when they start out but become more complex as time goes on.  The codebase must be inspected regularly for signs of complexity and the code refactored to produce small, simple functions and methods.  
• Test-Driven Development (TDD) – This practice requires that no line of production code is written unless an ‘automated’ test has been written for the functionality, the test has been run and fails and only enough production code is written so that the test passes.

The practice does require the use of an Integrated Development Environment (IDE) that supports TDD or access to a TDD framework that supports the programming language being used.

• Rigorous, regular refactoring – As stated in most of the practices above no line of code can be considered ‘finished’ until the end of the Product Development.  Even during a Product maintenance phase, the code may need to be modified. If ‘patches’ are added just to make the code work, the codebase will become complex and difficult to modify and maintain.
• Continuous integration – Even code that works in the IDE and passes all tests, it may fail in the system build; the longer you leave it between system builds (integration), the harder it is to track down what caused the build to fail.

Integration system builds should be done as often as PRACTICABLE to catch errors early and make them easier to find and fix.

Some organisations do a full build of source code that has been checked-in to the source code repository every 2 hours; some organisations do a full build each time code is checked-in to the source code repository.

This practice does require the use of automated system build systems.