PEARL XXIV: Incorporate Cloud computing to enable Agile S/w Development


Organizations are changing IT architecture to incorporate cloud computing resources that enable Agile and empower software development teams with self-service.

Agile software development is winning the hearts and minds of developers and testers in leading enterprise organizations. In the “State of Agile Development” 2011 study, VersionOne highlights that 80% of the respondents from 6,042 companies surveyed have adopted Agile development practices within their organization. Nearly 50% of respondents had between two and five Agile projects underway, and one third said their organization is running 11 or more. There is a business reason for this momentum. The Agile development model enables software teams to produce higher quality software that is more in-sync with customer needs and delivers release cycles faster and more cost effectively than ever before.
Unfortunately, most software teams that adopt Agile development struggle to achieve its full potential due to legacy IT challenges, especially in the enterprise. While the Agile model accelerates the software development process, many teams find that their IT environments are not optimized to support the full potential of their Agile development release cycles. These legacy environments are often too slow, inflexible, and inadequate for Agile development processes.

Consider this: Typical provisioning time for an enterprise-grade development environment can take, at a minimum, from several weeks to several months. Most Agile release cycles span four to six weeks at most. Not only does a four week provisioning delay result in sub-optimal outcomes, but once created, these static environments are also difficult to change and cannot support the rapid iteration required for Agile development.
Essentially, Agile development methodologies require Agile infrastructure for optimal efficiency.

Leading companies are changing the way their IT teams equip and support software development teams by integrating fast, dynamic, flexible, and easily shareable cloud-based environments that are available on-demand. They are changing IT architecture to incorporate cloud computing resources that enable Agile and empower software development teams with self-service. By integrating cloud-based services into the overall IT architecture strategy, software development teams are better enabled to create, change, and scale complex computing environments as often as needed. And at the same time, IT is able to retain the full visibility and control required for security and operational governance over these environments.

Enterprises that implement Agile IT architecture to support Agile development have seen provisioning of IT resources reduced from weeks to minutes, accelerating software release cycles dramatically. For example, Cushman & Wakefield, the world’s largest real estate services firm, moved its application development and test environments to the cloud. In fewer than four months, Cushman & Wakefield development teams saw application release cycles shorten and become more efficient—and they doubled the number of projects they could complete in a given period of time.

When developers adopt the Agile model, software development will undergo rapid iterations before being deployed to production. Agile development teams must have the flexibility to develop and test each iteration of code as they converge on the final version of product. Often times, developers must also test their code across multiple operating systems, network configurations, and browsers for each release. Most enterprise applications require a complex multi-tier, multinetwork architecture that includes web servers, application servers, databases, firewalls, and load balancers. The ability to rapidly create, change, and test against these complex computing configurations is critical for Agile development speed and success. Unfortunately, most Agile teams do not have access to nimble, self-service environments that can support the high rate of change demanded by rapid iteration. Instead, progress is impeded by a variety of roadblocks inherent to legacy IT environments that are too rigid, costly, or static.

Specific road blocks may include:
Slow to provision/static development and testing environments – Developers and test engineers often must rely on IT teams for the ordering, set-up, and access to development and test environments. Once provisioned, these environments tend to be static.
Under powered infrastructure – The provisioning of environments typically involves older infrastructure that performs poorly and does not scale well. Often times the development and test lab is overloaded with too many overlapping projects.
Lack of test coverage – In order to reproduce production scenarios or customer-specific issues, development and test teams need to be able to change operating systems, browsers, and databases, or infrastructure parameters such CPU, memory, disk size, and network configuration. Existing data center architectures built for predictable workloads lack the agility or configurability to support the dynamic requirements to cover the full test matrix with each pass.

Inability to capture and reproduce complex software bugs – When developers and test engineers encounter complex bugs, they need to be able to save the memory, disk, and network settings across multiple machines and networks, so that the development team can properly diagnose the issue, while the QA team works in parallel on additional testing. Most development and test labs do not have the capacity or the flexibility to parallelize the capture of bugs with full environmental data and continue to execute on the full test matrix.

Limited sharing and collaboration – Most software development is team-oriented, and a lack of collaboration creates silos across teams and slows the release process. The challenge of collaboration and sharing is further compounded when the development, testing, and operations teams are geographically distributed with separate labs. Even more challenging is the case where constituents outside the company require access—examples include customers for user acceptance testing or contractors who perform certain test functions. IT teams using only in-house infrastructure often rely on scheduling specific shifts and resources for specific projects, and are typically unable to maintain the level of access or the pace of change required to support the multiple teams.

In short, legacy IT environments are simply not designed to handle the demands of today’s Agile software development cycles and complex application requirements.
Development teams are being pushed to create quality applications faster and at lower cost than ever before. Many are rightfully choosing the Agile model so they can focus on customer satisfaction, initiate rapid development, and build a culture of collaboration. But how can these teams succeed if they don’t have the IT environment required to support their goals?

New IT Requirements for Agile Development Teams
As discussed earlier, the goal of Agile development is to shift from a long and inflexible development process to a much shorter, more collaborative process directed toward shipping software more frequently.
To be most successful, Agile development teams will require the following from their development and test lab infrastructure:
Self-service provisioning – Software development teams need to be able to create, change, deploy, copy, re-create, delete, and change development and test lab environments on demand, without IT assistance.
On-demand scalability – Software development teams need to scale environments up and down easily.
Alibrary of virtual data center(VDC)templates – Software development teams need to create a consistent version of the current release stack, prior release stacks, and customer-specific variations as templates. Within a few minutes after a hot fix issue is reported, teams should be able to create a new environment that matches the appropriate release scenario to reproduce the issue, fix it, test it, and deploy the new code.
Complex bug capture and reproduction – QA and support teams need to easily create, snapshot, and clone complex, multi-tier environments when a complicated bug is identified. They should be able to capture and quickly recreate complex environments, including all memory and state information, so that the relevant development team resources can work to identify root cause and develop a fix, while the QA team moves forward with additional testing.
Collaboration – Developers need to share copies of their lab environments with test engineers, other development engineers, and users. Teams should be able to organize their work in projects, invite specific project members to participate, and assign specific roles or access points to each participant based on roles (user, manager, database engineer, etc.) or status (employee, contractor, etc.).
Together, these requirements enable Agile software development teams to optimize the software development model for faster, more collaborative release cycles. When the development environment they use is as Agile as their development process, they can focus on specific customer problems, quickly develop solutions, iterate with customers, and ship higher quality software faster.

Create Agile IT Using the Cloud
A typical procurement cycle requires 6 to 8 weeks to specify a development and test environment,; procure server, networking and storage hardware; and rack, configure, and test everything. That is a time-consuming, and costly process that does not match the demands of the Agile development cycle. Leveraging cloud computing resources can provide more convenient, affordable, and on-demand computing environments tailored to the needs of software development teams.
By leveraging cloud computing resources as part of an overall IT strategy, enterprises can effectively extend their existing data centers and manage the cloud as an extension of their existing environment.

By utilizing cloud computing resources for development and test environments (rather than owning and maintaining hardware), IT can provide a higher degree of self-service for end users (developers and testers), and more configurability and scalability to support Agile requirements with much lower operational costs. Cloud-enabled solutions for development and test workloads will integrate the best characteristics of virtualization, cloud automation, software as a service (SaaS), and infrastructure as a service (IaaS) to provide a complete application lifecycle solution.
This solution-centric approach enables:

Developer and tester self-service – Developers and testers can create, replicate, change, or delete entire software development and test stacks and deploy application builds with just a few mouse clicks. A cloud-based solution can better enable teams to implement continuous integration, so they can quickly execute unit and functional tests and understand how their new code interacts with the rest of the application stack.
Scalability and configurability – Developers and testers can create new release stacks ondemand, in a repeatable and dependable fashion, as they go through the peaks and troughs of release cycles.
Broader test coverage – The cloud can enable developers and test engineers, virtually unlimited resources as compared to in-house physical lab infrastructure, which typically struggles to keep up as test matrices grow and release cycles compress. In the cloud, development teams can easily run multiple test passes in parallel to test various OS/DB/browser combinations, as the cloud enables VDC templates to scale up or down as needed. A rich library of VDC templates makes it easy to select from a broad range environments that are ready to be provisioned with a mouse click.
Rapid bug capture and reproduction – In the cloud, test teams can snapshot complex bug
environments (creating VDC templates), rapidly create clones of these templates, and
continue to run tests unblocked by the saved snapshot in the development team queue. Using templates in a cloud-based environment enables testers to capture the whole environment without having to write down reproduction steps. Developers can then re-use those same environments to review the bug and quickly develop patches.
Collaboration and parallel work streams – More than ever, application development teams are geographically dispersed, providing significant challenges to cross-team collaboration. With cloud-based solutions, developers can easily collaborate and share access to environments with other developers, testers, and offshore or contract resources by creating release-specific projects, and providing role-based access as appropriate

IT Requirements for Agile Cloud
Just as development and test teams demand that cloud infrastructure support their Agile
development needs, IT professionals also require that cloud-based labs meet requirements as they relate to managing budget and user access. Specifically, IT’s need for full visibility and control of cloud environments requires that they can:

  • Set up development and test environment templates that are IT policy compliant.
  • Create users, roles, access control lists, and set permissions.
  • Establish a hybrid cloud architecture to securely connect the cloud environment to existing data center infrastructure.
  • Assign group, project, and individual-level quotas for machines, storage, and networks.
  • Track usage by month, by user, by project, and implement chargebacks if needed.
  • Audit and ensure compliance policies are followed.

IT teams that adopt a cloud-enabled Agile IT solution can:

  • Increase business agility for development teams.
  • Reduce time to market for new applications.
  • Ensure development ships better software faster.
  • Boost productivity across development/test and IT teams.
  • Lower fixed and variable costs.

Agile IT empowers development teams to achieve the full potential of the Agile model. In addition, IT will be able to retain full visibility and control over cloud environments and reduce operating costs.

Five Best Practices for Creating Cloud-Enabled Software Development
Modern enterprise organizations are leveraging cloud computing to enable IT to be Agile and to power Agile software development teams. Companies that have successfully implemented cloud-enabled software development have subscribed to the following five best practices when creating Agile infrastructure:
1 Don’tchange the Agile process to fit legacy infrastructure –  change your IT strategy to be more Agile. The very essence of the Agile model is trust and delegation, and yet some IT organizations still struggle to operate with these principles in mind. They claim to support the Agile development model, but require developers to change their model to fit the existing IT processes. Successful IT organizations are flexible and work with software development teams to create an IT cloud strategy that is self-service oriented, while still providing visibility and control for IT.
2 Empower end users with self-service environments. – Enable your developers and testers by creating VDC templates specific to each development project, and providing IT services that developers can consume easily and without intervention.
3 Expect rapid changes and fast iteration to be the new normal. –  Be ready to architect your cloud infrastructure to be more configurable, scalable, and flexible. An Agile development model is inherently fast paced, so be willing to accommodate change and quickly adapt to what works and what does not. Expect rapid iteration and design your cloud implementation accordingly.
4 Collaboration is at the heart of Agile development – Customers, line-of-business users, QA engineers, contractors, and support professionals should be able to collaborate during multiple phases of the development cycle. All of these stakeholders are expected to operate on the application based on the specific roles they play on the team. If the environment cannot be easily replicated and shared across teams, then the developers and testers will struggle to get the full benefits of Agile.
5 Maintain full visibility and control over IT operations. – Implementing Agile cloud infrastructure does not eliminate security and governance needs. IT organizations need to set security policies and enforce them through granular access control. They need to have full visibility into quota usage, resource management, and compliance.

Agile Cloud computing Infrastructure strategy at Health and Human Services(US Gov)

Agile Cloud computing Infrastructure strategy at Health and Human Services(US Gov)


Extending  existing IT architecture to encompass a cloud-enabled development strategy will ultimately serve your Agile development team better. The process does not have to be difficult or challenging, and in most cases, complex computing environments can be created in the cloud in just a few minutes or hours versus days or weeks. Look for enterprise-grade cloud computing service providers that can deliver on the following five key capabilities to enable  applications development teams:

1 Intuitive self-service
2 Fast productivity
3 Flexible,complex computing environments
4 Collaborative platformsforteams
5 Full visibility and controlforIT

Although it is possible to continue using on-premises infrastructure, Agile development process will be much more effective when IT infrastructure and service delivery model is Agile. Given the potential consequences of operating with dated hardware, poor collaboration, and slow provisioning of IT resources, organizations can increase business agility by embracing cloud computing for software development and testing

