Agile Glossary

Below are some terms that are frequently used within the Agile community…

Acceptance Tests :: are written to specify the criteria that must be achieved for the requirement to be viewed as complete. Of course the final voice on the completeness of a requirement is that of the customer.

Agile Manifesto :: a set of principles and beliefs signed by a number of key thinkers originating the Agile software development movement. The Agile Manifesto can be found at www.agilemanifesto.org.

Agile XP :: Agile eXtreme Programming was developed by Kent Beck and his co-conspirators working in the C3 project at Daimler Chrysler AG in the late nineties. For an introduction to Agile XP check out www.extremeprogramming.org.

Automated Tests :: are exactly what they sound like: tests, that we’ve automated. A number of tools can be used for automating tests at both at a unit and functional level. Check out Selenium, an open source functional testing tool.

Build Light :: these can be used to visually present the status of the build to the team. Red, amber, green. Just like traffic lights.

Coding Standards :: the development team agree coding standards that allow them to communicate through the code. This will assist with developing the application and ongoing maintenance. The intent is that the application should appear to have been written by a single, highly skilled developer.

Collective Code Ownership :: the responsibility for the code should be spread across the entire team and silos of ownership should be prevented. Any developer should be able to work on any area of the code and should be encouraged to do so to remove people dependencies.

Common Vocabulary :: Agile teams develop a common vocabulary that is aligned to that of the business, encouraging business stakeholders to consolidate and agree terminology where appropriate.

Continuous Integration :: the application is built on a regular basis when developers check-in their code. Traditionally this build activity is performed infrequently, or worse, right at the end of the project leading to significant effort in making the code work as an application.

Crystal :: a family of software development methods designed by Alistair Cockburn. Crystal Clear seems to be the most well described methodology in the family.

DSDM :: stands for Dynamic Systems Development Method and is another methodology often referred to under the Agile umbrella. DSDM seems to have fallen behind other Agile methods (such as XP and Scrum) in popularity at present.

Iteration :: is a period of work for an Agile team, often one, two or four weeks. The intent is that at the end of this period some working software is completed and could be released to production if required.

Metaphor :: confused the hell out of me for a long time!… but can be very powerful. Developing a metaphor for an application helps the team build a conceptual framework and keeps the team on track to a solid solution. For example, “This application will be like performing your shopping in a small supermarket but for jobs and online”.

Pair Programming :: a practice that management types often find controversial. Two developers work at a single console on the same problem. The best metaphor that I have heard for pair programming is of rally drivers and co-pilots; the driver is focussed on the immediate part of road they are driving and the co-pilot is thinking about what is coming up. If pair programming is in place then code reviews are not performed. I have seen figures that suggest productivity drops slightly (~5%) with the introduction of pair programming, however quality significantly increases (~100%).

(The) Planning Game :: is a model and environment for negotiating the content of releases and iterations. Agile teams make all information available to stakeholders who make decisions through the planning game.

Refactoring :: is the process of improving a piece of codes inward structure without affecting its outward behaviour.

Regular Releases :: is an Agile principle intended to both improve the efficiency of the delivery process and allow for early and regular feedback from real world users.

Retrospective :: an activity performed at frequent intervals to reflect (Hansei) and introduce improvements (Kaizen).

Scrum :: another member of the Agile family of methodologies. Slightly stronger on the documentation scale than XP and less prescriptive in technical practices.

Showcase :: an activity performed on an iteration basis to present the working software developed within the last iteration to key stakeholders. Is often also used to discuss progress and status.

Sustainable Pace :: a principle of Agile teams to work at a pace that can be sustained iteration after iteration, release after release, project after project. Extra time may be required around key milestones but Agile teams are in it for the long-haul.

Technical Debt :: occurs when the technical purity of a solution is compromised to deliver short-term business value. If the technical debt within a system is not managed it will become increasing complex and difficult to modify over time.

Ten-Minute Build :: is a principle tied to continuous integration that says within 10 minutes of a developer checking in the code the application should be built and all tests run.

Test-Driven Development :: a process for writing code that involves writing tests prior to writing the solution code. The code is then written with the intent of making the tests pass. These automated tests can than be integrated with the build and used as a safety net to test integration issues when other areas of the code base are changed.

User Stories :: are a simple way of writing requirements favoured by Agile teams due to their simplicity and their ability to support the planning game and deferred decision making. User stories are a single sentence that can be written on one side of an index card, acting as a placeholder for a conversation about the detailed requirement at an appropriate point in the future.