The Full Wiki

More info on Agile software development

Agile software development: Wikis


Note: Many of our articles have direct quotes from sources you can cite, within the Wikipedia article! This article doesn't yet, but we're working on it! See more info or our list of citable articles.


From Wikipedia, the free encyclopedia

Software development process
Activities and steps
Requirements · Specification
Architecture · Design
Implementation · Testing
Deployment · Maintenance
Agile · Cleanroom · DSDM
Iterative · RAD  · RUP  · Spiral
Waterfall · XP · Scrum  · Lean
V-Model  · FDD  · TDD
Supporting disciplines
Configuration management
Quality assurance (SQA)
Project management
User experience design
Compiler  · Debugger  · Profiler
GUI designer
Integrated development environment

Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. The term was coined in the year 2001 when the Agile Manifesto was formulated.

Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices intended to allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.

Conceptual foundations of this framework are found in modern approaches to operations management and analysis, such as lean manufacturing, soft systems methodology, speech act theory (network of conversations approach), and Six Sigma.[citation needed]



There are many specific agile development methods. Most promote development, teamwork, collaboration, and process adaptability throughout the life-cycle of the project. The only metric showing Agile method is more productive than other methods is a Dr. Dobb's Journal survey. [1]

Agile methods break tasks into small increments with minimal planning, and do not directly involve long-term planning. Iterations are short time frames ("timeboxes") that typically last from one to four weeks. Each iteration involves a team working through a full software development cycle including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders. This helps minimize overall risk, and lets the project adapt to changes quickly. Stakeholders produce documentation as required. An iteration may not add enough functionality to warrant a market release, but the goal is to have an available release (with minimal bugs) at the end of each iteration.[2] Multiple iterations may be required to release a product or new features.

Team composition in an agile project is usually cross-functional and self-organizing without consideration for any existing corporate hierarchy or the corporate roles of team members. Team members normally take responsibility for tasks that deliver the functionality an iteration requires. They decide individually how to meet an iteration's requirements.

Agile methods emphasize face-to-face communication over written documents when the team is all in the same location. When a team works in different locations, they maintain daily contact through videoconferencing, voice, e-mail, etc.

Most agile teams work in a single open office (called bullpen), which facilitates such communication. Team size is typically small (5-9 people) to help make team communication and team collaboration easier. Larger development efforts may be delivered by multiple teams working toward a common goal or different parts of an effort. This may also require a coordination of priorities across teams.

No matter what development disciplines are required, each agile team will contain a customer representative. This person is appointed by stakeholders to act on their behalf and makes a personal commitment to being available for developers to answer mid-iteration problem-domain questions. At the end of each iteration, stakeholders and the customer representative review progress and re-evaluate priorities with a view to optimizing the return on investment and ensuring alignment with customer needs and company goals.

Most agile implementations use a routine and formal daily face-to-face communication among team members. This specifically includes the customer representative and any interested stakeholders as observers. In a brief session, team members report to each other what they did yesterday, what they intend to do today, and what their roadblocks are. This standing face-to-face communication prevents problems from being hidden.

Agile emphasizes working software as the primary measure of progress. This, combined with the preference for face-to-face communication, produces less written documentation than other methods. The agile method encourages stakeholders to prioritize wants with other iteration outcomes based exclusively on business value perceived at the beginning of the iteration.

Specific tools and techniques such as continuous integration, automated or xUnit test, pair programming, test driven development, design patterns, domain-driven design, code refactoring and other techniques are often used to improve quality and enhance project agility.


The modern definition of agile software development evolved in the mid-1990s as part of a reaction against "heavyweight" methods, perceived to be typified by a heavily regulated, regimented, micro-managed use of the waterfall model of development. The processes originating from this use of the waterfall model were seen as bureaucratic, slow, demeaning, and inconsistent with the ways that software developers actually perform effective work. A case can be made that agile and iterative development methods mark a return to development practice from early in the history of software development.[3] Initially, agile methods were called "lightweight methods."

An adaptive software development process was introduced in a paper by Edmonds (1974).[4] Notable early Agile methods include Scrum (1995), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development, and Dynamic Systems Development Method (DSDM) (1995). These are now typically referred to as Agile Methodologies, after the Agile Manifesto published in 2001.

In 2001, 17 prominent figures[5] in the field of agile development (then called "light-weight methods") came together at the Snowbird ski resort in Utah to discuss ways of creating software in a lighter, faster, more people-centric way. They coined the terms "Agile Software Development" and "agile methods", and they created the Agile Manifesto, widely regarded as the canonical definition of agile development and accompanying agile principles. Later, some of these people formed The Agile Alliance,[6] a non-profit organization that promotes agile development.


Agile methods are a family of development processes, not a single approach to software development. The Agile Manifesto states:

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.

Some of the principles behind the Agile Manifesto[7] are:

  • Customer satisfaction by rapid, continuous delivery of useful software
  • Working software is delivered frequently (weeks rather than months)
  • Working software is the principal measure of progress
  • Even late changes in requirements are welcomed
  • Close, daily cooperation between business people and developers
  • Face-to-face conversation is the best form of communication (co-location)
  • Projects are built around motivated individuals, who should be trusted
  • Continuous attention to technical excellence and good design
  • Simplicity
  • Self-organizing teams
  • Regular adaptation to changing circumstances

The manifesto spawned a movement in the software industry known as agile software development.

In 2005, Alistair Cockburn and Jim Highsmith gathered another group of people—management experts, this time—and wrote an addendum, known as the PM Declaration of Interdependence.

The functioning principles of Agile can be found in lean manufacturing and six sigma. These concepts include error proofing, eliminating waste, creating flow, adding customer value, and empowering workers. The concepts were first formally espoused in the 14 principles of the Toyota Way, the two pillars of the Toyota Production System (Just-in-time and smart automation), the 5S methodology, and Deming’s 14 points. These have been summarized in the seven points of lean software development.

Comparison with other methods