Developers need feedback. In Agile, near-immediate feedback is essential, and it’s generated through daily commits, continuous integration, testing, and through stakeholder input.

Agile development values rapid, continuous feedback—through analytics, and through direction from stakeholders and product owners. First, through continuous introspection, on a daily basis the technical team members can see if their code merges properly with other developers’ code, or find duplications or efficiencies in code. Next, with continuous integration and regular deployments of code to development or testing servers (daily, every few days, or weekly), product owners and stakeholders can give regular feedback
on the development by reviewing iterations and identifying necessary modifications—before it’s too late. This ensures that the developers are building what the project owners want, versus finding out months later that it’s off track.
The key to Agile is to reduce this overall feedback cycle—to shorten it. The best way to do reduce the cycle is to automate each piece of feedback functionality. Automation of code scanning and integration, testing, deployment, and all other continuous introspection activities will not only shorten cycles and speed up development, but it will also make the

Agile Methodology using cloud computing services

Agile Methodology using cloud computing services

Agile Automation using Cloud Computing

Agile development process scalable. All automated introspection functions are easily and readily available across the enterprise.
The cloud can automate feedback in all stages of a project. Here are some of the ways cloud automation can support fast feedback and provide other benefits in Development, Building, Testing, and Deployment.
Automated Development in the Cloud: Continuous integration of code must begin with proper source control management to establish version control. For successful Agile development, organizations can rely on the cloud to provide distributed and easily accessible source code management to any number of developers—in less than five minutes. The cloud enables secure, 99.9% up-time availability to source code. And organizations can quickly scale up—moving from a few developers accessing the tool up to 500 or even 1000 developers without infrastructure concerns.
Automated Build in the Cloud: Organizations building with Agile in the cloud can expedite their work, and reduce their build costs. First, developers can take their existing build images residing on multiple platforms and use virtualization to have those images pre-built, and then accessed through the cloud. This expedites provisioning of existing build images. Second, the cloud enables utility pricing, so that fees are only charged for the specific services and actual build time used, versus the cost of maintaining a dedicated server.
Automated Testing in the Cloud: Testing in the cloud provides significant advances in speed and agility. Organizations can quickly run multi-platform testing using virtual images. In addition, they can run unit tests in parallel through cloud machines; so rather than running consecutive tests on one machine, multiple tests can be simultaneously run on multiple cloud machines. This also results in cost savings by paying only for actual test time used, and not the expense of maintaining a dedicated server or testing infrastructure.

Automated Production Deployment in the Cloud: The cloud provides access to production environments in minutes, and, in some cases, push-button control to automate deployment: Leading Agile enterprise-ready cloud solutions empower organizations to export code to production in one click. Consider how important that is to supporting Agile development.
In Agile, to reduce the feedback cycle, automating production deployment as much as possible is a top priority. Whether deployment is to a test machine or a demo machine staging production, fast and frequent deployment is how the technical team can receive critical feedback from the business owners and keep the project moving quickly in the right direction. Therefore, push button deployment should be made available to all developers and the Scrum Master, as opposed to IT or an operations team. Remember, fast feedback is king in Agile. And IT requests can lengthen the feedback cycle. To counteract security management concerns regarding widespread system access, sophisticated cloud solutions for Agile incorporate pre-configured, password-ready access to the deployment system.

PEARL X : Behavior Driven Development

PEARL X : Behavior Driven Development provides stakeholder value through collaboration throughout the entire project

Behavior-driven development was developed by Dan North as a response to the issues encountered teaching test-driven development:

  • Where to start in the process
  • What to test and what not to test
  • How much to test in one go
  • What to call the tests
  • How to understand why a test fails
At the heart of BDD is a rethinking the approach to the unit testing and acceptance testing that North came up with while dealing with these issues. For example, he proposes that unit test names be whole sentences starting with the word “should” and should be written in order of business value

At its core, behavior-driven development is a specialized version of test-driven development which focuses on behavioral specification of software units.

Test-driven development is a software development methodology which essentially states that for each unit of software, a software developer must:

  • define a test set for the unit first;
  • then implement the unit;
  • finally verify that the implementation of the unit makes the tests succeed.

This definition is rather non-specific in that it allows tests in terms of high-level software requirements, low-level technical details or anything in between. The original developer of BDD (Dan North) came up with the notion of BDD because he was dissatisfied with the lack of any specification within TDD of what should be tested and how. One way of looking at BDD therefore, is that it is a continued development of TDD which makes more specific choices than TDD.

Behavior Driven Development

Behavior Driven Development

Behavior-driven development specifies that tests of any unit of software should be specified in terms of the desired behavior of the unit. Borrowing from agile software development the “desired behavior” in this case consists of the requirements set by the business — that is, the desired behavior that has business value for whatever entity commissioned the software unit under construction.  Within BDD practice, this is referred to as BDD being an “outside-in” activity.

BDD practices

The practices of BDD include:

  • Establishing the goals of different stakeholders required for a vision to be implemented
  • Drawing out features which will achieve those goals using feature injection
  • Involving stakeholders in the implementation process through outside–in software development
  • Using examples to describe the behavior of the application, or of units of code
  • Automating those examples to provide quick feedback and regression testing
  • Using ‘should’ when describing the behavior of software to help clarify responsibility and allow the software’s functionality to be questioned
  • Using ‘ensure’ when describing responsibilities of software to differentiate outcomes in the scope of the code in question from side-effects of other elements of code.
  • Using mocks to stand-in for collaborating modules of code which have not yet been written

Domain-Driven Design (DDD) is a collection of principles and patterns that help developers craft elegant object systems. Properly applied it can lead to software abstractions called domain models. These models encapsulate complex business logic, closing the gap between business reality and code.


BDD is driven by business value; that is, the benefit to the business which accrues once the application is in production. The only way in which this benefit can be realized is through the user interface(s) to the application, usually (but not always) a GUI.

In the same way, each piece of code, starting with the UI, can be considered a stakeholder of the other modules of code which it uses. Each element of code provides some aspect of behavior which, in collaboration with the other elements, provides the application behavior.

The first piece of production code that BDD developers implement is the UI. Developers can then benefit from quick feedback as to whether the UI looks and behaves appropriately. Through code, and using principles of good design and refactoring, developers discover collaborators of the UI, and of every unit of code thereafter. This helps them adhere to the principle of YAGNI, since each piece of production code is required either by the business, or by another piece of code already written.

YAGNI : You Are Not Goingto Need It

Behavior-Driven Development (BDD) is an agile process designed to keep the focus on stakeholder value throughout the whole project. The premise of BDD is that the requirement has to be written in a way that everyone understands it – business representative, analyst, developer, tester, manager, etc. The key is to have a unique set of artifacts that are understood and used by everyone.

User stories are the central axis around which a software project rotates. Developers use user stories to capture requirements and to express customer expectations. User stories provide the unit of effort that project management uses to plan and to track progress. Estimations are made against user stories, and user stories are where software design begins. User stories help to shape a system’s usability and user experience.

User stories express requirements in terms of The Role, The Goal, and The Motivation.

A BDD story is written by the whole team and used as both requirements and executable test cases. It is a way to perform test-driven development (TDD) with a clarity that cannot be accomplished with unit testing. It is a way to describe and test functionality in (almost) natural language.


BDD Story Format
Even though there are different variations of the BDD story template, they all have two common elements: narrative and scenario. Each narrative is followed by one or more scenarios.

The BDD story format looks like this:

In order to [benefit]
As a [role]
I want to [feature]
Scenario: [description]
Given [context or precondition]
When [event or action]
Then [outcome validation]

“User stories are a promise for a conversation” (Ron Jeffries)
A BDD story consists of a narrative and one or more scenarios. A narrative is a short, simple description of a feature told from the perspective of a person or role that requires the new functionality. The intention of the narrative is NOT to provide a complete description of what is to be developed but to provide a basis for communication between all interested parties (business, analysts, developers, testers, etc.) The narrative shifts the focus from writing features to discussing them.
Even though it is usually very short, it tries to answer three basic questions that are often overlooked in traditional requirements.
What is the benefit or value that should be produced (In order to)?
Who needs it (As a)? And what is a feature or goal (I want to)?
With those questions answered, the team can start defining the best solution in collaboration with the stakeholders.

The narrative is further defined through scenarios that provide a definition of done, and acceptance criteria that confirm that narrative that was developed fulfill expectations.

It is important to remember that the written part of a BDD story is incomplete until discussions about that narrative occur and scenarios are written. Only the whole story (narrative and one or more scenarios) represents a full description of the functionality and definition of done.

If more information is needed, narratives can point to a diagram, workflow, spreadsheet, or any other external document.

Since narratives have some characteristics of traditional requirements, it is important to describe distinctions. Two most important differences are precision and planning

Narratives favor verbal communication. Written language is very imprecise, and team members and stakeholders might interpret the requirement in a different way.

Verbal communication wins over written.
As another example,  is the following requirement statement relating to a registration screen: “The system shall allow the user to register using 16 character username and 8 character password”.

It was unclear whether the username MUST be 16 characters or whether it could be any length up to 16 characters, or whether it could be any length with a minimum of 16 characters. In this particular case, the business analyst removed any doubt as soon as clarification was asked.

However, there are many other cases
when developers take requirements as a final product and simply implement them in a way they understand them. In those cases they might not understand the reasons behind those requirements but just “follow specifications”. They might have a better solution in mind that never gets discussed.

IEEE 830 style requirements (“The system shall…”) often consist of hundreds or even thousands of statements. Planning such a large number of statements is extremely difficult. There are too many of them to be prioritized and estimated, and it is hard to understand which functionalities should be developed. That is especially evident when those statements are separated into different sections that represent different parts of the system or products. Without adequate prioritization, estimation, and description of the functionality itself, it is very hard to accomplish an iterative and incremental development process. Even if there is some kind of iteration plan, it can take a long time for a completed functionality to be delivered, since the development of isolated parts of the
system is done in a different order and at a different speed.

Narratives are not requirement statements
The Computer Society of the Institute of Electrical and Electronics Engineers (IEEE) has published a set of guidelines on how to write software requirements specifications. This document is known as IEEE Standard 830 and it was last updated in 1998. One of the
characteristics of an IEEE 830 statement is the use of the phrase
“The system shall…”. Examples would be:

The system shall allow the user to login using a username and password.

The system shall have a login confirmation screen.

The system shall allow 3 unsuccessful login attempts.

Writing requirements in this way has many disadvantages: it is error prone and time-consuming, to name but two. Two other important disadvantages are that it is boring and too long to read.
This might seem irrelevant until you realize the implications. If reviewers and, if there is such a process, those who need to sign off requirements do NOT read it thoroughly and skip sections out of boredom, or because it does NOT affect them, many things will be missed. Moreover, having a big document written at that level often prevents readers from understanding the big picture and the real goal of the project.

A Waterfall model combined with IEEE 830 requirements tends to plan everything in advance, define all details, and hope that the project execution will be flawless. In reality, there are almost no successful software projects that manage to accomplish these goals. Requirements change over time resulting in “change requests”. Changes are unavoidable and only through constant communication and short iterations can the team reduce the impact of these changes. IEEE 830 statements are a big document in the form of a checklist. Written, done, forgotten, the overall understanding is lost. The need for constant reevaluation is nonexistent.
Consider the following requirements:

  • The product shall have 4 wheels.
  • The product shall have a steering wheel.
  • The product shall be powered by electricity.
  • The product shall be produced in different colors.

Each of those statements can be developed and tested independently and assembled at the end of the process. The first image in someone’s head might be an electrically-powered car.
That image is incorrect. It is a car, it has four wheels, it is powered by electricity (rechargeable batteries) and it can be purchased in different colors. it is A toy car

That is probably not what individual would think from reading those statements. A better description would be:

In order to provide entertainment for children
As a parent
I want a small-sized car
By looking at this narrative, it is clear what the purpose is (enter- tainment for children), who needs it (parents), and what it is (a small-sized car). It does not provide all the details since the main purpose is to establish the communication that will result in more information and understanding of someone’s needs.

That process might end with one narrative being split into many. Further on, scenarios produced from that narrative act as acceptance criteria, tests, and definition of done.

