How Agile Methodology Pulled Us Out of the Weeds

Some ten years ago, I worked with a developer who I will refer to as “Ivan.” Ivan was a software developer from Russia who, aside from regular outbursts of sarcasm, rarely communicated with anyone. He worked largely by himself and he liked it that way. He was famous for holding up completion dates on key assignments, which resulted in stopping progress on the entire project. Ivan was just a part of the problem, but It was clear our process was flawed in two fundamental ways:

Programmers responsible for different phases of a project were not required to communicate with one another.
The waterfall software development methodology, in use at the time, was rigid and unresponsive to new developments. We often were not aware of a problem in project design, architecture or code until the project was nearing completion.

Some History

An alternative to the waterfall development process was first presented by Dr. Wayne Royce in 1970. Critical of the way the waterfall style presumed to be able to identify all essential elements of a project at the outset before coding even began, Dr. Royce proposed a methodology that was more “intelligent” and adaptive. He proposed a methodology that would be much more responsive to market needs and to design issues discovered during the course of code development. The basic attributes of Agile can be summarized as follows:

Agile is highly responsive to customer needs and to standards of performance that can change daily.
The delivery of a workable product every day is feasible. Some have called this “continuous development and delivery.”
Agile development is grounded in frequent communication between stakeholders and developers.
Agile managers strive to encourage self-organizing teams. These teams communicate frequently in their efforts to become more efficient and responsive to project requirements.
Development focus is targeted and centered on the essential. Unnecessary steps are eliminated in the interests of stream-lined design principles.

How Agile Works in Practice

In my opinion, Agile methodology gets its strength from communication. Not only do developers meet monthly at the “sprint,” where all goals are set for the months ahead, but in the daily “scrum” meetings as well. At the scrum, each developer reports on progress made and/or problems encountered. Goals first identified at the sprint can be determined unworkable or adjusted at the daily “scrum.” No one is allowed to sit down; this is a stand-up meeting so no one can get too comfortable. There are undoubtedly variations to this process, but I like to call randomly on developers. As a result, everyone needs to be prepared at all times. Each developer is accountable for his or her particular assignment and if a developer encounters a problem, the issue is “parked” (i.e., tabled) for a separate discussion.

Developers are not “Islands”

In Agile software development, programmers don’t work in isolation, but in teams. Not only do less experienced developers shadow more seasoned programmers, but for complex development issues we use paired programming, where two developers work together on the code. This process allows errors to be caught early by team mates and complements regular code reviews. Informing the discussion at scrum meetings is feedback from on-going software testing that stress-tests software with over 500 data sets. If an application consistently fails, it is discussed at the next scrum meeting. A hallmark of the Agile methodology is that code is never left alone, but is subjected to several levels of review by developers and engineers through automated and manual testing processes.

Agile is a No-Brainer

CivilGEO’s software development thrives on Agile methodology. Software products can stagnate if, once conceived, the purpose, design and features are never revisited until the finished software “rolls off the assembly line.” This is how Agile differs from old-school methodology. Agile treats each product like a “living organism” that grows and changes with its environment. The final software product is an accurate reflection of current customer preferences and front-line design capabilities. Ivan would not have survived in this new age of truly “intelligent” programming methodology. Developers are not islands and the programming world is better off because of it.