Agile methods are sometimes characterized as being at the opposite end of the spectrum from "plan-driven" or "disciplined" methods. This distinction is misleading, as it implies that agile methods are "unplanned" or "undisciplined". A more accurate distinction is that methods exist on a continuum from "adaptive" to "predictive".[8] Agile methods lie on the "adaptive" side of this continuum.

Adaptive methods focus on adapting quickly to changing realities. When the needs of a project change, an adaptive team changes as well. An adaptive team will have difficulty describing exactly what will happen in the future. The further away a date is, the more vague an adaptive method will be about what will happen on that date. An adaptive team can report exactly what tasks are being done next week, but only which features are planned for next month. When asked about a release six months from now, an adaptive team may only be able to report the mission statement for the release, or a statement of expected value vs. cost.

Predictive methods, in contrast, focus on planning the future in detail. A predictive team can report exactly what features and tasks are planned for the entire length of the development process. Predictive teams have difficulty changing direction. The plan is typically optimized for the original destination and changing direction can cause completed work to be thrown away and done over differently. Predictive teams will often institute a change control board to ensure that only the most valuable changes are considered.

Agile methods have much in common with the "Rapid Application Development" techniques from the 1980/90s as espoused by James Martin and others.

Contrasted with other iterative development methods

Most agile methods share other iterative and incremental development methods' emphasis on building releasable software in short time periods. Agile development differs from other development models: in this model time periods are measured in weeks rather than months and work is performed in a highly collaborative manner. Most agile methods also differ by treating their time period as a timebox.

Contrasted with the Waterfall Methodology

Agile development has little in common with the waterfall model. The Waterfall methodology is the most structured of the methods, stepping through requirements, analysis, design, coding, and testing in a strict, pre-planned, "all at once" sequence. Progress is often measured in terms of deliverable artifacts: requirement specifications, design documents, test plans, code reviews and the like.

A common criticism of the waterfall model is its inflexible division of a project into separate stages, where commitments are made early on, making it difficult to react to changes in requirements as the project executes. This means that the waterfall model is likely to be unsuitable if requirements are not well understood/defined or change in the course of the project.[9]

Agile methods, in contrast, produce completely developed and tested features (but a very small subset of the whole) every few weeks. The emphasis is on obtaining the smallest workable piece of functionality to deliver business value early and continually improving it and/or adding further functionality throughout the life of the project. If a project being delivered under Waterfall is cancelled at any point up to the end, there is often nothing to show for it beyond a huge resources bill. With Agile, being cancelled at any point will still leave the customer with some worthwhile code that has likely already been put into live operation.

Adaptations of Scrum[10] show how agile methods are augmented to produce and continuously improve a strategic plan.

Some agile teams use the waterfall model on a small scale, repeating the entire waterfall cycle in every iteration.[11] Other teams, most notably Extreme Programming teams, work on activities simultaneously.

Contrasted with "cowboy coding"

"Cowboy coding" is the absence of a defined or structured method; i.e., team members do whatever they feel is right. The Agile approach is sometimes confused with cowboy coding due to its frequent re-evaluation of plans, emphasis on face-to-face communication, and relatively sparse use of documentation. However, Agile teams follow clearly defined, even rigid processes and controls (e.g., deadlines for completion of coding/testing); it is likely the flexibility and adaptability of the overall methodology which causes the confusion. Further, Agile controls offer stronger levels of accountability. The degradation of such controls or procedures can lead to activities that are often categorized as cowboy coding.

Suitability of agile methods

There is little if any consensus on what types of software projects are best suited for the agile approach. Many large organizations have difficulty bridging the gap between the traditional waterfall method and an agile one.

Large scale agile software development remains an active research area.[12][13]

Agile development has been widely documented (see Experience Reports, below, as well as Beck[14] pg. 157, and Boehm and Turner[15]) as working well for small (<10 developers) co-located teams.

Some things that can negatively impact the success of an agile project are:

  • Large scale development efforts (>20 developers), though scaling strategies[16] and evidence to the contrary[17] have been described.
  • Distributed development efforts (non-co-located teams). Strategies have been described in Bridging the Distance[18] and Using an Agile Software Process with Offshore Development[19]
  • Forcing an agile process on a development team[20]
  • Mission critical systems where failure is not an option at any cost (Software for surgical procedures).

Several successful large scale agile projects have been documented. BT has had several hundred developers situated in the UK, Ireland and India working collaboratively on projects and using Agile methods. While questions undoubtedly still arise about the suitability of some Agile methods to certain project types, it would appear that scale or geography, by themselves, are not necessarily barriers to success.[citation needed]

Barry Boehm and Richard Turner suggest that risk analysis be used to choose between adaptive ("agile") and predictive ("plan-driven") methods.[15] The authors suggest that each side of the continuum has its own home ground as follows:

Agile home ground:[15]

  • Low criticality
  • Senior developers
  • Requirements change often
  • Small number of developers
  • Culture that thrives on chaos

Plan-driven home ground:[15]

  • High criticality
  • Junior developers
  • Requirements do not change often
  • Large number of developers
  • Culture that demands order

Agile methods and method tailoring

In the literature, different terms refer to the notion of method adaptation, including ‘method tailoring’, ‘method fragment adaptation’ and ‘situational method engineering’. Method tailoring is defined as:

A process or capability in which human agents through responsive changes in, and dynamic interplays between contexts, intentions, and method fragments determine a system development approach for a specific project situation.[21]

Potentially, almost all agile methods are suitable for method tailoring. Even the DSDM method is being used for this purpose and has been successfully tailored in a CMM context.[22] Situation-appropriateness can be considered as a distinguishing characteristic between agile methods and traditional software development methods, with the latter being relatively much more rigid and prescriptive. The practical implication is that agile methods allow project teams to adapt working practices according to the needs of individual projects. Practices are concrete activities and products that are part of a method framework. At a more extreme level, the philosophy behind the method, consisting of a number of principles, could be adapted (Aydin, 2004).[21]

