Agile Software Development

Pair programming is one of the most known Extreme Programming practices. In essence it means creating the code in pairs trying to get multiple perspectives on the code created. One of the participants, called driver, types the code and thinks about the low level details. Another one, called navigator, thinks about what the typed code is for. The participants periodically switch roles. The definition of "low level" depends on the skills of the concrete pair and their experience in the subject area. For example, when using test-driven development the driver might be focused on the writing the production code, while the navigator could be thinking about how the next unit test should look like in order to change the system architecture in the desired direction.

In traditional software development the design phase happens in the beginning of the project, takes quite a long no-coding or little-coding time. At the end of the phase, the design is considered being more-or less frozen. It might sound logical to plan ahead in a detail, however, in the case of software only the final source code is the real design - any diagrams or descriptions can at best be the higher level design abstractions. Therefore attempts to fix the design well in advance often lead to the wrong assumption and sub-optimal solutions.

Test-First Programming (TFP) and its sometimes more known related practice Test-Driven Development(TDD)  are not very usual for the traditional software development cycle. Test-driven development simply means creating tests before writing the code they are supposed to test. A canonical test-driven cycle is as follows:

1. Write a test for the functionality you are going to implement
2. Write as little code as possible to make the test compile. Make sure that at this step the test fails
3. Write minimal or almost minimal code needed to make the test pass
4. Once the test passes, refactor the code to make it better, prettier or simpler. The test and other existing tests will guard against accidental functionality breaks during the refactoring process

Incremental Design is one of the core values of the XP. Many favor to have a "rough up-front design" rather than the "big up-front design". The days when the Design is a single long term process is gone (as in waterfall or v-model) and developers are embracing the design as an integrated daily process.

Software development has taught us to know that the "requirements change" and we need to live with it. When requirements change, the design too changes. We often hear that "the design need to be flexible enough", but not practical in all cases. The software design is often a function of the designer's technical and system/business knowledge. Its very difficult to predict and assume some of the changing requirements in advance.

Extreme programming weekly cycle is an efficient tool against over-planning that allows for focusing on implementing the top priority stories and getting the user feedback as soon as possible. While it is indeed important to deliver in small chunks of the high priority functionality, permanent work on the low level of detail can lead to the sub-optimization, when you might be polishing the already good enough product while loosing the opportunity to recognize the need for the completely new feature.

"Standup Meetings" is one of the core practices in the Agile Software Development. Instead of meeting the team once in a week in a meeting room, daily 10 minute Standup Meetings are quite popular. Few teams - which do not have a clear idea of Scrum - consider these meetings as personally intrusive and intimidating. But what one can gain via Standup meetings are many fold then conventional meetings.

"Honesty is the best policy — when there is money in it."
- Mark Twain

XP requires constant communication between team members. More specifically, XP and Agile teams depend on honest communication between stakeholders, including developers, testers, managers, and customers.

We expect manufacturers and vendors to be honest to us about the products and services they offer and market to us. Our customers expect the same. Honesty is especially crucial during iterative development where a minor course correction early in the schedule can save significant time down the road.

Weekly Cycle practice is a recommendation for reducing the short term planning period to one week. When developing software in the evolutionary way the architecture and design of the system under development are supposed to change. The high level decomposition usually stays intact for a reasonably long time, while low level details can get outdated often. The weekly cycle practice takes this fact into account and recommends for planning in detail for no longer, than a week.

For newcomers in Scrum and XP, its often difficult to appreciate a "War Room" or "Team Room" or often called as "Scrum Room". The conventional seating which depicted the hierarchies is slowly fading.

Stories or User Stories is the XP practice of thinking about software in terms of units of customer-visible functionality. A canonical form of a user story looks like "As a <user-type> I want to a <goal> so that <reason>". For example, "As a Frequent Flier, I want to rebook a trip so that I save time when booking trips I take frequently" (from Mike Cohn's User Stories applied).