Software development in agile environment implies usage of some best practices providing high quality output in relatively short period of time. Such practices include test driven development, pair programming, code refactoring, code reviews, continuous integration, code coverage and automated tests. Agile software development assumes emergence of design from self managed teams during task implementation, in which no clear role of architects, tester or business analyst is postulated. There are team members with different background skills in real life projects, but the resulting design and coding tasks are considered team owned. Some architectural blueprints exist usually in enterprise projects. These blueprints serve as constraints, or playing ground boundary, where Scrum development team allowed to play with its use case, user stories or task oriented design and architectural implementations.
Test driven development allows creation of test cases as acceptance criteria counterparts to backlog items planned for current Sprint. This approach is called Acceptance Test Driven Development (ATDD). The initial failing tests (e.g. with JUnit) would be written first with test driven development. These tests expect some desired behaviour from the system and they should be 'green' after fine designing and implementation of the tasks. The acceptance tests belong to the 'Definition of Done' (DoD) of SCRUM teams - agreed contract upon which a software piece considered deliverable at the end of each Sprint. Acceptance tests can be written using e.g. FitNesse framework.
Pair programming, code refactoring and code reviews come from XP practice and increase knowledge exchange, code quality and decrease possible tasks misunderstandings. Team work and communication benefit from all these practice. Because agile is an iterative process and design emerges during the task realization, common approach here is the 'least necessary design' providing only needed functionality and not breaking best programming practices. Refactoring is an ongoing process in Agile and SCRUM.
Continuous integration allows smooth verification of code and build states after code check-ins in a software repository (e.g. Subversion or Git). Build tasks are defined using such project management frameworks as Maven and would be triggered by such build servers as Hudson. The Maven tasks include usually execution of functional and integration tests bundles. Integration tests are more involving and long running and their scope is more coarse grained. Functional tests can use some mock implementation for proxying of external to the system artefacts (bests praxis for this is the usage of Dependency Injection design pattern - DI).
Code coverage is another important aspect of software quality and belongs usually to teams DoD as well. The code coverage metrics can be gathered from such quality management platforms as Sonar. Non-broken builds, passed functional and integration tests, acceptable code coverage provide assurance of potentially deliverable software quality at the end of each Sprint.