Extreme Programming (XP) makes the need for method adaptation explicit. One of the fundamental ideas of XP is that no one process fits every project, but rather that practices should be tailored to the needs of individual projects. Partial adoption of XP practices, as suggested by Beck, has been reported on several occasions.[23] A tailoring practice is proposed by Mehdi Mirakhorli which provides sufficient roadmap and guideline for adapting all the practices. RDP Practice is designed for customizing XP. This practice first time proposed as a long research paper in APSO workshop at ICSE 2008 conference and yet it is the only proposed and applicable method for customizing XP. Although it is specifically a solution for XP, this practice has the capability of extending to other methodologies. At first glance, this practice seems to be in the category of static method adaptation but experiences with RDP Practice says that it can be treated like dynamic method adaptation. The distinction between static method adaptation and dynamic method adaptation is subtle.[24] The key assumption behind static method adaptation is that the project context is given at the start of a project and remains fixed during project execution. The result is a static definition of the project context. Given such a definition, route maps can be used in order to determine which structured method fragments should be used for that particular project, based on predefined sets of criteria. Dynamic method adaptation, in contrast, assumes that projects are situated in an emergent context. An emergent context implies that a project has to deal with emergent factors that affect relevant conditions but are not predictable. This also means that a project context is not fixed, but changing during project execution. In such a case prescriptive route maps are not appropriate. The practical implication of dynamic method adaptation is that project managers often have to modify structured fragments or even innovate new fragments, during the execution of a project (Aydin et al., 2005).[24]

Agile methods

Some of the well-known agile software development methods:

Agile practices

Note: Although these are often considered methodologies in and of themselves, they are simply practices used in different methodologies.

Agile beyond software development

Agile software development depends on some special characteristics possessed only by software, such as object technologies and the ability to automate testing. However, related techniques have been created for developing non-software products, such as semiconductors, motor vehicles, or chemicals. For more on them, see Flexible product development.

Measuring agility

While agility can be seen as a means to an end, a number of approaches have been proposed to quantify agility. Agility Index Measurements (AIM)[1] score projects against a number of agility factors to achieve a total. The similarly-named Agility Measurement Index [2], scores developments against five dimensions of a software project (duration, risk, novelty, effort, and interaction). Other techniques are based on measurable goals [3]. Another study using fuzzy mathematics[25] has suggested that project velocity can be used as a metric of agility. There are agile self assessments to determine whether a team is using agile practices.[26][27]

While such approaches have been proposed to measure agility, the practical application of such metrics has yet to be seen.


The criticisms regarding insufficient software design and lack of documentation are addressed by the Agile Modeling method, which can easily be tailored into agile processes.[citation needed]

Agile software development has been criticized because it may not bring about all of the claimed benefits unless utilized by above average programmers; above average programmers create above average code regardless of the method used.[citation needed]

Agile does not readily lend itself to traditional project accounting practices, therefore financial forecasting is less predictable when with Agile development. [28]

With a passionate drive towards reducing, if not eliminating documentation, teams establish a direction that can be perceived as satisfying the core Agile Manifesto.[citation needed] As an individual team member, this direction provides for greater efficiency in the short term and provides for more rapidly observed delivery by the stakeholder.[citation needed] The dangers are the loss of recognition that systems/solutions change continually over time as well as team members.[citation needed] Software’s highly complex nature as well as aggressively becoming mission critical to businesses, demands more thorough understanding of decisions being made when changes are to take place.[citation needed] Without having designs or details on purpose and process, the effectiveness of the team diminishes and forces developers to go through the code to discover solutions.[citation needed] Current software industry trends support system solution reuse and the ability to have disparate data sources through SOA architecture. Knowledge of the business process in communication across different domains makes for greater difficulty when designs are unavailable as reference when change is to occur and the subsequent validation of the impact of that change for business risk management. The developer is forced to ‘trace’ through code invariably written by other programmers without the knowledge of purpose and direction.[citation needed] Essentially it is a balance that is needed to determine where documentation in fact ‘has value’ for the greater good of the business as a whole and often to the disadvantage of the initial development team trying to get the solution completed.

A reminder that the very first day a new solution is deployed, is the very first day it has become a legacy system ready for change.[citation needed]

Experience reports

Agile development has been the subject of several conferences. Some of these conferences have had academic backing and included peer-reviewed papers, including a peer-reviewed experience report track. The experience reports share industry experiences with agile software development.

As of 2006, experience reports have been or will be presented at the following conferences:

  • XP (2000[29], 2001, 2002, 2003, 2004, 2005, 2006[30], 2010[31] )
  • XP Universe (2001[32])
  • XP/Agile Universe (2002,[33] 2003,[34] 2004[35])
  • Agile Development Conference[36] starting from 2003 to present (peer-reviewed; proceedings published by IEEE)

