Agile Development
Designing an information system is more of an art than a science. Because there is no perfect formula for success many projects fail, costing firms time and money.
Imagine constructing a bridge which will span a bay. All of the people involved meet to design the new crossing. Blue prints are created and the work is split between two groups of workers. One team begins construction on the east shore, the other team begins on the west. Each team is responsible for building half of the bridge, but they don’t know what the team across the bay is doing. How likely is it that the bridge segments will align when both teams reach the middle of the waterway?
In reality bridges are not built in the above described manner, so why do some developers use the same doomed methodology when creating information systems? The analysts and users meet initially to discuss the requirements for the new system. A plan is drafted to meet the needs of the users. The plan is reviewed and revised, then work begins. A traditional project begins life with a strong tendency towards failure. The users build a bridge of expectations and the developers build a bridge of systems, but the two rarely meet. The solution to information system discontinuities is very simple, communicate. The traditional waterfall approach does not compel parties to communicate throughout the entire development process. Communication occurs in the beginning, but once development begins the user is not involved until they access the completed system.
In recent years a concept known as “Agile Development” has been used to get everyone involved in the creation of a new system. One of the best known Agile Development methodologies is called extreme programming (XP). A correctly implemented XP methodology forces developers and users to constantly exchange ideas throughout the project’s entire life cycle. In XP all of the tasks are broken down into pieces, called stories. Stories are generated and given a priority by the user. Each story is simple enough that a pair of programmers can write the code. The user in XP is not only encouraged to participate, they are required to be on premises at all times. This is important because the developers can ask the user questions rather than make assumptions which may be incorrect. Other tenants of XP philosophy include incremental changes and frequent releases. This release early, release often approach allows the user to inspect the product and request changes while the product is still being developed rather than after the system is installed. If an XP project is not going the direction the user intended, the problem is spotted early and the user can redirect the developers before much time or expense is wasted.
Information systems only grow in complexity as we continuously invent new technologies. Our information systems development techniques must also evolve to meet these new challenges.