Part 1. Agile fundamentals and a supporting case study
The following two chapters will provide a foundation for understanding what agile is and introduce a case study that we will
use throughout the book. Chapter one will discuss the origins of agile and contrast agile to traditional software development
practices. Chapter one also focuses on correlating agile to the two most important goals for many companies: making money
and holding down costs.
Chapter two will introduce you to our case study, Acme Media. Acme Media has business needs that are driving it to become more agile.
They have not delivered software very well in the past, and there has not been urgency surrounding their projects. This has
all changed with the rise of online advertising. The team needs to learn how to deliver valuable software quickly, else their
customers will shift to their competitors.
Chapter 1. Moving to agile
The tragedy started when the crew accidentally bored into an adjacent, abandoned mine that was flooded with water. The miners’ map told them, incorrectly, that the abandoned mine was hundreds of yards away. The men scrambled to reach the exit, but the rising water blocked the way out. Their only option was to seek out the highest point in the mine.
Word of the accident spread above ground and a rescue team was formed. The rescue team estimated where the crew was located in the mine and picked a spot to drill. Maps revealed a gas line that ran close to the target drilling point; and if their coordinates were incorrect, they might rupture the line and create an explosion. Being careful to avoid the gas line, the team began drilling a small, exploratory hole. After 90 minutes the drill broke through the wall of the tunnel, and the rescuers listened anxiously for any sounds from the miners. After minutes of sobering silence, the rescuers could hear the trapped men pounding on the drill bit with their hammers. The miners had been located. Now the challenge was to get them out of the mine before hypothermia set in.
The rescue team outlined a two-part plan. First, they would drill additional holes to help pump water from the mine. Second, they would use a “super drill” to create a 2-foot-wide escape tunnel for the miners. The drilling work began without a hitch, but then the super drill bit broke 105 feet below the surface. A special “fishing” tool was needed to extract the bit. In the past it had taken 3 days to build such a tool. The rescuers knew they did not have 3 days to get to the miners out.
Rescue workers contacted Frank Stockdale, the plant manager at Star Iron Works, and asked him to build the tool they needed. They faxed engineering prints to Stockdale and explained the dire situation to him. Using his 95-member machine shop, Stockdale was able to reduce a 3-day job to 3 hours. The rescue team then removed the broken bit and resumed drilling the rescue tunnel.
Finally, 78 hours after the tragedy began, the drill penetrated the shaft and the drill operator shouted with joy. The last miner was pulled to safety 5 hours later from the Quecreek Mine in Somerset County, Pennsylvania on July 28, 2002. After being trapped 240 feet below the surface, and with body temperatures as low as 92.5 Fahrenheit, they would all make full recoveries (see figure 1.1).
Figure 1.1. A Quecreek miner is rescued from the flooded mine after spending 3 days crouched in waist-deep water. (Photo courtesy of the U.S. Department of Labor.)
You may wonder why a software development book starts with a story about a mining rescue. If you’ve performed agile software development previously, you’ve probably identified the parallels. Let’s look at a few.
All software projects have constraints. Similar to the situation during the Quecreek rescue, the number-one constraint is frequently time. The Quecreek rescue team had a few days to reach the miners. Software projects are often limited to a few days, weeks, or months, after which they’re of no value. Like a Sunday newspaper delivered on Monday, all the quality work and effort invested in the project are worthless if you don’t meet your most critical priority.
The rescue project also had a clear vision of the primary project priority: to reach the miners while they were still alive. A secondary priority was to reach them before they got hypothermia, and a third priority was to reach them before they started losing consciousness due to hunger. The team focused on delivering the number-one priority first.
When you perform software projects, you can lose track of your priorities, things can get muddy, and low-value work can hold up project delivery. Agile software development asks you to follow the Quecreek model by identifying what is critical and focusing on delivering to meet the critical need as soon as possible.
Quecreek also reinforces another agile tenet: you should expect change, you should embrace change, and you should be ready to plan and adapt frequently. The Quecreek rescuers adapted to broken drill bits, gas lines blocking their path, and the need to reduce the time required to create a fishing device. In software development, you encounter similar situations. You discover a missing requirement, you identify a technical constraint that prevents you from following your initial design, or a third party delivers their part of the project later than expected. These types of issues happen on every software project; and to ensure success, agile asks you not to be surprised but to continue to perform by adapting to the reality of the situation.
Finally, the Quecreek rescue demonstrated goodwill and collaborative team work. Ideas came from all team members, such as the suggestion to try positive air pressure to keep the water at bay. Goodwill and collaboration were also demonstrated when the rescue team approached Frank Stockdale and asked if he could create the fishing tool. Stockdale didn’t ask the rescuers to spend days creating a contract and going through legal papers; instead, he trusted the rescue team and quickly delivered the fishing device.
Agile development depends on this type of relationship with customers and vendors. You want a vendor who is a partner, not a vendor who is considered the enemy because you spend more time talking about contracts than ensuring the delivery of value.
In this chapter, we’ll help you understand the need for agile practices, what agile really is, and how agile contrasts to plan-driven development practices. We’ll conclude the chapter by discussing the most important consideration when pursuing a development process: how does agile correlate to the most common corporate goal of increasing revenue and reducing expenses?
1.1. Is Agile just another process?
Many people may think that agile is just another software development process. Although that is true to a degree, there is a lot more to agile than just a process or just a set of practices. Agile (or agility) is more of a mindset—a way of thinking about software development. This agile mindset can be applied to any process using any set of practices. The best way to illustrate our understanding of agile is through figure 1.2.
Figure 1.2. The relationship between agile values, principles, and practices
Today the market is moving quickly, and as a result, the software development lifecycle needs to be flexible enough to enable organizations to seize new and emerging market opportunities before their competitors do. To reach the desired ability to respond to constant change, your software process needs to focus on what is truly important.
Similar to the way you pack light when you’re going to backpack around Europe, your process needs to be light. You need to increase everything in the process that adds value to the end goal and decrease everything that doesn’t add value. Agile values attempt to highlight what adds value in a software development process.
1.1.1. The Agile Manifesto and related values
In 2001, a group of authors wrote a document called the Manifesto for Agile Software Development, with a goal of identifying the values that yield the most benefit to a software development process. Let’s look at the manifesto, which is available online at http://agilemanifesto.org/:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
When people first read the manifesto they immediately agree with the stated values or they hesitate. The hesitation usually comes from the perception that an agile methodology throws away the items on the right (processes, tools, documentation, contracts, and planning). This is completely false. The manifesto is saying that the items on the right do add value to the development process but the items on the left (interaction between individuals, developing working software, and so on) provide more value to the process. The manifest...