See also


  1. ^
  2. ^ Beck, Kent (1999). "Embracing Change with Extreme Programming". Computer 32 (10): 70–77. doi:10.1109/2.796139. 
  3. ^ Gerald M. Weinberg: We were doing incremental development as early as 1957, in Los Angeles, under the direction of Bernie Dimsdale [at IBM’s ServiceBureau Corporation]. He was a colleague of John von Neumann, so perhaps he learned it there, or assumed it as totally natural. I do remember Herb Jacobs (primarily, though we all participated) developing a large simulation for Motorola, where the technique used was, as far as I can tell, ... All of us, as far as I can remember, thought waterfalling of a huge project was rather stupid, or at least ignorant of the realities. I think what the waterfall description did for us was make us realize that we were doing something else, something unnamed except for “software development. quoted in Larman, Craig; Victor R. Basili (June 2003). "Iterative and Incremental Development: A Brief History" (pdf). Computer 36 (6): pp 47–56. doi:10.1109/MC.2003.1204375. Retrieved 2007-02-22.  (Permission note)
  4. ^ Edmonds, E. A. (1974). "A process for the development of software for non-technical users as an adaptive system". General Systems XIX: 215–218. 
  5. ^ 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 and Dave Thomas
  6. ^ Agile Alliance
  7. ^ Agile Manifesto principles
  8. ^ Boehm, B.; R. Turner (2004). Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison-Wesley. ISBN 0-321-18612-5.  Appendix A, pages 165-194
  9. ^ Sommerville, Ian (2007) [1982]. "4.1.1. The waterfall model". Software engineering (8th ed.). Harlow: Addison Wesley. pp. 66f. ISBN 0-321-31379-8. 
  10. ^ Ambler, S. (April 2008). ""Scaling Scrum - Meeting Real World Development Needs". Dr. Dobbs. Retrieved 2009-12-27. 
  11. ^ As reported by HeavyLogic
  12. ^ Agile Processes Workshop II Managing Multiple Concurrent Agile Projects. Washington: OOPSLA 2002
  13. ^ "Supersize Me" in Dr. Dobb's Journal, February 15, 2006.
  14. ^ Beck, K. (1999). Extreme Programming Explained: Embrace Change. Boston, MA: Addison-Wesley. ISBN 0-321-27865-8. 
  15. ^ a b c d Boehm, B.; R. Turner (2004). Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison-Wesley. pp. 55–57. ISBN 0-321-18612-5. 
  16. ^ Supersize Me
  17. ^ Schaaf, R.J. (2007). "Agility XL", Systems and Software Technology Conference 2007, Tampa, FL
  18. ^ Bridging the Distance
  19. ^ Using an Agile Software Process with Offshore Development
  20. ^ [The Art of Agile Development James Shore & Shane Warden pg 47]
  21. ^ a b Aydin, M.N., Harmsen, F., Slooten, K. v., & Stagwee, R. A. (2004). An Agile Information Systems Development Method in use. Turk J Elec Engin, 12(2), 127-138
  22. ^ Abrahamsson, P., Warsta, J., Siponen, M.T., & Ronkainen, J. (2003). New Directions on Agile Methods: A Comparative Analysis. Proceedings of ICSE'03, 244-254
  23. ^ Abrahamsson, P., Salo, O., Ronkainen, J., & Warsta, J. (2002). Agile Software Development Methods: Review and Analysis. VTT Publications 478
  24. ^ a b Aydin, M.N., Harmsen, F., Slooten van K., & Stegwee, R.A. (2005). On the Adaptation of An Agile Information Systems Development Method. Journal of Database Management Special issue on Agile Analysis, Design, and Implementation, 16(4), 20-24
  25. ^ Kurian, Tisni (2006). "Agility Metrics: A Quantitative Fuzzy Based Approach for Measuring Agility of a Software Process" ISAM-Proceedings of International Conference on Agile Manufacturing'06(ICAM-2006), Norfolk, U.S.
  26. ^ Nokia test, Scrum specific
  27. ^ Karlskrona test, generic agile adoption
  28. ^ The Great Pyramid of Agile
  29. ^ 2000
  30. ^ 2006
  31. ^ 2010
  32. ^ 2001
  33. ^ 2002
  34. ^ 2003
  35. ^ 2004
  36. ^ Agile Development Conference

Further reading

External links

Study guide

Up to date as of January 14, 2010

From Wikiversity


History and Origins

The Agile Manifesto

The Need for Agile methods


The Agile Manifesto

On February 11-13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, seventeen people met to talk, ski, relax, and try to find common ground and of course, to eat. What emerged was the Agile Software Development Manifesto. Representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven, heavyweight software development processes convened. Now, a bigger gathering of organizational anarchists would be hard to find, so what emerged from this meeting was symbolic a Manifesto for Agile Software Development signed by all participants.
Taken from: "History: The Agile Manifesto"

So why bother with agile methodologies?
Alistair Cockburn did research about how a process influences project teams. He concludes that the larger a project team the more a process can influence the effectiveness of the project development. However it is the people in the project teams that repeatedly argue the process that is proposed to use. Alistair Cockburn summarizes this behaviour in his quote: “People trump process”. It is true that good enough people in a team can deliver a solution where no process can improve the quality of the outcome. The most interesting part that contributed to the manifestation of agile methodologies is the fact that people working together with good communication and interaction have the ability to perform at significant higher levels than operated on an individual basis. According to Cockburn this becomes apparent time and again in brainstorming and joint problem-solving sessions. This the reason agile methodologies can contribute to project teams by focusing on increasing both the individual competencies and the collaboration levels.

For further reading visit: URL:

Authors of the Agile Manifesto

On February 11-13, 2001, seventeen people met at the Lodge in the Wasatch mountains of Utah, they initiated an agile manifesto.

They were :

  • 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

The Agile manifesto encompassed the idea of several pre-existing methodologies including:

  • Extreme Programming
  • DSDM
  • Adaptive Software Development
  • Crystal,
  • Feature-Driven Development,
  • Pragmatic Programming
  • Lean Development

These authors all work for the software industry, and did a great distribution on agile software development. That’s the reason why they became participates for the Agile manifesto.

Agile Methodologies

Defining traits of Agile Methodologies

Agility is the ability to both create and respond to change in order to profit in a turbulent business environment - Jim Highsmith, Agile Software Development Ecosystems [1]

Such a general description allows a lot of room for debate as to whether a particular methodology is Agile or not. Where there is debate, it is fair to say that a methodology which doesn't have the following principles cannot consider itself Agile.

  • Least Design Up Front
  • Accommodates changing requirements, even late in the development cycle
  • Iterations are measured in weeks, not months
  • Low bureaucracy and administration overhead
  • Continuous customer feedback and involvement
  • Complete buy-in from all stakeholders

It's also fair to say that an Agile team that fails to realize any of these principles will struggle and probably fail.

Types of Agile Methodologies

Adaptive Software Development

Adaptive software development is a management to control software project for changeable requirement and short period project.

The three key point of adaptive software development are:

  • speculation
  • collaboration
  • learning

