Manifesto for Agile Software Development

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.

Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas

© 2001, the above authors
this declaration may be freely copied in any form,
but only in its entirety through this notice.

Embrace change!  Photo credit

In a recently published patent, Google describes a vision for an open wireless world, one in which mobile devices (and smartphones in particular) are no longer married to particular cellular service providers.

(…)

The Google patent for “Flexible Communication Systems and Methods” contends that cellphone users should also have the freedom to connect through various networks and methods, and that the communication service they choose at any particular time and location should be determined by competitive market forces.

The idea is that you could, for example, make phone calls and browse the internet on your smartphone via WiFi when at home, Verizon when downtown, and perhaps AT&T when out in the countryside. You’d base your decision on both pricing and quality of service, with the quality of coverage in your current location playing a major role.

Full article: Google’s End Run Around the Wireless Carriers, via TechCrunch

(…)

Throughout the 1980s and into the 1990s, most DoD projects were mandated to follow a waterfall cycle of development as documented in the published standard DoD STD 2167. A report on failure rates in one sample concluded that 75 percent of the projects failed or were never used [Larman2004]. Consequently, a task force was convened. Chaired by Dr. Frederick Brooks, a well-known software engineering expert, the report recommended replacing the waterfall with iterative and incremental development:

DOD STD 2167 likewise needs a radical overhaul to reflect modern best practice. Evolutionary development is best technically, it saves time and money.

Statistical evidence and several authors’ experience [Larman2004],[Boehm1988],[Tomas2001] leads to conclude that the waterfall model does not work. By looking deeper into the assumptions of the waterfall model, it is possible to understand why it fails.

ASSUMPTIONS UNDERLYING THE WATERFALL MODEL

In retrospect, it appears that we made at least four key assumptions with the model that simply turned out to be incorrect:

1. There exists a reasonably well-defined set of requirements if we only take the time to understand them.
2. During the development process, changes to requirements will be small enough that we can manage them without substantially rethinking or revising our plans.
3. System integration is an appropriate and necessary process, and we can reasonably predict how it will go based upon architecture and planning.
4. Software innovation and the research and development that is required to create a significant new software application can be done on a predictable schedule.

Let’s look at these assumptions in light of what we have learned over the last few decades of building enterprise class systems.

Assumption 1: There Exists a Reasonably Well-Defined Set of Requirements if Only We Take the Time to Understand Them.
We now realize that there are a number of reasons why this assumption is false:
Software, is intangible. We envision solutions that we think will work; customers concur that our vision appears to make sense—while they simultaneously envision something somewhat different. We write down those elements in relatively formal constructs, such as software requirements specifications, that are difficult to write and read, and then use that flawed understanding to
drive system development.
The “Yes, But” syndrome. Leffingwell [Leffingwell and Widrig 2003] describes the “Yes, But” syndrome as the reaction that most of us receive when we deliver software to a customer for the first time: “Yes, I see it now, but no, that’s not exactly what I need.” Moreover, the longer it takes for us to deliver software to the end user, the longer it takes to elicit that reaction and the longer it takes to evolve a solution that actually addresses the user’s needs.
Changing business behavior. We also discovered an even more pernicious aspect of providing software solutions: delivery of a new system changes the basic requirements of the business and the behavior of the system, so the actual act of delivering a system causes the requirements on the system to change. The longer we wait to discover the change, the greater the change is going to be and the more rework will be required.

Assumption 2: Change Will Be Small and Manageable

Requirements do change while the system is being developed, whether in the form of clarification of poorly written requirements or actual change motivated by external factors.
Moreover, the longer the time between determining the requirements and delivering the system, the more substantial the change will be. Therefore, big systems with long development times will have a very big history of changes to requirements. If development were really fast and changes were really small, we could track our market very closely. But if development is slow and change happens fast, bad things are bound to happen.

Assumption 3: System Integration Will Go Well.

This assumption underlies our premise that, with appropriate planning and analyses, we could predict how all the components of a complex system would come together and interact. We assumed that our architectural plans would address any system integration problems; that volumes of code written by largely independent teams would work well together; and that overall system behavior, including performance and reliability, could somehow be predicted by our plans and models. To address this challenge, we sometimes even created entire teams or departments—system integration teams—responsible for bringing all of those components together and testing at the system level. Well, of course, system integration didn’t go well, and we discovered that many of our assumptions about the way the system needed to work were incorrect. Our faulty assumptions often led to significant rework on a wholesale basis, further delaying the system and setting us up for another difficult system integration attempt somewhere down the road. The lesson learned is that even a relatively thorough up-front analysis could not predict nor control the system integration process. The problem is too complex; change happens midstream; technologies evolve during the project and integration assumptions are often wrong and are simply discovered too late.

Assumption 4: We Can Deliver on Schedule.
Given the time for proper planning, we assumed that we could know enough about the system, its requirements, and the resources required to build it, and that we could reliably predict when we were going to deliver a system. Underlying this assumption are many more:

• We have planned for what we know, and we have left sufficient allowance in our plans for what we don’t know.

• We have allowed room in the schedule to recover from unpredictable events.

• We are good at estimating software development in general, and therefore our prediction in this case is reasonably accurate.

The most telling assumption of all is that we can do it once, and we can do it right the first time. In other words, we assumed that we could schedule innovation, and even software research, in a predictable way. We have now proven that this is not the case.
In my own personal analyses and studies of software projects over the last decade or so, I’ve concluded that teams actually can estimate—just not very well—and that their estimates are typically off by approximately a factor of at least two. In other words, even with a known, fixed set of resources and even when facing a new application in a known domain, teams will typically take
twice as long as they estimate to reach the desired result.
This is partly attributable to the complexity of the planning in waterfall projects being exponentially harder than it seems because different parts of the system (or parts of the team) transition between phases at different times. So, essentially we have “dozens, and perhaps even hundreds,” of parallel waterfall models proceeding (not exactly in parallel) toward a final result.

ENTER CORRECTIVE ACTIONS VIA AGILE METHODS

How do agile methods fundamentally address the flawed assumptions of our former model?
Agile avoids virtually all of these underlying assumptions of the waterfall model and addresses these problems in the following ways:

1. We do not assume that we, or our customers, can fully understand all the requirements, or that anyone can possibly understand them all up front.
2. We do not assume that change will be small and manageable. Rather, we assume that change will be constant, and we deliver in small increments to better track change.
3. We do assume that system integration is an important process and is integral to reducing risk. Therefore, we integrate from the beginning and we integrate continuously. We live under the mantra “the system always runs,” and we strive to assure that there is always product available for demonstration and/or potential shipment.
4. We do not assume that we can develop new, state-of-the-art, un-proven, innovative, and risk-laden software projects on a fixed-functionality and fixed-schedule basis. Indeed, we assume that we cannot. Instead, we assume that we can deliver the most important features to our customer earlier, rather than later, than the customer might have expected. In so doing, we can get immediate feedback on whether we are building the right solution. If through immediate and direct customer feedback we discover that it is not the right solution, all is not lost. A much smaller investment has been made to this point, and we can refactor the solution and evolve it rapidly, while delivering continuously, and we can do so without excess rework.

In conclusion, agile makes an entirely new set of assumptions about the fundamental nature of this innovative process we call software development. In so doing, we change the basic paradigm: we move to rapid delivery of the highest priority requirements, followed by rapid feedback and rapid evolu-
tion, and we are thereby better able to deliver a solution that truly meets the customer’s end goals.

(…)

Read the complete chapter here. Order the book via Amazon here.

For local information about Agile Methods (in spanish), go to: www.chileagil.cl , or ask us at: agile@firenxis.com.

“Image: Waterfall Vertigo”

Photo from flickr.

Quality Assurance: Why?

In these times, everybody can give away lots of services, to lots of people, but not everybody can do it the right way. What’s even worse, it’s not easy to know if you are giving a good service to your customers. Whether you are a mobile operator selling ringtones, a bank, or a retailer selling flowers, you know the uptime is critical.

Failures are unacceptable. Always. You do not expect your barista at the local Starbucks to take your order, take the money, give you the change, and then hear “We cannot complete your request at this moment. Please come back later”. Imagine how frustrating that’d be. Imagine how frustrating it IS for YOUR customers, when a machine displays those words on a screen.

In an era of fully remote services, most interaction with customers is through machines. When a transaction fails on your website, some (if not all) of these take place:

• You do not fulfill your customer’s needs.
• You lose a sell.
• Your customer leaves frustrated.
• Your customer loses confidence in your service.
• Your customer loses confidence in your brand.
• You fail in your company’s mission.

Do our clients receive a good service?

This is a big question, that’s been driving our research for a long time: Are your customers getting a good service? How do you know? Is it possible to know? If you don’t know that answer… will you just hope that your customers receive good service, based on income figures? are you willing to address quality problems ONLY after your income is affected? if so, how long it would take you to figure that out? are you sure those problems aren’t taking place now?

We can work together in order to answer these questions.

Some problems we’ll face

As we’ve seen, there are tricky questions to answer. We want to be in the shoes of a customer, experience your service, and get a quantifiable qualification of your service, week to week, or even minute by minute. In other words, we want to measure the quality.

Often quality is the sum of all the organization efforts. It is clear that customers perceive the services as a whole, and a failure in one organizational unit could detriment overall service.

We’d also want to analyze how much quality influences in your income. Some services might be more sensitive to quality than others. Efforts could be much more effective when applied to the real problem zone.

Our research

At Firenxis we have assessed these problems and we can offer innovative solutions based in automatic customers simulation, quality metrics and resulting quality data analysis. We are commited to solve our customers problems of quality assurance, by using our tools and knowledge, or by creating new tools and knowledge. We can bring this until now hidden information to the light, and help you fulfill your customers expectations.