Tutorial

ABC: An Introduction to Agile Programming

Agile programming strategy can help reduce application costs, improve application quality and ensure everyone is involved in the creation process. We explain the basics to help you get started with iterations, extreme programming, Scrum and other related programming methodologies.

What's Different, Besides Working in Iterations?

The keystone of the Agile programming methodology is communication. The method emphasizes face-to-face communication, with written documents as the discussion points. In other words, rather than have a lot of people working on their own on various project pieces, everyone gets together and works on the pieces as a cohesive unit.

Unlike other programming methods, Agile programming relies on teams of highly differentiated members who work in a group called a bullpen. A team includes project managers, designers, developers, testers, customers, writers and anyone else who needs to work with the iteration. Because the project piece is small enough for everyone to understand and for all of the stakeholders of the piece to work together, it's usually possible to get it out the door in a minimal amount of time, with little or no rework.

However, the most important consideration about Agile development is that the development process involves everyone. The customer (user) is involved with the project at the outset, which means that the development team makes fewer wrong assumptions about how the user will interact with the application and the steps required to perform a particular task. This process is very different from the "write a spec, throw it over the wall, and then ignore it until you sneer during the application demonstration" approach that's common in many shops.

Won't Working Like this Change Our Corporate Culture?

Agile programming does require a different environment from what you typically find in a corporate setting. For example, all team members have to embrace some level of trust in the other members. No one person can hold out information, resources or data from the other team members. To ensure a good result, the team must work as a unit and avoid the usual political entanglements. In some cases, this may mean replacing one team member with another member who's willing to trust the team.

In addition to trust, the team members must be willing to compromise. A piece of the application may require certain features and have other features that are nice, but not required. Sometimes, to get the piece finished in a reasonable time frame, a team must decide to remove unnecessary features and save them for a future iteration. The point is that the team must be willing to work together to create the application piece within the given time frame.

Some organizations are used to throwing a lot of people at a particular problem in hopes of getting the job done faster. When working with Agile programming techniques, you use a few highly skilled people. Fewer lines of communication mean that the team members can accomplish tasks faster because there are fewer people who must agree to a particular course of action.

The team will make some decisions that might not prove popular with the organization as a whole. The old saying, "You can't please everyone" comes into play here. Because the team includes a representative from every part of the organization, the organization must trust the team to act in good faith. The goal is to live with that application piece that the development team delivers. Otherwise, the project can quickly spiral into chaos. Of course, this doesn't mean that the organization has to accept a buggy application or one that doesn't work as needed to accomplish the task. The reason to deploy the application in small pieces is to find and fix bugs and usage problems sooner, rather than later, to reduce the cost of repair.

A final piece of the picture is providing an environment that encourages communication among team members. Achieving this goal may require that you set aside a specific place for team members to work. The members should maintain the same working hours and be available to other members as needed. You may have to temporarily assign customers (defined here as someone, such as company users, who will interact with the application) to the team and not ask them to perform their regular jobs during this period.