“The overriding, powerful, indivisible, predominant benefit of the Adaptive Development Life Cycle is that it forces us to confront the mental models that are at the root of our self-delusion. It forces us to more realistically estimate our ability.” - Jim Highsmith [2]

Crystal Methods

To view the Crystal Methods section, please click the following link:

Crystal Methods

Dynamic Systems Development Method (DSDM)

What is DSDM?

DSDM is an example of an iterative (Agile) development model. DSDM approaches every step in the process to be completed only enough to be able to move to the next step. Since agile development is applied in situations where business requirements are likely to change, any further work would not benefit the overall process of delivery. The DSDM Consortium defines DSDM as a framework based on best practises that can be used to deliver new systems, which combines the most effective use of people's knowledge, tools and techniques to achieve tight project delivery timescales. The DSDM framework serves as a basis for a development and implementation process whether it is an IT project or a business change. The framework includes people (staff and skills), the technology that supports them (IT) and the processes that bind them all together (the business strategy).


The goal of DSDM is to target a demand for organizations to deliver working systems in shorter timescales. A typical DSDM project delivers an operational system within six months. The main emphasis however is that, according to the DSDM organization, most projects fail because of people issues rather than technology. Therefore the focus is providing people with guidelines to work together in a way that business goals are achieved successfully.

Because of the agile approach, DSDM build systems focus on the current needs in contrast to the traditional approach of going through all the perceived possibilities. Therefore, the resulting system is expected to better fit the business needs, be easier to test and be more likely to be accepted into the users' working practices.

The DSDM Framework Principles

The framework is based on nine initial principles which are applied in the different phases of the methodology:

  1. Active user involvement is imperative
  2. DSDM teams must be empowered to make decisions
  3. The focus is on frequent delivery of products
  4. Fitness for business purpose is the essential criterion for acceptance of deliverables
  5. Iterative and incremental development is necessary to converge on an accurate business solution
  6. All changes during development are reversible
  7. Requirements are baselined at a high level
  8. Testing is integrated throughout the lifecycle
  9. A collaborative and co-operative approach between all stakeholders is essential

Source: DSDM Consortium, underlying principles

The DSDM Framework Phases

The framework defines phases that apply to the process in the case of a new system development or the change of business processes. The core project process is preceded by the Pre-Project phase and end with the Post-Project phase:

  • Pre-Project
  • Feasibility Study
  • Business Study
  • Functional Model Iteration
  • Design and Build Iteration
  • Implementation
  • Post-Project

Within DSDM the phases “Feasibility Study” and “Business Study” are firstly done in sequence. Because these phases set the foundation rules for the rest of the iterative and incremental development in the remaining phases, they must be before any other work is done in a project. With these first two core phases done, the other three phases can overlap and be merged in any other order appropriate to the project. When the project solution is delivered the project team will hand over the solution to the Post-Project phase. This final phase includes the process of maintaining the solutions operations and monitoring the performance to make sure that the business requirements have been met.

Figure 1. DSDM Phases
Dsdm lifecycle.gif

Within each phase the goal is to produce a minimum set of products. These products are often specific documentation with a defined criteria and purpose. As a result the achievement of every purpose can be assessed. The way these products are produced and what the content will be, is left open for the concerning organization or project to determine. Table 1 provides an overview of the activity and products that apply to the DSDM phases.

Table 1. DSDM activity and products

Phase Activity Products
Pre-Project Ensures that only the right projects are started and setup correctly. Performs any initial project planning for the Feasibility Study. No formally defined DSDM products
Feasibility Study Determines if DSDM is the right approach for the project. Defines the problem to be addressed, the costs and technical feasibility.
  • Feasibility Report, possibly supported by a Feasibility Prototype
  • Outline Plan
  • Risk Log
Business Study Focuses on the business processes affected as well as their information needs. Deliverable: Business Area Definition.
  • Business Area Definition
  • Prioritised Requirements List
  • System Architecture Definition
  • Development Plan
  • Updated Risk Log
Functional Model Iteration Refines the business-based aspects of the system building on the high-level processing and information requirements identified in the Business Study.
  • Functional Model (including Functional Prototypes)
  • Functional Model Review Records
  • Non-Functional Requirements List
  • Timebox Plans
  • Implementation Plan
  • Risk Log
Design and Build Iteration The system is engineered to a sufficiently high standard to be safely placed in the hands of the users. Deliverable: the Tested System.
  • Timebox Plans
  • Design Prototypes (intermediate products)
  • Design Prototyping Review Records
  • Tested System, including all design documentation, etc. together with supporting Test Records
Implementation Involves training the users and transferring the system from the development environment to the operational environment. Deliverable: Increment Review Document
  • User Documentation
  • Delivered System, together with supporting build, delivery and acceptance records
  • Trained User Population
  • Increment Review Document
Post-Project Maintenance

Post-Implementation Review Report

For further reading visit: URL:

Feature Driven Development


Feature Driven Development(FDD) is a model driven process of short iterations (two weeks). An overall model is established at the beginning of a project after which the project continues with a series of design by feature/build by feature iterations. A feature is a small and “useful in the eyes of the client” result.


FDD consists of five processes, three of which are per project, the other two being per feature. FDD.jpg

Develop an Overall Model

This process involves the domain experts, chief architect and chief programmers. The main goal here is to establish the overall shape of the system. Classes and their inter relationships are defined.

Build Feature List

This process involves the domain experts, chief architect and chief programmers. Its goal is to produce fine grained feature list. Essentially the model developed in process 1 is functionally decomposed into subject areas. Each subject area contains business activities and each business activity can be broken into a number of business steps. The categorisation of these steps forms the feature list.

Plan By Feature

The feature sets are sequenced into a high level plan and assigned to chief programmers.

Design by Feature

A small set of features are designed by a feature team. Each feature is represented by a sequence diagram in UML. This diagram is the design deliverable and is peer reviewed by the feature team against the requirements.

Build By Feature

The code for each feature is written by the members of the team who own the business classes affected by the functionality of that feature. The completed code is peer reviewed. Once the code has passed the review and been unit tested it is marked for inclusion in the system build.

