Becoming Agile

...in an imperfect world

Ahmed Sidky, Greg Smith

• Publisher: Manning
• Year: 2009
• ISBN:
  9781638354123
• Topic: Computer Science
• Subtopic: Software Development
• Index: Computer Science

Many books discuss Agile from a theoretical or academic perspective. Becoming Agile takes a different approach and focuses on explaining Agile from a case-study perspective. Agile principles are discussed, explained, and then demonstrated in the context of a case study that flows throughout the book. The case study is based on a mixture of the author's real-world experiences. Becoming Agile also focuses on the importance of adapting Agile principles to the realities of your environment. In the early days of Agile, there was a general belief that Agile had to be used in all phases of a project, and that it had to be used in its purest form. Over the last few years, reputable Agile authorities have begun questioning this belief: We're finding that the best deployments of Agile are customized to the realities of a given company. Becoming Agile discusses the cultural realities of deploying Agile and how to deal with the needs of executives, managers, and the development team during migration. The author discusses employee motivation and establishing incentives that reward support of Agile techniques. Purchase of the print book comes with an offer of a free PDF, ePub, and Kindle eBook from Manning. Also available is all code from the book. Praise for Becoming Agile... "This is much more than just a book about Agile. This is a roadmap. A very detailed roadmap that takes you from the initial "is Agile right for me?" stage through completion and delivery of your pilot project and beyond."-Charlie Griefer, Senior Software Engineer, Amcom Technology"...a must read for those of us who have come from years of waterfall and attempts at changes to "traditional" methodologies or processes... clear, concise and has plenty of example scenarios that many individuals and corporations would identify with."-Jamie Phillips, Senior Software Engineer, Picis Inc"This book is quite unique. It is written in a form of a 5-day training course. I am usually not a fan of such a writing style, but I think that Becoming Agile is an exception. It's about a software process and as such requires a lot of case studies, group exercises (or at least what a book format allows), and therefore the training course style is perfect to facilitate learning."-Vladimir Pasman, Cocoacast.com"Becoming Agile in an Imperfect World offers a different and useful look at Agile methods. Reminding us that becoming agile is more of a mindset adjustment than a process change, Sidky and Smith use a case study to share their insights and tools throughout the book, including the unique Sidky Agile Measurement Index (SAMI)."-Sanjiv Augustine, President, LitheSpeed LLC and author of Managing Agile Projects"The authors emphasise that the aim should be to create a customised agile development process that is tailored to the needs of the organisation...Instead of aiming for "agile perfection", one should aim at reaching the right level of agility for one's organisation. Excellent advice!"-Kailash Awati, Eight to Late"The book totally inspired me. A lot of my readings on Agile from back in the day were very theoretical and high level at the same time. But Becoming Agile helps take you to the next level by going beyond the theory and into the nitty gritty practicality of employing the Agile approach. So it was very energizing having the game plan laid out in front of you, as well as the hurdles you'll encounter and how to overcome them."-Tariq Ahmed, author of Flex 3 in Action

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...