Agile: Don’t Worry, It’s Natural

In February 2001, seventeen individuals met in northern Utah and drafted the twelve principles of agile in a manifesto, which has had a profound impact on the software development industry. The purpose of the manifesto is to move software development from taking on all the requirements and completing each phase prior to starting the next, to exercising all the development phases on a smaller chunk of requirements that developers (and customers) can collectively get their heads around.

Looping through the development phases several times during a project affords sensible adjustments that avoid catastrophic results and the need for blame. It also gives the entire development team greater project wisdom that can only come from several passes through all the development phases.

Although the idea of repeatedly exercising the full development lifecycle on smaller chunks of the requirements is newer to the software industry, it isn’t at all new to many other aspects of life and nature. In other words, we have been agile practitioners for quite some time, and the software development industry is just now catching up. Let’s discuss a few examples.

Agile Applied to the Musical Arts

When world-class musicians practice, do they only practice the pieces they perform from beginning to end? World-class musicians practice their scales. Through repetitive practice of core elements, musicians gain a mastery of technique necessary to perform various pieces of music. Musicians have been practicing this way for hundreds of years.

Agile Applied to Conceptual Understanding

Instantaneous understanding of a new concept is rare for us. Remember going through your algebra or geometry book for the first time? You weren’t able to go to the back of the book and comprehend the last chapter without first understanding the earlier ones. We needed the lifecycle of concept introduction, example, simple practice, advanced practice, and a quiz. After this, we moved on to the next concept, completed the chapter, and eventually finished the book and the final test.

Agile Applied to Painting a House

What process do you go through when you are planning on painting your entire house? Before you commit to a color, you want to be sure it will work. The smart thing to do is buy a small sample of each of the colors you’re considering and paint small swaths next to each other on the house. Repeat the color samples for all the different places the paint will be seen—direct sunlight, in the shade, on the first story, and on the second story. Once the paint has dried, you check the color up close and from the street, during the day and at night with the porch light on. After considering all the influences and shades, you should be able to make a decision about what color combination is best, and you are ready to paint the house.

Agile Applied to Software

Most software customers are confronted with choices about how the resulting product will look, function, and interact with itself and the user community. Similar to the situation when selecting a color to paint your house, the customer can be confronted with more choices than he or she could have imagined. Trying to work through all the combinations for these choices is even more daunting.

Getting the customer a glimpse of what the product can look and behave like is similar to the swaths of paint on the house. What was a daunting selection of choices and combinations suddenly becomes an easier decision when faced with a model of what the finished product can be. A little bit of the product in its intended environment speaks volumes compared to analysis and what-ifs. The customer at this early stage has the opportunity to realize an entirely different path without devastation to the project or the relationship. This is a standard expectation in an agile environment.

My web designer was elated when I sent him the mock-up of what I wanted in PowerPoint: photos here, text here, lists of papers there. He was done in four hours, making both of us happy campers. Imagine the number of possibilities if my request had been only “a webpage that piques the interest of male thirty-somethings in Spanish-speaking nations.” We could have gone through many iterations of how the webpage would look, feel, and behave, with lots of testing and analysis.

A while ago I did real-time programming for aircraft radar and was part of a very large upgrade of both hardware and software. The project housed about fifty programmers and lasted four years.

The front end of the lifecycle, system requirements, detailed requirements, preliminary design, and detailed design were all performed for the entire project as a whole. These were big events that required hundreds of slides on vellum and was very much a waterfall event.

However, the coding, integration, and flight test were carefully prioritized or layered. The core radar modes were completed first, which gave the customer a chance to see the basic system in operation prior to all the more sophisticated modes being completed. The motivation for this integration approach was limited integration and flight test resources—certainly not agile principles. But it did result in an opportunity for the customer to see a fully operational partial system long before the project was completed.

We could argue about the appropriateness of agile in such a large environment, the difficulties of running the full lifecycle several times prior to project completion, and whether the integration portion of the project actually qualifies as agile. But one thing holds true. The first principle of the Agile Manifesto was met about halfway through the project. We did deliver working software to the customer, and the customer was able to begin comprehending their actual product right away instead of in the future.

In today’s software development environments, we strive to adhere to the principles of agile, looping through all the development phases on small chunks of requirements in an effort to reveal the working system to the customer as early as possible. Don’t worry—this is not only natural, but also makes both software producers and customers happier.