Best Practices

FDD is built around a set of eight best practices each of which complements the other. The practices are not exclusive to FDD, but are used in a unique combination in FDD.

Domain Object Modeling


Developing by Feature


Individual Class (Code) Ownership


Feature Teams




Regular Builds


Configuration Management


Reporting/Visibility of Results



For each feature of the feature list there are six discrete milestones. Three of which belong to the Design by Feature process; Domain Walkthrough, Design, Design Inspection; and three which belong to the Build by Feature process; Code, Code Inspection, Promote to Build.

Domain Walkthrough




Design Inspection




Code Inspection


Promote to Build


Lean Development

Although Robert Charette originally defined the principles of Lean Development, he has not been it's primary proponent nor has he contributed much to the body of work relating to Lean Software Development. Instead, Lean Software Development has mainly been popularized through the work of Mary and Tom Poppendieck. They describe in detail how to apply the principles of lean production to the software development process. They specify a set of seven principles and 22 tools to help realise those principles. (Charette lists twelve principles [3])

Lean Production

Since Lean Development derives it's principles and practices from Lean Production it is important to have an understanding of Lean Production (sometimes referred to as Lean Manufacturing).

The concepts and tools of Lean Production were laid out in Womack, Jones and Roos book "The machine that changed the World: The Story of Lean Production". Lean Production draws on several production processes including Toyota Production System (TPS), just-in-time manufacturing and inventory management as well as adding it's own ideas to the mix. One of the key ideas in Lean Production - eliminate waste - is drawn from TPS. TPS has an extensive definition for waste, breaking it down into seven categories and suggesting how to deal with each one. Lean Software development then is the application of the principles of Lean Production to the software process.

Benefits of Lean Development

Lean Development allows companies to manage their risk and turn that risk into an opportunity. Robert Charette refers to this as "risk entrepreneurship" [Agile Software Development Ecosystems, Highsmith, 2002][1]. By proactively dealing with risk and adapting to changes in the market place brought about by circumstances and competitors a company can gain a competitive advantage. Lean Development enables software systems to adapt to this change rapidly, something that software systems are generally known for.

Principles of Lean Development

There are seven principles of lean development (though sometimes twelve are listed). Also, the naming of some of the principles has changed with time.

In Lean Software Development : An Agile Toolkit [4] the following principles are listed

  • Eliminate Waste
  • Amplify Learning (Create Knowledge)
  • Decide as Late as Possible (Defer Commitment)
  • Deliver as Fast as Possible (Deliver Fast)
  • Empower Teams (Respect People)
  • Build Integrity In (Build Quality In)
  • See the Whole (Optimise the Whole)

(Titles in brackets are apparently newer names used in Implementing Lean Software Development [5])

Eliminate Waste - The Core Principle

In TPS, Taiichi Ohno analysed the concept of waste in great detail and categorised different types of waste, and ways of addressing them. In explaining Ohnos concept of waste, Poppendieck uses the phrase "anything with does not create value for a customer is waste" [ASDE, Highsmith] and when applied to software development this translates to implementation of features that are not core requirements, poor or missing requirements, administrative overhead and bureaucracy. Poppendieck maps Ohnos concepts of waste to software as follows:

Mapping Waste in Manufacturing to Software Development
Manufacturing Software Development !
In-Process Inventory Partially Done Work
Over-production Extra features
Extra Processing Re-learning
Transportation Handoff
Motion Task Switching
Waiting Delays
Defects Defects

Tools: Seeing Waste, Value Stream Mapping

Amplify Learning

Take advantage of the short iterations and feedback from customers to learn how to improve the product and the process. Present a choice of solutions as working prototypes rather than explore possible solutions. This way you limit choice as well as get a head start on the final solution.

Tools: Feedback, Iteration, Synchronization, Set-Based Development

Decide as Late as Possible (Defer Commitment)

In traditional software development processes, important decisions are made far in advance of implementation. Any mistakes made at the distant planning stage are amplified in implementation and their effect on the whole process. By deferring decisions to as late as possible the implications of mistakes are limited and you also can deal with change more easily.

Tools: Options Thinking, The Last Responsible Moment Making Decisions

Deliver as Fast as Possible (Deliver Fast)

Business success is often achieved by responding rapidly to change. A customer who needs a system for commercial applications wants that system as fast as possible. The faster you can deliver that system the greater the value to the customer and the greater the long term benefit to you. The concepts of this principle are related to the theory of Just-In-Time delivery.

Tools: Pull Systems, Cost of Delay, Queuing Theory

Empower Teams (Respect People)

"An organization that respects software developers as professionals will expect them to design their own jobs with proper training, coaching, and assistance. It will expect them to improve continually the way they do their work as part of a learning process. Finally, it will give them the time and equipment necessary to do their jobs well. In a lean organization, the people who add value are the centre of organizational energy. Frontline workers have process design authority and decision-making responsibility; they are the focus of resources, information and training." [Chapter 5]

Instead of treating software developers as cogs in a wheel, respecting their needs and abilities will give them a sense of responsibility and increase their motivation, and ultimately benefits everyone. Tools: Self-Determination, Motivation, Leadership, Expertise

Build Integrity In (Build Quality In)

Perceived Integrity - the ability of the software to "delight" the customer by functioning well, and Conceptual Integrity - a sense of cohesiveness and integrity between different parts of the system are key demand of customers. Refactoring and Testing ensure that these goals are achieved.

Tools: Perceived Integrity, Conceptual Integrity, Refactoring, Testing

See the Whole (Optimize the Whole)

By choosing the right measures and interpreting the measures correctly we can find the root cause and source of defects in systems. The assumptions are that defects are caused by individuals when in fact they are the caused by the processes and procedures in the system. Also, most projects are made up of many sub-teams, vendors and contractors. A shared agreement and understanding of goals is of huge benefit for the project and company in the long term.

Tools: Measurements, Contracts

Extreme Programming

