Agile has taken these best practices and added a few new concepts of its own that dramatically change the perspective of software development from a technical and business sense.

• Short Time Boxed Iterations

  Phases of development, even iterative development, are typically based on a set of features being implemented. This can cause radical variability in delivery schedules and meaningful progress updates. Agile tells us to prioritize subsets of features to ensure the important stuff gets done first but fixes the iteration length so that at the end of each iteration, whatever has passed acceptance testing is demonstrated (and possibly delivered) so that progress updates and opportunities to redirect development based on new knowledge, opportunities, or changing business climate can be reflected in the acting plan.

  We commonly work in two-week long iterations which means you'll get tangible results from your development effort on a frequent basis rather than wait months before you discover whether or not those promised deliverables are going to be useful or wasted.

• Fixed Costs & Schedule

  There are three variables in Software Development - Features, Costs, and Schedule. Classic development methodologies have always tried to fix the features up front then determine the cost and schedule estimates. This ultimately results in costs & schedule being variable (invariably higher!) as it is impossible to know up front all the issues with developing said features. Agile takes a counter approach. Realizing that there is much unknown about what developing these complex features will entail, we set upon a course of fixed length iterations of fixed costs to implement a prioritized but variable set of features. This significantly reduces our exposure to risk while ensuring that the most important and useful features do get delivered at some level.

• Test Driven Development

  Experienced managers not familiar with Agile will quickly react to the above concepts with alarm as they rightly point out that one of the hardest parts of complex multi-team, multi-component development is integration which is why they put it off til late in the process. Agile's short iterations and frequent releases requires an integration effort that many more times. This is true and that is why Agile practitioners have developed highly automated tools and processes to continually integrate their entire system on an ongoing basis.

  Developers must follow a process whereby they define "unit tests" which are fine grained stand alone test cases that confirm their code is delivering the required functionality. Then they only focus on writing enough code to pass these unit tests which get automatically executed by their build environment. Once unit testing is passed their new source code is checked into the source code control system which brings it into an automated Continuous Integration (CI) environment.

  The CI system brings together all the dependent components and runs a suite of functional and integration acceptance tests immediately notifying the team if something has been broken so that it can be fixed right away. The net result is that integration is an ongoing constant effort but highly automated so the last operationally tested setup can be deployed at any time and new features get into production sooner and more frequently. That is how we ship working software fast!

• Estimating Relative Complexity with Story Points

  Another demonstration on how Agile recognizes the strengths and weaknesses of human nature is the concept of the Story Point. Humans are notoriously bad at estimating absolute values, especially in terms of time. Getting good time estimates through absolute numbers is simply not practical. However, humans are quite good at estimating the relative measure of something. Story Points take advantage of this fact by creating a value with no tangible unit of measure which can be manipulated later. The entire team sits together and discusses each User Story and then attempts to compare the story to stories completed in earlier iterations. It is generally much easier to reach a concensus that one story is twice as complex or equally complex as another one which then determines the number of Story Points it will receive.

  As a measure of productivity for planning purposes, Agile further leverages the fact that iterations have a fixed time length. At the end of each iteration the total Story Points for all user stories that have completed their acceptance testing are totalled giving the Velocity of development for that iteration. By taking a rolling average of the velocity of several iterations a practical metric for planning purposes becomes available which gives a realistic indication of how many further iterations will be required to complete the project. Since User Stories are estimated each iteration, this metric becomes more and more accurate over time.