Agile Development Principles


We follow these principles:

 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

 Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

 Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

 Business people and developers must work together daily throughout the project.

 Build projects around motivated individuals.

 Give them the environment and support they need, and trust them to get the job done.

 The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

 Working software is the primary measure of progress.

 Agile processes promote sustainable development.

 The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

 Continuous attention to technical excellence and good design enhances agility.

 Simplicity—the art of maximizing the amount of work not done—is essential.

 The best architectures, requirements, and designs emerge from self-organizing teams.

 At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.


Second, contracts with hard numbers and dates can encourage both vendor and client to focus on the wrong thing—namely, the contract. Agilists note that these parties can readily lose track of the spirit of the contract by focusing on its letter. In the face of a changing business climate for the client, the vendor may grow focused on delivering the functionality spelled out in the contract. In spite of flexibility and a willingness to adjust to change on the part of the vendor, the client may refuse to budge from the contract price. Either scenario, Agilists would argue, sticks one of the parties with the short end of the stick and will discolor future engagements.

“No amount of process can replace good people.”
Crystal is based on the idea that different projects need different sorts of methodologies. The Crystal family is a set of methodologies that all share the same principles and building blocks, with each individual methodology geared toward a different project situation. Crystal should not be confused with a toolkit approach, such as the one employed by the Rational Unified Process (RUP), which provides a development kit of processes, practices, and documents that is meant to be tailored for each project. Instead, the Crystal approach is to collect and catalogue sample methodologies. A project selects a base methodology from that catalogue and tailors it to its particular environment and circumstances.
The Crystal methodologies are people focused, communication-centric, and highly tolerant—described by one agile practitioner as “the least dogmatic process conceivable” [Marick04]. Nonetheless, there are two restrictions on all the Crystal methodologies: they do not currently address life-critical systems, and they are based on collocated teams. The three properties that are central to every Crystal methodology are frequent delivery, close communication, and reflective improvement.
Finally, the methodology has an offshoot, Crystal Orange Web, that—as opposed to addressing a single project—takes on a steady stream of initiatives

Principle 7 of the Lean Software Development Methodology:
Complex systems require expertise that is both broad and deep. A common pitfall in product development is the tendency to overemphasize one’s expertise in a given area to the detriment of the entire system. A lopsided approach can be taken at the individual, project, and even organizational level because in each case the entity will want to maximize performance in its own area of specialization. The integrity of a system is based on how well its parts work together, not simply the quality of each individual part.

Mix and Match Approach:
Also, as has been noted previously in this book, whatever helps to make software better, faster, and more useful to the customer should be considered fair game.

Waste – Defects: Fixing a defect takes time that could have been spent on something more productive. Defects typically take more effort to fix the longer they go unnoticed. Therefore, adjusting processes to find defects faster can eliminate waste.

From a management point of view, iteration zero outputs may include:
 Initial list of features identified and prioritized
 Project planning mechanism (spreadsheet, simple database, index cards, or other planning tool) identified and agreed upon
Identification of and agreement upon a team customer, essential stakeholders, and business users and the nature of the iterative planning process, such as the time of planning meetings and the length of iterations.

Project teams should not fret over how agile they have or have not become. Rather, if a team needs to measure progress, it should focus on whether it and the business are communicating better; whether the code is cleaner, easier to maintain and less prone to defects; and whether, ultimately, the business is receiving more of what it has been asking for. Ultimately, a team should not really care whether it is more agile if all the rest of this activity is taking place.

Automation has been built into systems like .NET. With minor standards in place (such as source-safe or a method for backing up existing systems), the Build and Deploy steps of application development are already a single button.

Has Jeanne done any automated testing? If so, what?

It appears – at least from my standpoint – that automated testing/datamanagement will be our biggest challenge.


Additionally—and unlike traditional projects—agile projects are always planning

Prescriptive software processes such as the Unified Process (Kruchten 2000; Ambler 2001b), the OPEN Process (Graham, Henderson-Sellers, and Younessi 1997), and the Object-Oriented Software Process (Ambler 1998; Ambler 1999) all have their place. It is just that they may not be as appropriate as their supporters consider them to be. The problem with these approaches is that they typically focus on prescriptive procedures and the artifacts that should be created, approaches that are often implemented by organizations who consider people to be "plug and play compatible." In other words, their belief is that, with the right process in place and with the necessary number of artifacts, you can swap people in and out of a project with relative ease. My experience is that this is only true when the person you are replacing isn't very productive, something that is often the case in organizations following a heavy-weight process. The reality is that replacing a productive person is difficult regardless of the process you follow, so the "plug and play compatibility" goal is questionable at best.

Integrating Agile Development in the Real World, Peter Schuh, Charles River Media, 2005 Ch 2.
Integrating Agile Development in the Real World, Peter Schuh, Charles River media, 2005, Ch3.
“ “ “
Chapter 4
Chapter 5
Notes to myself regarding Chapter 7
Chapter 10
Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process, Scott W. Ambler, John Wiley & Sons 2002

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License