Extreme Programming (XP) was developed by Kent Beck in mid 90’s. As projects reduced in size and became more dynamic with rapidly changing requirements, there was a need for quick project development life-cycle. Since 70’s widely used approach had linear structure characteristic known as “Waterfall Model”, project scope was planned out at the beginning of the project life-cycle, in which changing requirements in the middle of the development, made it very costly. Frequently changing requirements by customers required for more agile approach.

XP is known as a methodology of Agile development. This is used in small, collocated project teams up to 10 members, more is probable. Development is flexible and lightweight. XP is based on twelve practices and four groups - collaboration, feedback, revision and respect.

  • Collaboration – active participation of all stakeholders of the project in which customer is a part of the development team. Project starts with creating simple design and ‘hands on’ coding. Test Driven Development approach is applied by adding new functionality to the code. Focus is on today tasks and requirements rather than looking at long-term. Regular meetings are held and frequent verbal communication between programmer team is practiced. Feedback acquired immediately through iterative structure of the development.
  • Feedback – feedback is effective if it is instantaneous. System feedback is achieved through Unit Testing. Unit Tests are created for the software throughout development phase on which complete software is built. Any changes to the requirements is done through collaboration process with customers who give the feedback to the existing model, changes are taken into account and presented as new requirements. XP exercise ‘Use Case’ diagrams and ‘Story boards’ through which requirements are presented.
  • Revision – XP development focuses on current tasks and problems. This makes written code often unstructured as it should be. Since the structure of the code is not planned out at the beginning of the project, regular refactoring is recommended and even compulsory for further development and maintenance. This takes courage to redesign the system and even sometimes discard completely parts of the code to implement a new functionality.
  • Respect – XP practices programming in peers. Programmers split tasks, one is typing code (person is known as a ‘driver’), while the other programmer is following the code and working on an algorithm to solve the problem. Roles change in time. This is a good practice because every decision of the team matters which leads to the team loyalty.

Code is the most important part of XP, complete documentation is considered as a waste of assets. Simple code and design form the basis; this is understandable to programmers who join the team at the later stages. Peer programming complements it – what is obvious for one, is not for another, following the decisions is easy to understand the thought of the colleague.

There are twelve core practices in XP stated as a standard:

  1. Coding Standards – mutually agreed standard by the team throughout the development on language used, vendors, rules and format.
  2. Collective Code Ownership – every programmer in the team has a right on the code. Suggested to use repositories to store the code, every programmer has access rights.
  3. Simple Design – problem should be tackled and the simplest outcome should be applied.
  4. System Metaphor – classes and functions should do what they say on the ‘label’, naming should be given in mutual understanding for the functionality.
  5. Pair Programming - two programmers work on one task, one is typing and following the lead of the other who focuses on the functionality and algorithms to solve the problems, also reviewing written code.
  6. Planning Game – regular project meetings are held and are divided into release planning in which customers request necessary changes and new functionality, and iteration panning which is done after completing the iteration by presenting functional software.
  7. Test Driven Development – creation of a test case following by writing a code that satisfies the desired test result.
  8. Whole Team – all project stakeholders are actively involved and work together.
  9. Continuous Integration - team members should work on the latest release of the software, some team members who work on the delayed parts should integrate the code into the main release repositories as soon as possible.
  10. Refactoring – refactoring should be performed on a regular basis.
  11. Small Releases – functional releases should be built iteratively that form the project. These visible modules encourage customers, also used for evaluation purposes.
  12. Sustainable Pace – also known as a 40 hour week. Well being of the team is important, burnt out programmers do not perform at their best. Productivity is achieved by these means.


Basic concept of Scrum

Scrum is a flexible process control for complex software project. It uses iterative and incremental practices on the software product. It is raised in 1995 by Advanced Development Methodologies,Inc, and has become popular after the Agile Alliance is created since 2001.

The hypothesis of Scrum is, at the begin of the product development, we could not definite the product’s final requirements. During the development duration, we need creation, develop, and get experience from mistakes, so there is no fixed procedure we can warrant the success. It seems like the Rugby football team, they have highest priority goal, familiar with the development process, have high self-control authority, and cooperate tightly, to ensure the develop team is going ahead to achieve their goals on every phase, every day.

One iteration lasts 30 days, it starts from the beginning of the new product’s requirements. The develop team must implement all functional parts which they select from the beginning. They have daily meeting, spend 15 minutes, to check the progress of every team number, to know what difficulties they met and try to resolve them as soon as possible.

Scrum’s advantage/ disadvantage

The most advantage of Scrum would be its changeability. Scrum can take action when something changes, e.g. requirement change from marketing.

Because of the changeable requirements using Scrum development process, it makes a great challenge to feature testing team especially when they are under developing test case. Because of unfixed and often changed requirements in every unit Sprint, testers often need to re-work on develop test case in a short time.

Scrum’s framework

Glossary of Scrum terms

(Material in this section is based on information available at Scrum Alliance)

Backlog: Backlog is the requirements for a system, expressed as a prioritized list of product backlog Items. These included both functional and non-functional customer requirements, as well as technical team-generated requirements.

Sprint: An iteration of work during which an increment of product functionality is implemented.

Sprint backlog: Defines the work for a sprint, represented by the set of tasks that must be completed to realize the sprint's goals, and selected set of product backlog items.

ScrumMaster: The ScrumMaster is a facilitator for the team and product owner.

Time-box: The duration time of daily meeting.

Sprint planning meeting: The Sprint planning meeting is a negotiation between the team and the product owner about what the team will do during the next sprint.

Daily Scrum meeting: A fifteen-minute daily meeting for each team member to answer three questions:

  1. "What have I done since the last Scrum meeting?"
  2. "What will I do before the next Scrum meeting?"
  3. "What prevents me from performing my work as efficiently as possible?"

The ScrumMaster ensures that participants call sidebar meetings for any discussions that go too far outside these constraints. The Scrum literature recommends that this meeting take place first thing in the morning, as soon as all team members arrive.