Who can write narratives?
Anyone can write narratives. Teams that are switching to Agile tend to have business analysts as writers and owners of narratives or even whole BDD stories (a narrative with one or more scenarios).
In more mature agile teams, the product owner has a responsibility to make sure that there is a product backlog with BDD stories. That does not mean that he writes them. Each member of the team can write BDD stories or parts of them (narrative or scenario).
Whether all the narratives are written by one person (customer, business analyst, or product owner) or anyone can write them (developers, testers, etc.) usually depends on the type of organization and customers. Organizations that are used to “traditional” requirements and procedures that require them to have those requirements “signed” before the project starts often struggle during their transition to Agile and iterative development. In cases like this, having one person (usually a business analyst) as the owner and writer of narratives might make a smoother transition towards team ownership and lower the impact on the organization

A good BDD narrative uses the “INVEST” model:

  •  Independent. Reduced dependencies = easier to plan.
  •  Negotiable. Details added via collaboration.
  •  Valuable. Provides value to the customer.
  •  Estimable. Too big or too vague = not estimable.
  •  Small. Can be done in less than a week by the team.
  •  Testable. Good acceptance criteria defined as scenarios.

While IEEE 830 requirements are focused on system operations, BDD narratives focus on customer value. They encourage looseness of information in order to foster a higher level of collaboration between stakeholders and the team. The actual work being done is accomplished through collaboration revolving around the narrative that becomes more detailed through scenarios as the development progresses. Narratives are at higher level than IEEE 830 requirements. Narratives are followed by collaboratively developed scenarios which define when the BDD story meets the expectations.

Even though narratives can be written by anyone, it is often the result of conversations between the product owner or business analyst and the business stakeholder.
Scenarios describe interactions between user roles and the system. They are written in plain language with minimal technical details so that all stakeholders (customer, developers, testers, designers, marketing managers, etc.) can have a common base for use in discussions, development, and testing.
Scenarios are the acceptance criteria of the narrative. They represent the definition of done. Once all scenarios have been implemented, the story is considered finished. Scenarios can be written by anyone, with testers leading the effort.

The whole process should be iterative within the sprint; as the development of the BDD story progresses, new scenarios can be written to cover cases not thought of before. The initial set of scenarios should cover the “happy path”. Alternative paths should be added progressively during the duration of the sprint.

Scenarios consist of a description and given, when, and then steps.
The scenario description is a short explanation of what the scenario does. It should be possible to understand the scenario from its description. It should not contain details and should not be longer than ten words.
Steps are a sequence of preconditions, events, and outcomes of a scenario. Each step must start with words given, when or then.
The Given step describes the context or precondition that needs to be fulfilled.

Given visitor is on the home screen

The When step describes an action or some event.

When user logs in

The Then step describes an outcome.

Then welcome message is displayed

Any number of given, when and then steps can be combined, but at least one of each must be present. BDD steps increase the quality of conversations by forcing participants to think in terms of pre-conditions that allow users to perform actions that result in some outcomes. By using those three types of steps, the quality of the interactions between team members and stakeholders increases.

The following process should be followed.
1. Write and discuss narrative.
2. Write and discuss short descriptions of scenarios.
3. Write steps for each scenario.
4. Repeat steps 2 and 3 during the development of the

By starting only with scenario descriptions, we are creating a basis that will be further developed through steps. It allows us to discuss different aspects of the narrative without going into the details of all the steps required for each of the scenarios. Do not spend too much time writing descriptions of all possible scenarios. New ones will be written later.
Once each scenario has been fully written (description and steps) new possibilities and combinations will be discovered, resulting in more scenarios.

Each action or set of actions (when steps) is followed by one or more outcomes (then steps). Even though this scenario provides a solid base, several steps are still missing. This situation is fairly common because many steps are not obvious from the start.
Additional preconditions, actions, and outcomes become apparent only after first version of the scenario has been written.

This scenario covers one of many different combinations. It describes the “happy path” where all actions have been performed successfully. To specify alternative paths, we can
copy this scenario and modify it a bit.

This scenario was not written and fully perfected at the first attempt  but through several iterations. With each version of the scenario,  new questions were asked and new possibilities were explored.
The process of writing one scenario can take several days or even  weeks. It can be done in parallel with code development. As soon as  the first version of the scenario has been completed, development  can start. As development progresses, unexpected situations will  arise and will need to be reflected in scenarios.

Behavior-driven development borrows the concept of the ubiquitous language from domain driven design. A ubiquitous language is a (semi-)formal language that is shared by all members of a software development team — both software developers and non-technical personnel. The language in question is both used and developed by all team members as a common means of discussing the domain of the software in question.  In this way BDD becomes a vehicle for communication between all the different roles in a software project.

BDD uses the specification of desired behavior as a ubiquitous language for the project team members. This is the reason that BDD insists on a semi-formal language for behavioral specification: some formality is a requirement for being a ubiquitous language. In addition, having such a ubiquitous language creates a domain model of specifications, so that specifications may be reasoned about formally. This model is also the basis for the different BDD-supporting software tools that are available.

Much like test-driven design practice, behavior-driven development assumes the use of specialized support tooling in a project. Inasmuch as BDD is, in many respects, a more specific version of TDD, the tooling for BDD is similar to that for TDD, but makes more demands on the developer than basic TDD tooling.

Tooling principles

In principle a BDD support tool is a testing framework for software, much like the tools that support TDD. However, where TDD tools tend to be quite free-format in what is allowed for specifying tests, BDD tools are linked to the definition of the ubiquitous language discussed earlier.

As discussed, the ubiquitous language allows business analysts to write down behavioral requirements in a way that will also be understood by developers. The principle of BDD support tooling is to make these same requirements documents directly executable as a collection of tests. The exact implementation of this varies per tool, but agile practice has come up with the following general process:

  • The tooling reads a specification document.
  • The tooling directly understands completely formal parts of the ubiquitous language . Based on this, the tool breaks each scenario up into meaningful clauses.
  • Each individual clause in a scenario is transformed into some sort of parameter for a test for the user story. This part requires project-specific work by the software developers.
  • The framework then executes the test for each scenario, with the parameters from that scenario.

Dan North has developed a number of frameworks that support BDD (including JBehave and RBehave), whose operation is based on the template that he suggested for recording user stories  These tools use a textual description for use cases and several other tools (such as CBehave) have followed suit. However, this format is not required and so there are other tools that use other formats as well. For example Fitnesse (which is built around decision tables), has also been used to roll out BDD.

Tooling examples

There are several different examples of BDD software tools in use in projects today, for different platforms and programming languages.

Possibly the most well-known is JBehave, which was developed by Dan North. The following is an example taken from that project:

Consider an implementation of the Game of Life. A domain expert (or business analyst) might want to specify what should happen when someone is setting up a starting configuration of the game grid. To do this, he might want to give an example of a number of steps taken by a person who is toggling cells. Skipping over the narrative part, he might do this by writing up the following scenario into a plain text document (which is the type of input document that JBehave reads):

Given a 5 by 5 game
When I toggle the cell at (3, 2)
Then the grid should look like
When I toggle the cell at (3, 1)
Then the grid should look like
When I toggle the cell at (3, 2)
Then the grid should look like

The bold print is not actually part of the input; it is included here to show which words are recognized as formal language. JBehave recognizes the terms Given (as a precondition which defines the start of a scenario), When (as an event trigger) and Then (as a postcondition which must be verified as the outcome of the action that follows the trigger). Based on this, JBehave is capable of reading the text file containing the scenario and parsing it into clauses (a set-up clause and then three event triggers with verifiable conditions). JBehave then takes these clauses and passes them on to code that is capable of setting a test, responding to the event triggers and verifying the outcome. This code must be written by the developers in the project team (in Java, because that is the platform JBehave is based on). In this case, the code might look like this:

private Game game;
private StringRenderer renderer;
@Given("a $width by $height game")
public void theGameIsRunning(int width, int height) {
    game = new Game(width, height);
    renderer = new StringRenderer();
@When("I toggle the cell at ($column, $row)")
public void iToggleTheCellAt(int column, int row) {
    game.toggleCellAt(column, row);
@Then("the grid should look like $grid")
public void theGridShouldLookLike(String grid) {
    assertThat(renderer.asString(), equalTo(grid));

The code has a method for every type of clause in a scenario. JBehave will identify which method goes with which clause through the use of annotations and will call each method in order while running through the scenario. The text in each clause in the scenario is expected to match the template text given in the code for that clause (for example, a Given in a scenario is expected to be followed by a clause of the form “a X by Y game”). JBehave supports the matching of actual clauses to templates and has built-in support for picking terms out of the template and passing them to methods in the test code as parameters. The test code provides an implementation for each clause type in a scenario which interacts with the code that is being tested and performs an actual test based on the scenario. In this case:

  • The theGameIsRunning method reacts to a Given clause by setting up the initial game grid.
  • The iToggleTheCellAt method reacts to a When clause by firing off the toggle event described in the clause.
  • The theGridShouldLookLike method reacts to a Then clause by comparing the actual state of the game grid to the expected state from the scenario.

The primary function of this code is to be a bridge between a text file with a story and the actual code being tested. Note that the test code has access to the code being tested (in this case an instance of Game) and is very simple in nature (has to be, otherwise a developer would end up having to write tests for his tests).

Finally, in order to run the tests, JBehave requires some plumbing code that identifies the text files which contain scenarios and which inject dependencies (like instances of Game) into the test code. This plumbing code is not illustrated here, since it is a technical requirement of JBehave and does not relate directly to the principle of BDD-style testing.

Story versus specification

A separate subcategory of behavior-driven development is formed by tools that use specifications as an input language rather than user stories. An example of this style is the RSpec tool that was also developed by Dan North. Specification tools don’t use user stories as an input format for test scenarios but rather use functional specifications for units that are being tested. These specifications often have a more technical nature than user stories and are usually less convenient for communication with business personnel than are user stories. An example of a specification for a stack might look like this:

Specification: Stack

When a new stack is created
Then it is empty

When an element is added to the stack
Then that element is at the top of the stack

When a stack has N elements 
And element E is on top of the stack
Then a pop operation returns E
And the new size of the stack is N-1

Such a specification may exactly specify the behavior of the component being tested, but is less meaningful to a business user. As a result, specification-based testing is seen in BDD practice as a complement to story-based testing and operates at a lower level. Specification testing is often seen as a replacement for free-format unit testing.

Specification testing tools like RSpec and JDave are somewhat different in nature from tools like JBehave. Since they are seen as alternatives to basic unit testing tools like JUnit, these tools tend to favor forgoing the separation of story and testing code and prefer embedding the specification directly in the test code instead. For example, an RSpec test for a hashtable might look like this:

describe Hash do
  before(:each) do
    @hash = => 'world')
  it "should return a blank instance" do eql({})
  it "should hash the correct information in a key" do
    @hash[:hello].should eql('world')

This example shows a specification in readable language embedded in executable code. In this case a choice of the tool is to formalize the specification language into the language of the test code by adding methods named it and should. Also there is the concept of a specification precondition – the before section establishes the preconditions that the specification is based on.

Cucumber lets software development teams describe how software should behave in plain text. The text is written in a business-readable domain-specific language and serves as documentation, automated tests and development-aid – all rolled into one format.

Cucumber works with Ruby, Java, .NET, Flex or web applications written in any language. It has been translated to over 40 spoken languages.

Cucumber also supports more succinct tests in tables – similar to what FIT does. Users can view the examples and documentation to learn more about Cucumber tables.

Gherkin gives us a lightweight structure for documenting examples of the behavior our stakeholders want, in a way that it can be easily understood both by the stakeholders and by Cucumber. Although we can call Gherkin a programming language, its primary design goal is human readability, meaning you can write automated tests that read like documentation.

Using mocks

BDD proponents claim that the use of “should” and “ensureThat” in BDD examples encourages developers to question whether the responsibilities they’re assigning to their classes are appropriate, or whether they can be delegated or moved to another class entirely. Practitioners use an object which is simpler than the collaborating code, and provides the same interface but more predictable behavior. This is injected into the code which needs it, and examples of that code’s behavior are written using this object instead of the production version.

These objects can either be created by hand, or created using a mocking framework such as mock.

Questioning responsibilities in this way, and using mocks to fulfill the required roles of collaborating classes, encourages the use of Role-based Interfaces. It also helps to keep the classes small and loosely coupled.

PEARL XVII : Multidimensional Testing Coverage Matrix


In Agile Software Development Methodology, the Multi Dimensional Testing Coverage Matrix  of what needs to be tested should be defined early. The importance of this has grown exponentially the past few years, as the test coverage matrix has become increasingly complex.

Rapid prototyping and development techniques combined with Agile development methodologies are pushing the envelope on the best practice of testing early and testing often. Keeping pace with the quick development turn-around and shorter time to market and being adaptive to late changes in requirements requires effective management of quality process. The use of  multidimensional test coverage matrix which maps of test artifacts – test cases, test defects, test fixtures – mapped to the requirements – needs, features, use cases and supplementary requirements – as a QA scheduling and planning tool defined early in the project, though claimed to have been practiced, has been largely overlooked by the  software industry.

 View of Agile Delivery Life Cycle

View of Agile Delivery Life Cycle

User needs in an agile process are defined by a story (sometimes captured as use-cases and features) planned to be implemented iteratively. Work break down for development (in iterations) of these use-cases and features is defined in terms of tasks.

Test coverage can help in monitoring the quality of testing, and assist in directing the test generators to create test cases that cover areas that have not been tested before.

Get Better Structure of the Product: Understanding the end-to-end data flow of an  application helps to analyze the root cause of a defect. Split the complete  product into small segments that will help team to get a clear structure of a product as well  as flows and dependencies of each and every part of modules.

Depending on Windows/Mac/Linux/Unix platforms, different types of browser-based tools are important for agile testers to troubleshoot the  defects. For example, for Http(s) tracking tools – Parse Proxy, Http Watch, WebScarab,  Http Debugger Pro, Archillies, and log tracing tools- Winscp & Putty, XML SPY,etc. These dependencies shall be clearly depicted in the Multidimensional Test coverage Matrix.

The agile team needs to  develop good test scenarios for future automation, end-to-end testing and product  lifecycle analysis, to help in organizational process growth

Acceptance TDD (ATDD). Team can do TDD at the requirements level by writing  customer test, the equivalent of a function test or acceptance test in the traditional world. Acceptance TDD is often called behavior-driven development (BDD) or story test-driven development, where you first automate a failing story test, then driving the design via TDD until the story test passes (a story test is a customer acceptance test).

Requirement Types

There are several categories of requirements, these are: Stakeholder, HighLevel Business, Application, Data, Security, Test (Quality), Supplementary, and Change
Management. Some of these categories have a lower level of granularity associated with them,
Stakeholder Requirements
These usually come from the CEO of the company, or the body of the Board of Directors. These are very high-level. They usually focus on a major “problem” that they want solved. These can also include high-level expectations for: Performance (“instantaneous”), Availability (“24x7x365”) and Security (“totally secure”).

High-Level Business Requirements
High-level requirements will fulfill Stakeholder Requirements. They are traced directly from them.  High-Level business requirements trace to Application Requirements.
Application Requirements
Application requirements drive the development of the application. They fall into the following categories; Use Case Requirements, Business Requirements/Rules, Functional Requirements, Technical Requirements, User Interface Requirements, “Look and Feel” Requirements and Navigation Requirements. There are some very fine lines between these types, and the ultimate strategy may be to combine these categories as needed.
Use Case Requirements
These start in the form of Use-Case Documents, but can be broken down into individual
requirements. The use case describes the basic flow of the system, alternate paths through the system. Business Rules, Navigation and User Interface requirements are all derived from the use case, and are traced from it.
Business Requirements/Rules
A Business Requirement or Rule is something that is specific to the business. These are
sometimes listed as “non-functional” requirements, as they do not have any function to them. The rules exist whether or not a system exists. An example of this would be, for a transportation firm,“Trucks only can travel 55 mph,” and another would be “We accept no bid less than $100,000.” This is also likely a list of data that is required to be captured, with the data including the data items needed, such as Name, address, etc. If there is a business need for data to be in a certain format, or minimum or maximum length for a text field, for example, that too is captured here. Any edit, validation, or default value that serves a business purpose is also in this category. This list of business rules is often captured in a business catalog. These are all should be traced from the use case.
Functional Requirements
These are driven and traced from the Business Requirements and Rules. They describe how a business rule is carried out, or how data is captured. These are usually in the format of “system shall do this or do that.”
Technical Requirements
These are derived during the low level design process, and sometimes during development. They are driven from and traced from the Functional Requirements. They are not “user” features of the system, but describe the low-level required actions of the system, that only a designer or developer would know. For example, “When transaction is being processed, and an error of type XYZ occurs, a rollback of the database transaction is required.” They can also include details of an error message, and error handling requirements.
User Interface Requirements
These are driven from Functional and Use Case Requirements, are traced from them both, depending on where they were derived from. They include items such as screen layout, tab flow, mouse and keyboard use, what controls to use for what functions (e.g. radio button, pulldown list), and other “ease of use” issues.
“Look and Feel” Requirements
These are driven from Functional and Business Requirements, and are traced from them both, depending on where they were derived from. These can be categorized as the “non-functional”
User Interface type requirements. They deal with how fields look, regarding font, font size,
colors, graphics, etc.
Navigation Requirements
These are driven and traced from the Use Case, as the Use Case lists the flow of the system, and the Navigation Requirements depict how that flow will take place. They are usually presented in a storyboard format, and should show the screen flow of each use case, and every alternate flow. Additionally, they should state what happens to the data or transaction for each step, for example, what happens to the data entered on a previous screen if the user decides to “go back?” They include the various ways to get to all screens, and an application screen map should be one of the artifacts derived in this category of requirements.
Based on the above Application Requirements, the Data Requirements are derived, and are traced from the Application Requirements.
Data Requirements
Based on the data needed in the Business Rules, and taking other requirements types into consideration, the database platform, database tables, columns, data types, size and other database attributes can be created.
Security Requirements
These are traced from wherever they need to be traced from, as they encompass all requirements that have do directly with the application . They mainly will come from Business Rules.
Test (Quality) Requirements/Test Cases
The Test Cases are traced from all types of requirements, and can be percived as the all en compassing box that all requirements are inside of. This shows that all requirements shall have test cases traced to it. If that test case fails during testing, the team should be able to see what higher-level requirement would not be fulfilled.
Supplementary Requirements
Traced from Data and Application requirements, these refer to the technology infrastructure and operations type of requirements, such as hardware and network requirements. There are many Operations Requirements that must also be captured, in the categories of, Administration Requirements, Maintenance Requirements, Disaster/Recovery Requirements, Skill Set of personnel Requirements, Change Management Requirements, User Documentation Requirements, Training Requirements, and Demo/Presentation Requirements. Other nonfunctional requirements that do not fall into any other category would fall into this “catch-all” category.

Carefully Define Testing Coverage Matrix: With the help of multi-dimensional  matrix, define the coverage requirements for a vital part of the specifications process at  an early stage. The size of the coverage matrix has an important influence on staffing  needs and QA budgets. Defining the testing coverage matrix early benefits the management to distribute resources and have better control and analysis of what can be  done internally versus what should be outsourced.

Test coverage in the test plan states what requirements will be verified during what stages of the product life. Test Coverage is derived from design specifications and other requirements, such as safety standards or regulatory codes, where each requirement or specification of the design ideally will have one or more corresponding means of verification. Test coverage for different product life stages may overlap, but will not necessarily be exactly the same for all stages. For example, some requirements may be verified during Design Verification test, but not repeated during Acceptance test. Test coverage also feeds back into the design process, since the product may have to be designed to allow test access .

In order to reproduce production scenarios or customer-specific issues, development and test teams need to be able to change operating systems, browsers, and databases, or infrastructure parameters such CPU, memory, disk size, and network configuration. These scenarios must be addressed in the multidimensional test coverage matrix.

The use cases descriptions define the main success scenarios of the system. However, not every use case scenario ends in a success for the user. While elaborating the use-cases using the descriptive text to capture these alternate paths, new aspects of the systems come to light when exceptions are encountered (non-happy path behavior of the system is being captured).

Spence and Probasco refer to them as overloading the term requirements, a common point of confusion with Requirements Management. These may not be clear from the user needs and system features captured, but they are a very vital and essential aspect of the system behavior. To ensure that the system meets these requirements and for coverage to be effective, these have to be elicited clearly and traced completely. Alternate paths may also be captured using a usability (scenario) matrix . While the use cases are mapped against features (or cards) which are planned for the iteration, so can the use-cases, the use-case scenarios that stem from these and so on, cascading to the test cases (and test artifacts)

Note that the usage of the application flow, even though captured, could end-up varying the application flow based on the data . Supplementary requirements corresponding to the architectural requirements for the system cannot be mapped unless captured separately. These remain outside the functional requirements modeled by the use cases.

A sample list of business rules that have to be followed could be summarized.

When the mapping of the test case flows across functionality is carried, it becomes evident that the granularity of details falls short; when mapping the coverage of the test flows against the business rules  in the tabular representation.

For example, Based on the feature set as set out it is possible that any one of the flows used to ensure coverage of business requirement 1 could as well serve for business requirement 2. However, on closer scrutiny the test case flow that tests non-happy path scenario of business requirement rule 2 requires a further elaboration of the test flows against feature set.

Such gaps and inadequacies will come to light in a multidimensional test coverage matrix that is not granular and consequently, the test coverage falls short. Tracing every non functional, business and non-business requirement to test cases and scenarios should increase the confidence and coverage of testing and QA activities that can be performed. The usability flows and concrete test cases that cover the requirements and needs can be formulated and with each iteration, targeted test cases could be identified to be run or executed to address within the specific build.

Test Coverage matrix is really multi-dimensional and to be effective QA artifacts, they have to transcend the various phases of the development process – initiation, elaboration, construction and transition. Further, it has to be a “living” artifact, one that is updated with each iteration

Multi Dimensional Test coverage matrix example

Multi Dimensional Test coverage matrix example

Within iterations, a set of acceptance and regression tests have to be scheduled and performed to meet the exit criteria. Features and stories (in the form of cards) are planned in iterations in an agile methodology. With multi dimensional test coverage matrix and mapping of the test cases to features, use cases and defects, optimum test planning assuring the software quality within each build/release becomes effortless and convenient. By establishing effective multi dimensional test coverage matrix, helps to answer some of the following questions

1. What test cases should be selected to run for the current build – verify fixed defects, regression suite for the current fixes, apart from the base code smoke and build acceptance tests?

2. What impact does change in a specific set of non-functional and functional requirements have on the QA testing process in arriving at test estimates?

3. How can defects identified be mapped to the requirements that the iteration was scoped to achieve? And what surround testing and re-testing have to be carried out to validate before the defects can be closed out or new but related ones identified?

4. What change requests were brought about by the most recent build or iteration and what does this new change entail?

Testing coverage matrix also establishes tracking back to the exact requirements being implemented in the iteration improving coverage and confience in the quality process. This is of greater significance in agile projects where requirements documentation isn’t complete as requirements continue to evolve with each build or iteration. Agility ensures the process (and the product) is adaptive to changing requirements and using testing coverage for QA activities ensures that verification keeps up with these changes. impact on quality

Multi Dimensional Attributes of Test Coverage Matrix

Multi Dimensional Test coverage matrix defines a method for testing a complex software system, wherein the complex software system has interrelated system programs.

The method comprising the steps of:

  • Determining linkages between interrelated system programs using an  multidimensional test coverage matrix;
  • identifying a change in one or more of the interrelated system programs;
  • applying the multidimensional test coverage matrix such that it depicts information pertaining to a selected test scenario and test cases pertaining to the identified change,
  • And also to depict other test scenarios and test cases linked by two or more levels through at least one of dependencies and tributaries.
  • The test coverage matrix is adapted to depict linkages across three or more levels of dependency;

Multi dimensional Test coverage matrix enables to keep track of the complex relationships between various components of complex software system and to assist in the regression testing needed in the integration and subsequent modification of the complex software system.  it is used to store the relationship information between test cases (predetermined scenarios involving a series of specified transactions to test the behavior of one or more software components of the complex software system) and/or the individual components of the complex software system

Dependency Scenario

Dependency Scenario

PEARL XX : Agile methodologies for Mobile Software Development


Agile Methodologies are best fit for Mobile Software Development 


The adoption of increasingly advanced mobile devices has inherently changed consumer and business expectations of communication and access to information. Because of technology built into mobile devices that collects data about user behavior — data not available through traditional desktop forms of computing — the expectation of what an application can offer is also evolving and becoming more sophisticated. As behavioral input affects application development and, in turn, user expectation, the consumer and business market will continue to migrate to and ultimately depend on mobile computing,
currently a technological genesis of possibilities.

As mobile computing becomes more pervasive it is necessary for any company to explore its mobile options and determine what advantage they offer to the business and its customers, as well as the cost and potential return. This is a continually shifting landscape affected by multiple — and sometimes seemingly disparate — variables including, but not limited to:

  • Development across multiple platforms, each with separate operating systems in various stages of market adoption and functioning on devices created by a number of companies, and each with their own specifications and digital functions
  • The advantage of developing native applications versus less expensive mobile web applications
  • Identification of who currently has — and anticipating who will have — competitive dominance in the marketplace, from device manufacturers to service providers; can be as basic as looking to trends in the market and projecting based on current consumer adoption of specific devices, or as complex as identifying who controls content such as film and television series license rights, partnership opportunities for digital, cloud-based distribution and how the limited threshold of consumer entertainment spending will affect device adoption based on content distribution investment in the right functionality, by identifying what technology is going to jump the gap from conceptual development to mainstream adoption
  • Environments provided to developers to create and distribute applications. For example, Apple dominated the market when it opened the floodgates by allowing almost anyone to develop and release apps to its store, but created a restrictive approval process. Android has been even more flexible and forgiving with its development environment, which may be in part why it has surpassed Apple in the market. Conversely, Blackberry has suffered from an unfriendly environment in which to develop.

These are just some of the considerations affecting the world of mobile computing, but the common denominator to all of these is the variable of continual change. And change happens quickly. For a company to embrace the opportunity and overcome the challenges presented by mobile computing, it must consider change as an expected variable and develop applications accordingly.

One aspect of the mobile market that allows a business to manage this variable is the downloadable distribution of applications. A newer or updated version of an application can be distributed and updated frequently. In this respect a new version of the application designed around changing variables can be released to the market as often as necessary. This also allows for the opportunity to bring an application to market more quickly, by breaking down its expected functionality, prioritizing it and gradually building it into the application through various version releases over time.

Employing Agile Development Methodology during the construction phase of applications allows for an iterative approach to development; small builds of each feature can be created through short sprints that can be tested for quality assurance and then integrated or re-built.
The iterative spirit of Agile should be extended into the entire application development cycle to allow all accompanying design and technical documentation to respond and evolve from each feature build to each complete version release of the application.
This is accomplished by establishing a methodology that carries through the inception and elaboration phase of each version release, complementary to the Agile methodology used in the construction phase, that allows for evolution. Utilizing an Adaptive Methodology, each version release of the application is developed and built upon
the last version, while both capturing the design intent of the previous version and incorporating new data, stakeholder concerns, metrics, Agile construction, and QA, technical and design considerations (the change variable) into the updated version

Research Literature

One of the pioneering studies in agile approach is by Abrahamsson  where it was assessed that agile development solution provides a good fit for mobile application development environment and proposed a new approach called Mobile D.  A new architecture concept called Architecture Line has also been introduced that aims producing an application framework, which guides the development of future mobile applications.The Architecture Line in the methodology is a new addition to the already established  agile practices. An architecture line is used to capture an organization’s knowledge of architectural solutions, from both internal and external sources, and to use these solutions when needed.

The successful development of mobile applications is challenged by several of software’s nastiest development and deployment landmines – rapidly emerging standards, volatile platforms, intermittent connections, varied devices, and inconsistent user-interface and input technology. Unfortunately, not only does the infrastructure pose a threat to successful deployment, the sheer volume of potential users and growing demand for accelerated delivery exacerbates potential risks. To the average mobile phone user, what often appears to be a simple, easy to navigate  application, very likely means the company producing the application went to great lengths to deliver a reliable solution. Without such efforts, mobile users would end up with a multitude of platform-specific customization’s and one-off solutions, not to mention, a constant barrage of patches and updates. To keep development costs down and ensure high-quality software, mobile application development organizations must approach software development with a commitment to internal efficiencies. As a result, many of today’s most successful mobile application development organizations have transitioned to iterative and incremental delivery methods just to keep up with the rapid pace and constant change inherent in the industry.

Mobile-D approach is based on Rational Unified Process RUP (life-cycle coverage), eXtreme Programming XP (development practices) and Crystal methodologies (scalability).

Abrahamsson . have demonstrated the traits which reasons why agile technologies fits best in mobile software development. The various issues includes, high environment volatility, small development teams, identifiable customer, object- oriented development environment, non-safety critical software, application level software, small systems and
short development cycles.

Working software has been given a focus over comprehensive documentation; however the required documents should be identified and documented. Dooms  has proposed a method called ‘RaPiD7’ (rapid production of documentation, 7 steps) that improves the documentation work without scarifying the quantity and quality of documentation . RaPiD7
describes how human interaction is planned in software projects and how documents are to be created in facilitated workshops.

Rahimian and Ramsin  presents a different approach to the Mobile-D. They proposed a hybrid Agile and risk-based methodology that generates a method suitable for mobile application development designed from Methodology Engineering techniques.
This is a discipline concerned with creating methodologies suitable for different development scenarios, motivated by the belief that no single process fits all situations. It is based on a combination between agile methodologies, Adaptive Software Development (ASD) and New Product Development (NPD).
The ideal mobile software development characteristics that the hybrid engineering
methodology is based on are: agility, market consciousness, software product line support, architecture-based development, support for reusability, inclusion of review and learning sessions, early specification of physical architecture. The Hybrid Methodology Design process has been developed as a top-down, iterative-incremental process comprised of the following tasks: prioritization of requirements, selection of the design approaches to be used in the current iteration, application of the selected design approaches, revision, refinement and restructuring of the methodology built so far, defining the abstraction level for the next iteration, and finally the revision and refinement of the requirements, prioritizing them for the next iteration.

Jeong  proposed the Mobile Application Software Agile Methodology (MASAM) that provides the process for developing the mobile applications swiftly using an agile approach. It is based on Extreme Programming (XP), Agile Unified Process, RUP and
the Software and Systems Process Engineering Meta- model (SPEM). It is GUI based architecture-centered that uses Agile approaches for rapid development and utilizes domain knowledge. MASAM shows a strong tie with the Mobile-D methodology and introduces slight variations, such as a project management and follow up tool coupled with Eclipse Process Framework.

Cunha   proposed SLeSS; an agile approach integrates Scrum and Lean Six Sigma (LSS) that focuses on project management and process improvement respectively. The approach uses two types of product backlogs, Customization Product Backlog (for customizing development projects) and LSS Product Backlog (for process improvements).

The product backlog is an ordered list of requirements that is maintained for the product. It consists of features, bug fixes, non-functional requirements, etc.—whatever needs to be done in order to successfully deliver a viable product. The product backlog items (PBIs) are ordered by the Product Owner based on considerations like risk, business value, dependencies, date needed, etc.

Items added to a backlog are commonly written in story format. The product backlog is what will be delivered, ordered into the sequence in which it should be delivered. It is open and editable by anyone, but the Product Owner is ultimately responsible for ordering the items on the backlog for the Development Team to choose.

The product backlog contains the Product Owner’s assessment of business value and the Development Team’s assessment of development effort, which are often, but not always, stated in story points using a rounded Fibonacci sequence. These estimates help the Product Owner to gauge the timeline and may influence ordering of backlog items;

The product backlog and the business value of each backlog item is the responsibility of the Product Owner. The size (i.e. estimated complexity or effort) of each backlog item is, however, determined by the Development Team, who contributes by sizing items, either in story points or in estimated hours.

Scrum is an iterative and incremental agile software development framework for managing software projects and product or application development. It defines “a flexible, holistic product development strategy where a development team works as a unit to reach a common goal”. It challenges assumptions of the “traditional, sequential approach” to product development. Scrum enables teams to self-organize by encouraging physical co-location or close online collaboration of all team members and daily face to face communication among all team members and disciplines in the project.

A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team’s ability to deliver quickly and respond to emerging requirements.

A sprint (or iteration) is the basic unit of development in Scrum. The sprint is a timeboxed effort; that is, it is restricted to a specific duration. The duration is fixed in advance for each sprint and is normally between one week and one month, although two weeks is typical.

Each sprint is started by a planning meeting, where the tasks for the sprint are identified and an estimated commitment for the sprint goal is made, and ended by a sprint review-and-retrospective meeting, where the progress is reviewed and lessons for the next sprint are identified.

Scrum emphasizes working product at the end of the Sprint that is really “done”; in the case of software, this means a system that is integrated, fully tested, end-user documented, and potentially shippable.

The SLeSS approach has been used in real embedded software customization development projects for mobile phones. The approach was experimented in P&D&I laboratory, with a mobile phone manufacturer as a client with team of 7-12 developers, in duration from 4-6 months, with average size of 529 LOC (Line of Code) developed in ANSI C programming language.

Agile development is an umbrella term used to describe several popular, highly iterative software methodologies such as Extreme Programming (XP), Feature-driven Development (FDD), Lean Development, Adaptive Software Development, Scrum, and Crystal. Although each methodology may employ certain unique practices and principles, they all focus on business value, adaptability, high customer involvement, and the frequent delivery of production-quality software. Agile methods have gained popularity, especially in the last few years, as companies have come under increasing pressure to accelerate delivery in the face of changing requirements and rapidly evolving technology. Applicable to a broad spectrum of today’s software projects, these agile approaches have gained tremendous industry momentum due to their overall simplicity and discipline.

Companies such as Sabre, Sprint, Nortel, Symantec, Fidelity, Borland, Qwest, and hundreds of other leading technology and software organizations have begun employing agile development methods with considerable success. Many transitioned from more traditional methodologies and processes that had become too heavy and bureaucratic to remain competitive, and many others have simply transitioned from a little to no defined methodology. In the case of the latter, these companies knew they could not move to a more traditional software methodology without risking their ability to rapidly adapt and deliver.

Demands of Mobile Development

Development organizations and teams that build mobile applications are challenged with their own unique array of complexities. Unlike traditional client-server and web-based software development shops, mobile developers are faced with very strict boundaries (memory, screen size, input devices, etc.), short application lifecycles, and extreme usability requirements. These are in addition to the inherent environmental volatility previously referred to. Given such constraints and challenges, mobile application developers have had to become very quick on their feet in dealing with all of the variables in the development and deployment lifecycle. As a result, most have transitioned to an extensive use of emulators, test automation, automated deployment processes, and shorter development cycles. The use of platform enablement application development software from vendors such as AppForge ( and Metrowerks ( has also eased some of the development burden.

The Agile Advantage

Due to the demands associated with rapid delivery and volatile infrastructure, the overhead associated with many traditional development methods often cannot be tolerated within the mobile industry. Mobile developers generally don’t have the luxury of spending 60% or more of their development cycle on efforts and artifacts not associated with working software. With the constant changes in technology and requirements, they also cannot wait until the end of the development cycle to initiate the testing and verification process. Similarly, because of the extreme demands for quality across a broad spectrum of devices, platforms, and users, an ad hoc development approach does not result in very positive outcomes, at least not for long.

The practices and principles of agile development, on the other hand, align well with the requirements of mobile development teams. The commitment to simplicity, low overhead, business adaptability, rapid delivery, and customer feedback complement the needs of mobile development. Agile development techniques help maintain a strict focus on delivering the highest business value as soon as possible, while at the same time identifying and addressing technical risks as early as possible. Relatively painless to implement, agile development methods also help ensure minimal overhead and bureaucracy in the development lifecycle. Agile development methods favor lightweight, continuous planning as opposed to detailed, long-range planning simply for the fact that, especially in the world of mobile development, change occurs too frequently. Agile development’s commitment to the delivery of working, tested software at frequent intervals (generally between 1 and 4 weeks) ensures much greater reliability and opportunity to incorporate user- and technology-driven feedback.

With several of the engineering practices promoted by Extreme Programming such as refactoring, simple design, test-first development, automated unit and acceptance testing, and continuous integration, a team can begin to implement an internal infrastructure that is capable of rapidly responding to all types of change. Incorporating some or all of these well-known best practices can help teams implement highly efficient, well-tested applications across the required spectrum of platforms and devices. For mobile development teams looking to introduce a lightweight development process or scale back more bureaucratic processes, agile software development offers tremendous opportunities and value. In the face of both a rapidly changing business and technical environment, agile development’s continuous focus on ensuring alignment between business and technology is of critical importance. And not only does the value of continuous user involvement benefit the functionality and usefulness of the software, but the development rhythm of producing production-quality software every few weeks helps ensure a team’s ability to delivery more predictably, deploy more confidently, and change direction more easily in today’s unpredictable environment

Agile mobile development enables thoughtful user experiences.

Mobile apps run in limited environments, and there are restrictions placed on the size of the app that can be downloaded initially or later on, in updates. If the app takes more than a couple of minutes to download, the user may delete the ongoing download and move on. There are also restrictions on how much application data can be downloaded ahead of time and stored locally. Agile development allows developers to experiment with these options in subsequent sprints and adjust the design and features of the app in such a way that the user experience is quick, smooth and seamless.

 Agile mobile development enables phased roll out of feature sets.


Click to Enlarge

Self-contained apps like single player games need to be compact, and usually do not communicate back and forth with any back-end server. However, many serious consumer-facing apps need this back-end server access periodically (weather-related apps, airline apps showing flight status, travel sites, etc.) They face the constraint of having enough meaningful features and not overloading any one app with too many features. Clever app designers spawn additional apps when one app gets too big with too many feature sets already. Agile mobile development helps organizations adjust their designs, and scale back on features, if necessary, with subsequent sprints.

Interface and Interaction Design

In the Agile Mobile Application life cycle, After analyzing the project’s business goals the team work on test scenarios of its uses, creating UI / UX wireframes for each screen of the app, conduct user-tests with target users and come up with a solid vision of the app interface and layout.

Learning Loop

When the mobile app is ready, it is only a beginning. Now is the time to monitor its uses and the use of key metrics that were selected during the design phase. All of these are filled with useful information, which will be used to improve the product and the release of the second version. The product is alive and it must live and improve all the time. And the cycle of Build-Measure-Learn should be repeated constantly.

Build Learn Measure

Here are Agile stages for a mobile development project from discovery to completion:

  • Discovery
  • Inception
  • Weekly Sprints
  • Milestones
    • Exec demos
    • Architecture review
    • Static analysis tools
    • Security review
    • Platform retrospective
    • Feature freeze
    • Design QA
    • Release candidate and QA
    • Ship to app store
    • Project retrospective

Mobile computing growing exponentially. Gartner forecasts that by the end of 2014 over 185 billion apps will have been downloaded from mobile app stores since the launch of the first one in 2008.

Adaptive Agile Mobile Application Development

When looking to move into the mobile computing space, it is tempting to identify a quick fix or easy entry by just developing an app and posting it to a store. Though this exercise can be good from an informational or conversational standpoint, because of the quantum change affected by mobile computing, it is better to consider a longer term program which may be comprised of a number of apps, both consumer- and business-facing; in other words, a complete mobile solution. The foundation of developing an adaptive application is approaching it as part of a complete solution.

Mobile solution  gives insight into a number of other factors that may affect individual application development, such as:

  • How application development concerns, and is needed by, multiple  stakeholders within a company, including executive level,  marketing, sales, IT, distribution, manufacturing, etc.; each of  these stakeholder’s needs are often accessing or sharing similar  data and functionality that may need to be coordinated in both a  macro and micro sense
  • Different stakeholders may need to develop different applications that must work together, from brand consistency to optimizing development resources
  • Integration with existing enterprise systems and enhancing those systems with new data
  • Identification and gathering of metrics to determine design, function and return on investment of the application
  • Maintenance and optimization of application performance from the back-end to front-end
  • Security of data across the entire enterprise
  • Machine-to-machine communication beyond the enterprise and mobile device market
  • Coordination with external agencies and other service providers.

When a company approaches the development of an application or multiple  applications it should employ a complete Mobile Solution Approach.  The first step in creating the approach is capturing the types of  applications proposed for development and how they relate to each  other based on various factors affecting development.

Creative Design Process

A complete Mobile Solution Approach is essentially an adaptable roadmap detailing the development process from concept to delivery. Because of the dynamics of the marketplace and the varying factors that affect mobile development, every mobile solution is going to be unique to each company. A complete mobile solution needs to maintain a flexible documentation structure. In order for this documentation to remain adaptable to change, it is produced and maintained through systems typical to the Creative Design Process.

The goal of the Creative Design Process is to capture as much information and as many ideas as possible, quantify the captured information to produce documentation, and confirm the documentation through additional collaboration and research. Confirmed and finalized documentation is used to establish the next iteration of documentation. The process of establishing final design documentation for deliverables is handled in an iterative and agile manner.

Documentation is produced in steps and each step of documentation is used as a proof, or build, to qualify and establish the next step. Most documentation evolves from draft to final. Each final document exists as an editable, evolving document that is tracked through version identification. Each step of the documentation is created using the Creative Design Process.

The first step in creating a mobile solution is developing a core Understanding of Feature Catalog of a company’s needs and desires. This begins with capturing and organizing information provided by clients from the beginning of the sales process, to exist as a benchmark influencing the entire development. Once an Understanding of Feature Catalog has been established the information is used to create a Predictive Design Map that establishes development from foundational needs to aspirational desires. Typically, applications in the mobile market are updated periodically. This allows for the opportunity to define the foundational function of an application and bring it to market in a timely manner, adding functionality in later version releases. The Predictive Design Map details broad functions of each version release of the application prioritized and broken into a time line. The Predictive Design Map is incorporated into the Mobile Solution Approach that maps a phased approach to assessment, optimization, translation and functions of the mobile architecture including:

  • KPIs
  • Adoption
  • Optimization

The Mobile Solution Approach also includes the Application Design Document, comprised of an Executive Summary, a benchmark overview of each application and a Maturity Map, a detailed account of the functions of each version release and the steps involved in bringing it from Elaboration to Release. Once a Maturity Map has been established, the initial design documentation detailing the application can be created, including flows, wire-frames and mock-ups. After the initial design specifications have been established and to maintain the application’s adaptive nature, the Predictive Design Map is open to change over time and version releases of the application. It becomes the basis of an Evolving Design Map that defines the future versions of the application.

Concurrent to creation of the Mobile Solution Approach, the development of the application begins utilizing the Agile Development Process. The Agile Process allows for the creation of usable iterations of the application, or builds that can be tested for QA. Data from QA is used to modify the next iterative build. Agile employs its own documentation, which includes User Stories, short descriptive statements captured as user functionality desires, and a Project Backlog, a functionality list that is intended to be built into a version release of the application. Each version release of an individual application detailed in the Application Design Document is developed using the Agile Process.

Agile creates an environment that allows developers to quickly turn around usable builds of an application’s functionality. This is done by breaking the application into iterations that are developed over one- to two-week sprints, a short development cycle typified by daily “Scrums,” a short meeting where developers review the progress on their current task. To determine what is going to be developed during each sprint, the team developing the application establishes a number that represents the amount of production that can be accomplished during the sprint, assesses the user stories and collaboratively prioritizes and agrees on a numerical degree of difficulty each user story represents. Numerically these considerations are weighed against the amount of work possible and negotiated among development team members to establish an individual sprint story list. Each version release of an application is collectively comprised of a few iterations.

Android Development Methodology


The Adaptive approach to application development integrates and complements the Agile Development Process. Content and information can be shared between the two, influencing and completing one another. For example, information from the Predictive or Evolving Design Map can be used to establish Initial User Stories. On the other hand, as the project progresses, the Agile Features Backlog can be used to populate the Maturity Map. Based on the Mobile Solution Approach, each application is considered a continuing and constantly evolving product, which changes through each new version release. With the release of each new version, the vision of the product needs to be assessed, and features and functions need to be re-evaluated and updated. There are a number of factors affecting this evolution between versions. Some of these factors need to be anticipated, documented and captured in the Maturity Map, as well as built into the development of the application. Metrics need to be identified to quantify user behavior, which will affect the design of the next version release.

The tools to measure these metrics need to be developed into the application. Performance of the application needs to be measured across the entire application delivery chain so it can be optimized.  Security measures need to be addressed and built into the application. The measures may need to be enhanced based on the changes in user behavior. Back-end systems with which the application interfaces need to be assessed and incorporated into the development with any necessary enhancements or changes. The development and adoption of other concurrently developed applications must be detailed in the Mobile Solution Approach. Other external factors will need to be evaluated and incorporated into the design and development of each version release,


  • Changes or adjustments in KPIs — based on the market — the business or consumer is addressing with the application
  • Opportunities to enhance functionality based on technological advancements in the hardware market business changes in the mobile market including the public adoption of one device over another
  • Changes in software development practices and systems
  • Changes in legal issues such as privacy maintenance
  • Amendments or adjustments to development environments managed by each mobile provider and its respective digital distribution systems.

Though some of these factors can change during the development of an application and incorporated into the design dynamically, they are typically incorporated into the design during the Assessment, which encompasses the Vision, Inception, Elaboration and Support phases of version release. The Assessment of each new version release begins at the end of the previous version. Incorporating the information, metrics and influences identified during Assessment is a cornerstone of the Adaptive Methodology and its ability to create a responsive, evolving application.

University of Missouri Health Care and University of Missouri Information Experience Lab – Case Study

This case describes the agile management methods for an iPhone software development project. The overall objective was to design a smartphone solution that allowed surgeons access to dynamic Electronic Health Record (EHR) data to optimize their workflow. Three separate organizations distributed the responsibilities. Specifically, the lead organization, Cerner Corporation, collaborated with the University of Missouri Health Care and University of Missouri Information Experience Lab to create the technology. Project goals included increased surgeon satisfaction; improved task efficiency, as measured by time spent retrieving lab and vital sign data on morning rounds; dynamic data accessibility; and increased revenue from new product sales.

To accomplish these goals, agile project management was utilized, applying iterative usability methods to create deliverables within a short development cycle. Each development cycle focused on user-centered design principles. Several challenges were encountered related to the user-centered design methods, usability data extraction, academic collaborations, and interface design choices.

Welcome to Agile Pearls of Wisdom Blog

This Blog elucidates the pearls of wisdom in Agile Software Development methodology based on best practices, approaches, implementations, frameworks, checklists, cheat sheets, concepts, principles, guidelines, tools, methods, values, practices, philosophies, culture etc.

Agile software development 

Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen tight iterations throughout the development cycle.

Agile Development

Agile Development

The Agile Manifesto introduced the term in 2001. Since then, the Agile Movement, with all its values, principles, methods, practices, tools, champions and practitioners, philosophies and cultures, has significantly changed the landscape of the modern software engineering and commercial software development in the Internet era

Martin Fowler is widely recognized as one of the key founders of the agile methods.
Incremental software development methods have been traced back to 1957.In 1974, a paper by E. A. Edmonds introduced an adaptive software development process. Concurrently and independently the same methods were developed and deployed by the New York Telephone Company’s Systems Development Center under the direction of Dan Gielan. In the early 1970s, Tom Gilb started publishing the concepts of Evolutionary Project Management (EVO), which has evolved into Competitive Engineering. During the mid to late 1970s Gielan lectured extensively throughout the U.S. on this methodology, its practices, and its benefits.

So-called lightweight agile software development methods evolved in the mid-1990s as a reaction against the heavyweight waterfall-oriented methods, which were characterized by their critics as being heavily regulated, regimented, micromanaged and overly incremental approaches to development.

Proponents of lightweight agile methods contend that they are returning to development practices that were present early in the history of software development.

Agile Methodologies

Agile Methodologies

Early implementations of agile methods include Rational Unified Process (1994), Scrum (1995), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development (1997), and Dynamic Systems Development Method (DSDM) (1995). These are now collectively referred to as agile methodologies, after the Agile Manifesto was published in 2001.

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. The only concern with the term agile came from Martin Fowler (a Brit for those who dont know him) who allowed that most Americans didnt know how to pronounce the word agile.

Alistair Cockburns initial concerns reflected the early thoughts of many participants. “I personally didn’t expect that this particular group of agilites to ever agree on anything substantive.”
But his post-meeting feelings were also shared, “Speaking for myself, I am delighted by the final phrasing [of the Manifesto]. I was surprised that the others appeared equally delighted by the final phrasing. So we did agree on something substantive.”

Naming themselves “The Agile Alliance,” this group of independent thinkers about software development, and sometimes competitors to each other, agreed on the Manifesto for Agile Software Development .

But while the Manifesto provides some specific ideas, there is a deeper theme that drives many, but not all, to be sure, members of the alliance. At the close of the two-day meeting, Bob Martin joked that he was about to make a “mushy” statement. But while tinged with humor, few disagreed with Bobs sentiments that they all felt privileged to work with a group of people who held a set of compatible values, a set of values based on trust and respect for each other and promoting organizational models based on people, collaboration, and building the types of organizational communities in which they would want to work.

At the core, Jim Highsmith believes

Agile Methodologists are really about “mushy” stuff about delivering good products to customers by operating in an environment that does more than talk about “people as our most important asset” but actually “acts” as if people were the most important, and lose the word “asset”. So in the final analysis, the meteoric rise of interest in and sometimes tremendous criticism of Agile Methodologies is about the mushy stuff of values and culture.

For example, Jim thinks that ultimately, Extreme Programming has mushroomed in use and interest, not because of pair-programming or refactoring, but because, taken as a whole, the practices define a developer community freed from the baggage of Dilbertesque corporations.

Kent Beck told the story of an early job in which he estimated a programming effort of six weeks for two people. After his manager reassigned the other programmer at the beginning of the project, he completed the project in twelve weeks and felt terrible about himself! The boss of course harangued Kent about how slow he was throughout the second six weeks. Kent, somewhat despondent because he was such a “failure” as a programmer, finally realized that his original estimate of 6 weeks was extremely accurate for 2 people and that his “failure” was really the managers failure , indeed, the failure of the standard “fixed” process mindset that so frequently plagues our industry.

According to JIm Highsmith,
This type of situation goes on every day marketing, or management, or external customers, internal customers, and, yes, even developers dont want to make hard trade-off decisions, so they impose       irrational demands through the imposition of corporate power       structures. This isnt merely a software development problem, it    runs throughout Dilbertesque organizations.
In order to succeed in the new economy, to move aggressively into  the era of e-business, e-commerce, and the web, companies have to  rid themselves of their Dilbert manifestations of make-work and    arcane policies. This freedom from the inanities of corporate life attracts proponents of Agile Methodologies, and scares the         begeebers  out of traditionalists. Quite frankly, the Agile        approaches scare corporate bureaucrats at least those that are     happy pushing  process for process sake versus trying to do the    best for the "customer" and deliver something timely and tangible  and "as   promised" because they run out of places to hide.
The Agile movement is not anti-methodology, in fact, many of them  want to restore credibility to the word methodology. They want to  restore a balance. They  embrace modeling, but not in order to file some diagram in a dusty corporate repository. They embrace        documentation, but not hundreds of pages of never-maintained and   rarely-used tomes. They plan, but recognize the limits of planning in a turbulent environment. Those who would brand proponents of XP or SCRUM or any of the other Agile Methodologies as "hackers" are  ignorant of both the methodologies and the original definition of  the term hacker.

The meeting at Snowbird was incubated at an earlier get together of Extreme Programming proponents, and a few “outsiders,” organized by Kent Beck at the Rogue River Lodge in Oregon in the spring of 2000. At the Rogue River meeting attendees voiced support for a variety of “Light” methodologies, but nothing formal occurred. During 2000 a number of articles were written that referenced the category of “Light” or “Lightweight” processes. A number of these articles referred to “Light methodologies, such as Extreme Programming, Adaptive Software Development, Crystal, and SCRUM”. In conversations, no one really liked the moniker “Light”, but it seemed to stick for the time being.

In September 2000, Bob Martin from Object Mentor in Chicago, started the next meeting ball rolling with an email; “I’d like to convene a small (two day) conference in the January to February 2001 timeframe here in Chicago. The purpose of this conference is to get all the lightweight method leaders in one room. All of you are invited; and I’d be interested to know who else I should approach.” Bob set up a Wiki site and the discussions raged.

Early on, Alistair Cockburn weighed in with an epistle that identified the general disgruntlement with the word Light: “I don’t mind the methodology being called light in weight, but I’m not sure I want to be referred to as a lightweight attending a lightweight methodologists meeting. It somehow sounds like a bunch of skinny, feebleminded lightweight people trying to remember what day it is.”

The fiercest debate was over location! There was serious concern about Chicago in wintertime cold and nothing fun to do; Snowbird, Utah cold, but fun things to do, at least for those who ski on their heads like Martin Fowler tried on day one; and Anguilla in the Caribbean warm and fun, but time consuming to get to. In the end, Snowbird and skiing won out; however, a few people like Ron Jeffries want a warmer place next time.

The Agile Manifesto reads, in its entirety, as follows:

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
  • James Grenning
  • Robert C. Martin
  • Mike Beedle
  • Jim Highsmith
  • Steve Mellor
  • Arie van Bennekum
  • Andrew Hunt
  • Ken Schwaber
  • Alistair Cockburn
  • Ron Jeffries
  • Jeff Sutherland
  • Ward Cunningham
  • Jon Kern
  • Dave Thomas
  • Martin Fowler
  • Brian Marick

In 2001, the above authors drafted the agile manifesto. This declaration may be freely copied in any form, but only in its entirety through this notice.

The meaning of the manifesto items on the left within the agile software development context are:

Individuals and interactions – in agile development, self-organization and motivation are important, as are interactions like co-location and pair programming.
Working software – working software will be more useful and welcome than just presenting documents to clients in meetings.
Customer collaboration – requirements cannot be fully collected at the beginning of the software development cycle, therefore continuous customer or stakeholder involvement is very important.
Responding to change – agile development is focused on quick responses to change and continuous development.
Introducing the manifesto on behalf of the Agile Alliance, Jim Highsmith commented that the Agile movement was not opposed to methodology:

The Agile movement is not anti-methodology, in fact, many of us    want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used      information. We plan, but recognize the limits of planning in a    turbulent environment. Those who would brand proponents of XP or   SCRUM or any of the other Agile Methodologies as "hackers" are     ignorant of both the methodologies and the original definition of  the term hacker.
—Jim Highsmith, History: The Agile Manifesto

Agile principles
The Agile Manifesto is based on twelve principles:

  • Customer satisfaction by rapid delivery of useful software
  • Welcome changing requirements, even late in development
  • Working software is delivered frequently (weeks rather than months)
  • Working software is the principal measure of progress
  • Sustainable development, able to maintain a constant pace
  • 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—the art of maximizing the amount of work not done—is essential
  • Self-organizing teams
  • Regular adaptation to changing circumstances

Later, Ken Schwaber with others founded the Scrum Alliance and created the Certified Scrum Master programs and its derivatives. Ken left the Scrum Alliance in the fall of 2009, and founded to further improve the quality and effectiveness of Scrum.

In 2005, a group headed by Alistair Cockburn and Jim Highsmith wrote an addendum of project management principles, the Declaration of Interdependence, to guide software project management according to agile development methods.

In 2009, a movement spearheaded by Robert C Martin wrote an extension of software development principles, the Software Craftsmanship Manifesto, to guide agile software development according to professional conduct and mastery.


The term XP predates the term Agile by several years. XP stands for Extreme Programming, and is a suite of practices, principles, and values invented by Kent Beck in the late ‘90s. Nowadays the principles and values are not as well known, but the practices survive. Those practices are:

The Planning Game

Development proceeds in very short iterations, typically 1-2 weeks in duration. Prior to each iteration features are broken down into very small stories. Stories are estimated by developers and then chosen by stakeholders based on their estimated cost and business value. The sum of story estimates planned for the current iteration cannot exceed the sum of estimates completed in the previous iteration.

Whole Team

The team consists of developers, business analysts, QA, project managers, etc. The team works together in a lab space or open area where collaboration and communication are maximized.

Acceptance Tests

Stories and features are defined by automated tests written by the business analysts, and QA. No story or feature can be said to be done until the suite of acceptance tests that define it are passing.

Small Releases

Systems are released to production, or pre-production very frequently. An interval of 2-3 months is the maximum. The minimum can be once per iteration.

Continuous Integration

The whole system is built and tested end-to-end several times each day. While new tests are made to pass, no previously passing tests are allowed to break. Developers must continuously keep the system in a deployable state.

Collective Ownership

Code, and other work artifacts, are not owned by individuals. Any member of the team may work on any artifact at any time.

Coding Standard

Code, and other work artifacts, look as if they were written by the team. Each team member follows the team standard for format and appearance of the artifacts.


Names within code and other work artifacts are chosen to be evocative of the system being created.

Sustainable Pace

Building software is a marathon, not a sprint. Team members must run at a rate they can sustain for the long haul. Overtime must be carefully controlled and limited. Tired people do not win.

Pair Programming

Code and other work artifacts are produced by pairs of individuals working together. One member of the pair is responsible for the task at hand, and the other helps out. Pairs change frequently (every two hours or so) but responsibility stays with the owner.

Pair programming, an agile development technique used by XP.

The affordability of pair programming is a key issue. If it is much more expensive, managers simply will not permit it. Skeptics assume that incorporating pair programming will double code development expenses and critical manpower needs. Along with code development costs, however, other expenses, such as quality assurance and field support costs must also be considered. IBM reported spending about $250 million repairing and reinstalling fixes to 30,000 customer-reported problems . That is over $8,000 for each defect!

In 1999, a controlled experiment run by the second author at the University of Utah investigated the economics of pair programming. Advanced undergraduates in a Software Engineering course participated in the experiment. One third of the class coded class projects as they had for years – by themselves.
The rest of the class completed their projects with a collaborative partner. After the initial adjustment period in the first program (the “jelling” assignment), together the pairs only spent about 15% more time on the program than the individuals . Development costs certainly do not double with pair programming!
Significantly, the resulting code has about 15% fewer defects . These results are statistically significant.The initial 15% increase in code development expense is recovered in the reduction in defects,

There are many specific agile development methods. Most promote development, teamwork, collaboration, and process adaptability throughout the life-cycle of the project.

Test Driven Development

Developers are not allowed to write production code until they have written a failing unit test. They may not write more of a unit test than is sufficient to fail. They may not write more production code than is sufficient to pass the failing test. The unit tests are maintained and executed as part of the build process. No previously passing unit test is allowed to fail.


Code, and other work artifacts, are continuously reviewed and kept as clean as possible. It is not sufficient that code works; it must also be clean.

Simple Design

The simplest design that suffices for the task at hand, is the right design. More complex and general designs may become useful later, but not now. We do not wish to carry the weight of that complexity while it is not needed. Sufficient for the day are the complexities therein.

Iterative, incremental and evolutionary

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 cross-functional team working in all functions: planning, requirements analysis, design, coding, unit testing, and acceptance testing. At the end of the iteration a working product is demonstrated to stakeholders. This minimizes overall risk and allows the project to adapt to changes quickly. An iteration might 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. Multiple iterations might be required to release a product or new features.

Scrum Cycle

Scrum Cycle

Efficient and face-to-face communication

No matter what development disciplines are required, each agile team will contain a customer representative, e.g. Product Owner in Scrum. 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 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 (ROI) and ensuring alignment with customer needs and company goals.

Information Radiators

In agile software development, an information radiator is a (normally large) physical display located prominently in an office, where passers-by can see it. It presents an up-to-date summary of the status of a software project or other product. The name was coined by Alistair Cockburn, and described in his 2002 book Agile Software Development.A build light indicator may be used to inform a team about the current status of their project.

Very short feedback loop and adaptation cycle

A common characteristic of agile development are daily status meetings or “stand-ups”, e.g. Daily Scrum (Meeting). In a brief session, team members report to each other what they did the previous day, what they intend to do today, and what their roadblocks are.

Quality focus

Specific tools and techniques, such as continuous integration, automated unit testing, 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.

Compared to traditional software engineering, agile development is mainly targeted at complex systems and projects with dynamic, undeterministic and non-linear characteristics, where accurate estimates, stable plans and predictions are often hard to get in early stages, and big up-front designs and arrangements will probably cause a lot of waste, i.e. not economically sound. These basic arguments and precious industry experiences learned from years of successes and failures have helped shape Agile’s favor of adaptive, iterative and evolutionary development.

Adaptive vs. Predictive
Development methods exist on a continuum from adaptive to predictive. Agile methods lie on the adaptive side of this continuum. One key of adaptive development methods is a “Rolling Wave” approach to schedule planning, which identifies milestones but leaves flexibility in the path to reach them, and also allows for the milestones themselves to change. 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 cannot report exactly what tasks they will do next week, but only which features they plan for next month. When asked about a release six months from now, an adaptive team might be able to report only the mission statement for the release, or a statement of expected value vs. cost.

Predictive methods, in contrast, focus on analysing and planning the future in detail and cater for known risks. In the extremes, a predictive team can report exactly what features and tasks are planned for the entire length of the development process. Predictive methods rely on effective early phase analysis and if this goes very wrong, the project may have difficulty changing direction. Predictive teams will often institute a Change Control Board to ensure that only the most valuable changes are considered.

Risk analysis can be used to choose between adaptive (agile or value-driven) and predictive (plan-driven) methods

Iterative vs. Waterfall
One of the differences between agile and waterfall is that testing of the software is conducted at different stages during the software development lifecycle. In the Waterfall model, there is always a separate testing phase near the completion of an implementation phase. However, in Agile and especially Extreme programming, testing is usually done concurrently with coding, or at least, testing jobs start in early iterations.

After almost a decade of mismanagement and waste at the FBI, its CIO turned the agency’s maligned case management implementation into an agile project. Two years later, the system is live. This relative success, as well as the example of other federal agencies, shows that agile can work in Washington.

Not only that, the U.S. Government is serious about Agile. Not only is agile part of Federal CIO Steven VanRoekel’s “Future First” initiative, but the Government Accountability Office (GAO)  had issued a report on the federal government’s use of agile.

GAO identified 32 practices and approaches as effective for applying Agile software development methods to IT projects. The practices generally align with five key software development project management activities: strategic planning, organizational commitment and collaboration, preparation, execution, and evaluation. Officials who have used Agile methods on federal projects generally agreed that these practices are effective. Specifically, each practice was used and found effective by officials from at least one agency, and ten practices were used and found effective by officials from all five agencies.

Code vs. Documentation
In a letter to IEEE Computer, Steven Rakitin expressed cynicism about agile development, calling an article supporting agile software development “yet another attempt to undermine the discipline of software engineering” and translating “Working software over comprehensive documentation” as “We want to spend all our time coding. Remember, real programmers don’t write documentation.”

This is disputed by proponents of Agile software development, who state that developers should write documentation if that’s the best way to achieve the relevant goals, but that there are often better ways to achieve those goals than writing static documentation. Scott Ambler states that documentation should be “Just Barely Good Enough” (JBGE), that too much or comprehensive documentation would usually cause waste, and developers rarely trust detailed documentation because it’s usually out of sync with codes, while too little documentation may also cause problems for maintenance, communication, learning and knowledge sharing. Alistair Cockburn wrote of the Crystal method:

Crystal considers development to be a series of co-operative games, and the provision of documentation is intended to be enough to    help the next win at the next game. The work products for Crystal  include use cases, risk list, iteration plan, core domain models,  and design notes to inform on choices...however there are no       templates for these documents and descriptions are necessarily     vague, but the objective is clear, just enough documentation for   the next game. I always tend to characterize this to my team as:   what would you want to know if you joined the team tomorrow.
—Alistair Cockburn

Agile methods
Well-known agile software development methods and/or process frameworks include:

  • Adaptive Software Development (ASD)
  • Agile Modeling
  • Agile Unified Process (AUP)
  • Crystal Methods (Crystal Clear)
  • Disciplined Agile Delivery
  • Dynamic Systems Development Method (DSDM)
  • Extreme Programming (XP)
  • Feature Driven Development (FDD)
  • Lean software development
  • Scrum
  • Scrum-ban

Software development life-cycle support

The agile methods are focused on different aspects of the Software development life cycle. Some focus on the practices (e.g. XP, Pragmatic Programming, Agile Modeling), while others focus on managing the software projects (e.g. Scrum). Yet, there are approaches providing full coverage over the development life cycle (e.g. DSDM, IBM RUP), while most of them are suitable from the requirements specification phase on (FDD, for example). Thus, there is a clear difference between the various agile methods in this regard.

Agile practices
Agile development is supported by a bundle of concrete practices suggested by the agile methods, covering areas like requirements, design, modeling, coding, testing, project management, process, quality, etc. Some notable agile practices include:

  • Acceptance test-driven development (ATDD)
  • Agile Modeling
  • Backlogs (Product and Sprint)
  • Behavior-driven development (BDD)
  • Cross-functional team
  • Continuous integration (CI)
  • Domain-driven design (DDD)
  • Information radiators (Scrum board, Kanban board, Task board, Burndown chart)
  • Iterative and incremental development (IID)
  • Pair programming
  • Planning poker
  • Refactoring
  • Scrum meetings (Sprint planning, Daily scrum, Sprint review and retrospective)
  • Test-driven development (TDD)
  • Agile testing
  • Timeboxing
  • Use case
  • User story
  • Story-driven modeling
  • Velocity tracking

The Agile Alliance has provided a comprehensive online collection with a map guide to the applying agile practices.

This section explains how Primavera Systems, a vendor of project portfolio  management solutions, turned around its development organization in 2003. In  terms of value to the company, the development organization went from having low no confidence in its ability to deliver and repeated failure to meet expectations, to  being cheered for a release that was the hit of their user conference, with good  quality and twice the expected functionality. Bonuses were forthcoming for this  release. Magic? No, just leadership, hard work, and using a process that turned the  leadership and hard work into results. These are the Agile processes Primavera, a 21 year-old software company, sells project portfolio management  solutions to help firms manage all their projects, programs, and resources.  Primavera was thriving, and its growth was leading to increasingly complex client  needs; this put a strain on its ability to release a product that pleased its entire  customer base. Throughout 2002, the development organization worked overtime to  develop release 3.5. As with other projects in the past, the last three months were  particularly bad; the developers sacrificed weekends and home life to get the release  out with all of the new requirements. The result – a release seen by management as  incomplete and three weeks late, and an exhausted team with low morale.  Primavera decided to try the Agile development processes Scrum and XP to fix its  problems. Scrum is an overarching process for planning and managing development  projects, while XP prescribes individual team practices that help developers,  analysts, testers and managers perform at peak efficiency. Though they are often implemented separately, Scrum and XP are even more effective when implemented  together. Primavera adopted Scrum first to improve the way it managed product  development, then adopted XP practices to upgrade its product quality and then  customized the amalgam to suit its own needs.

The result of Primavera’s experiment is a highly satisfied customer base, and a  highly motivated, energetic development environment. Of equal value, everyone  within Primavera now has a process for working together to build the best releases  possible, and is aware of, and participates in, the tradeoff decisions involved. People  who haven’t had a chance to work together in years put their shoulders to making  each release a success, from CEO, CTO and VP’s to the entire development  organization. When the experiment started, Primavera was a very quiet, subdued  place to work. It now feels like a vibrant community.

“We pull in a lot of feedback from all of our customers and look for the similarities  across conversations with resource managers, functional managers, program  managers, and executives,” says Michael Shomberg, Primavera Vice President of  Marketing. “These methodologies are very empowering. Decisions are driven down to  where knowledge is applied. Decisions are better and communication back to the  customers is real and exciting. There are no over-promises or expectations that run  the risk of disappointment, because the customer sees on the screen what they had  in their head – or better. That’s the wow we want to experience, with our customers  and everyone in our company.”

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 determine a system development approach for a specific project situation through responsive changes in, and dynamic interplays between contexts, intentions, and method fragments.

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

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.

Mehdi Mirakhorli proposes a tailoring practice that provides a sufficient road-map and guidelines for adapting all the practices. RDP (rule-description-practice) Practice is designed for customizing XP. This practice, first proposed as a long research paper in the APSO workshop at the ICSE 2008 conference, is currently 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.

Sabre Airline Solutions adopted XP in 2001. With its new model, Sabre does iterative development in small, simple steps. The company uses two-week iterations, and customers see a new release every one to three months. Features, called “stories,” are expressed in user terms and must be simple enough to be coded, tested and integrated in two weeks or less.
Automated unit tests (against the programmer’s criteria) and broader acceptance tests (against customer requirements) must be passed at the end of each iteration before the next can begin. Unit and acceptance tests for each feature are written before the feature is coded. If a developer has trouble writing a test, he doesn’t clearly understand the feature.
Actual coding is done in pairs by teams in open labs, promoting collective ownership of code, although individuals sometimes do the simplest tasks. Programmers are re-paired frequently, often every day or two. They sign up for the tasks they want to do and the person they want to pair with.
Every project team has an “XP coach” and an application subject-matter expert called the XP customer. The XP customer stays in or near the programming lab all or most of the time. He decides on and prioritizes product features, writes the stories for programmers and signs off on the results.
“Refactoring” code—rewriting it not to fix bugs or add features but to make it less redundant and more maintainable—is strongly encouraged. Sabre says the concept hardly existed at the company before XP because it was too difficult.

Comparison with other methods

This section needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (August 2010)

Agile methods have much in common with the Rapid Application Development techniques from the 1980/90s as espoused by James Martin and others. In addition to technology-focused methods, customer-and-design-centered methods, such as Visualization-Driven Rapid Prototyping developed by Brian Willison, work to engage customers and end users to facilitate agile software development.


In 2008 the Software Engineering Institute (SEI) published the technical report “CMMI or Agile: Why Not Embrace Both” to make clear that the Capability Maturity Model Integration and Agile can co-exist. Modern CMMI-compatible development processes are also iterative. The CMMI Version 1.3 includes tips for implementing Agile and CMMI process improvement together.

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) score projects against a number of agility factors to achieve a total. The similarly named Agility Measurement Index, scores developments against five dimensions of a software project (duration, risk, novelty, effort, and interaction). Other techniques are based on measurable goals. Another study using fuzzy mathematics 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 (Nokia test, Karlskrona test, 42 points test).

While such approaches have been proposed to measure agility, the practical application of such metrics is still debated. There is agile software development ROI data available from the CSIAC ROI Dashboard.

Experience and adoption

One of the early studies reporting gains in quality, productivity, and business satisfaction by using Agile methods was a survey conducted by Shine Technologies from November 2002 to January 2003. A similar survey conducted in 2006 by Scott Ambler, the Practice Leader for Agile Development with IBM Rational’s Methods Group reported similar benefits. Others claim that agile development methods are still too young to require extensive academic proof of their success.

Large-scale and distributed Agile
Large-scale agile software development remains an active research area. Agile development has been widely seen as being more suitable for certain types of environment, including small teams of experts. 157 Positive reception towards Agile methods has been observed in Embedded domain across Europe in recent years

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

  • Large-scale development efforts (>20 developers), though scaling strategies and evidence of some large projects have been described.
  • Distributed development efforts (non-colocated teams). Strategies have been described in Bridging the Distance and Using an Agile Software Process with Offshore Development.
  • Forcing an agile process on a development team.
  • Mission-critical systems where failure is not an option at any cost (e.g. software for avionics).
  • The early successes, challenges and limitations encountered in the adoption of agile methods in a large organization have been documented.

Agile offshore
In terms of outsourcing agile development, Michael Hackett, senior vice president of LogiGear Corporation has stated that “the offshore team … should have expertise, experience, good communication skills, inter-cultural understanding, trust and understanding between members and groups and with each other.

Agile methodologies can be inefficient in large organizations and certain types of projects. Agile methods seem best for developmental and non-sequential projects. Many organizations believe that agile methodologies are too extreme and adopt a hybrid approach that mixes elements of agile and plan-driven approaches.

The term “agile” has also been criticized as being a management fad that simply describes existing good practices under new jargon, promotes a “one size fits all” mindset towards development strategies, and wrongly emphasizes method over results.

Alistair Cockburn organized a celebration of the 10th anniversary of the Agile Manifesto in Snowbird, Utah on February 12, 2011, gathering some 30+ people who’d been involved at the original meeting and since. A list of about 20 elephants in the room (“undiscussable” agile topics/issues) were collected, including aspects: the alliances, failures and limitations of agile practices and context (possible causes: commercial interests, decontextualization, no obvious way to make progress based on failure, limited objective evidence, cognitive biases and reasoning fallacies), politics and culture.

 As Philippe Kruchten wrote in the end:
The agile movement is in some ways a bit like a teenager: very     self-conscious, checking constantly its appearance in a mirror,    accepting few criticisms, only interested in being with its peers, rejecting en bloc all wisdom from the past, just because it is fromthe past, adopting fads and new jargon, at times cocky and arrogant. But I have no doubts that it will mature further, become more    open to the outside world, more reflective, and also therefore moreeffective.

Applications Outside of Software Development
Agile methods have been extensively used for development of software products and some of them use certain characteristics of software, such as object technologies.[54] However, these techniques can be applied to the development of non-software products, such as computers, motor vehicles, medical devices, food, and clothing; see Flexible product development.

Agile development paradigms can be used in other areas of life such as raising children. Its success in child development might be founded on some basic management principles; communication, adaptation and awareness. Bruce Feiler has shown that the basic Agile Development paradigms can be applied to household management and raising children. In his TED Talk, “Agile programming — for your family”, these paradigms brought significant changes to his household environment, such as the kids doing dishes, taking out the trash, and decreasing his children’s emotional outbreaks which inadvertently increased their emotional stability. In some ways, agile development is more than a bunch of software development rules; but it can be something more simple and broad, like a problem solving guide.