Sprint review meeting: The team shows their achievement to their product owner during this sprint. It lasts 4 hours.

Sprint retrospective meeting: The sprint retrospective meeting is held at the end of every sprint after the sprint review meeting. It lasts 3 hours.

Introduction of Scrum process
  1. Divide product backlog into Sprint backlogs, ensure Sprint backlogs can be fulfilled based on the current resource.
  2. Hold a Sprint planning meeting, to make sure the works should be finished in this Sprint. Assign work to every team number with priority.
  3. Start the Sprint development lifecycle, hold the daily Scrum meeting.
  4. After the whole Sprint lifecycle ends, show their achievement to their product owner in the Sprint review meeting.
  5. Hold the Sprint retrospective meeting at last, the team and ScrumMaster meet to discuss what went well and what to improve in the next sprint.
  6. The next Sprint starts.
Related Material

Ken Schwaber provides an informative and entertaining overview of SCRUM in this Google Tech Talk

Applying Agile

Choosing an Agile Methodology

The methodology chosen needs to be on a level that the company is willing to work with. Different levels have different requirements such as:

  • Planning
  • Design
  • Programming practices

Extreme Programming (XP) is far more detailed than the other methodologies and defines programming practices, whereas the other methodologies are mainly involved with the project management and planning issues

The agile methodologies have different degrees of support for the different parts of the software development project's life-cycle.

The methodology to choose depends on:

  • The project size
  • The effort involved
  • Is the project mission or life critical
  • What is the company culture like
  • What build environments are in place(build everything before test allowed, etc)
  • How many senior developers in the team
  • What size is the development team
  • Are requirements going to change often (e.g. Nuclear Power Plant vs Company Website)
  • Order vs Chaos

All the above will determine firstly whether or not to take work with an Agile Methodology and secondly, which agile methodology to choose.

Tool Support for Agile Methodologies

While only a few tools are exclusively applicable to Agile, many tools have been developed to meet the needs of Agile teams and have gone on to find wider audiences. Many of the tools listed here are either specific to Java, or were developed for and with Java but now support other languages. This is mainly due to the popularity of Java during the time that Agile methods were widely adapted. Many tools exist for other languages also.

Scheduling and project management
  • XPlanner - XPlanner is a web-based project management tool for XP projects. XPlanner is probably the most widely used open source project management tool and can be used on other Agile projects, not just XP.
  • AgileTrack - A commercial project management tool for Agile projects
  • TargetProcess TargetProcess is a commercial project management tool for agile projects
Version Control Systems

Version control is a central configuration management activity in any Agile project. Code is written frequently and checked in every day at least. A reliable version control system is central to any agile project. There are dozens of version controls systems to choose from, only the most widely used are listed below, but even that doesn't approach a complete list

  • cvs - A client server system, until recently the dominant VCS system in use. Still very popular.
  • subversion - Seen as a successor to CVS and addresses many of the shortcomings of CVS
  • mercurial - A nascent distributed version control system
  • clearcase - A commercial client server source control system owned by IBM. See here for details of how it can be used in Agile projects.
  • perforce - A popular commercial VCS, used by Google amongst others.
  • Visual SourceSafe A widely used version control system from Microsoft
Build and Continuous Integration
  • CruiseControl - CruiseControl is an open source continuous build and integration tool.
  • buildbot - Another open source automated build and test tool

Unit Testing

Unit Testing is one of the principles of XP and other Agile methodologies and a whole ecosystem of unit testing frameworks has sprung up around Unit tests test code functionality at the smallest possible level of granularity. In object oriented programming this is usually at the level of a single method. There are simply too many unit testing frameworks to list here however the most widely known is probably JUnit.

Mock Objects Mock Objects and unit testing are intrinsically linked. Mock object allow you to create simulations of dynamic complex objects so that dependent code can be reliably tested without having to manage the complex objects state and complexity. There are many mock objects libraries for each language, the list below is a brief selection of what's available:

Directions for Agile

Criticisms of Agile

Agile technique works well in collocated environments in relatively small developer teams four to ten people. Unlike ‘Waterfall’ model, ‘Agile’ development has iterative, burst characteristic, with a very little documentation and no set final plan of the project. This would not be suited for security critical, projects where dominates reliability.

If team is not collocated, weekly project meetings with customers or any other stakeholders impact the success of ‘Agile’ development. Collaboration is very important. ‘Agile’ principles propose face-to-face meetings; this is possible when the team members are collocated in the same premises. Significant setback is if members work from remote locations.

Extreme Programming practice is that refactoring should be performed regularly. Recoding existing code or changing the structure of the system, even discarding and writing brand new code, this is just not the most efficient way of using resources and assets. This could be prevented if the architecture of the system would be planned out at the beginning of the coding.

Most of the time programmer teams are formed by inexperienced engineers. ‘Agile’ development works well with experienced developers with a state-of-art coding. Supposing that less changes of the code should be done and the structure of the code need to be altered at the refactoring phase if the code would be written at their best practice.

Current Status and Future Directions

‘Agile’ development is a very dynamic and elastic technique that could be applied in a variety of ways to different kinds of projects. Radically evolving technology creates a need for flexible ways of dealing with a new set of environments and rules. There is much scepticism in ‘Agile’ development, however the technique works well for many and they don’t want to discard it or apply heavy-weight development style instead. The set of ‘Agile’ tools and processes provided may be improved. Saying that current ‘Agile’ method is not final and it will be most definitely enhanced.


  1. 1.0 1.1 Highsmith, J., Agile Software Development Ecosystems, 2002
  2. Adaptive Software Development: A Collaborative Approach to Managing Complex Systems. Highsmith, J., 1999
  3. principles of Lean Development last visited 15 April 2008
  4. | Lean Software Development : An Agile Toolkit, Poppendieck & Poppendieck, 2003
  5. | Implementing Lean Software Development From Concept to Cash, Poppendieck & Poppendieck, 2007

Got something to say? Make a comment.
Your name
Your email address