> Home    > About Us    > Services    > Products    > Help    > Demos    > Contact Us
 Privacy  Terms  Login
 > Home
 > About Us
 > Services
 > Products
 > Help
 FAQ
 Glossary
 Site Map
 Webmaster Training
 > Demos
 > Contact Us
Progma Web Design - e-commerce and e-business solutions for Chicago and beyond

Frequently Asked Questions - IT Consulting

What are agile processes?

The goals of agile processes are the same as the goals of all processes and methodologies, to improve project success by: ensuring business objectives are met, increasing productivity, ensuring high quality, reducing time to market, and reducing risk.

There are three main categories of techniques that can be used to control a project:

1. Pre-definition and pre-planning
2. Handling change and uncertainty
3. People, teams, and communication

Traditional processes concentrate on pre-definition - before doing something, work out what you are going to do and write it down. These techniques have many advantages, such as identifying issues up front, enabling external review, and high-level visibility of progress and quality.

Pre-definition is an essential tool for managing many types of projects, such as construction work, where the cost of building is much greater than the cost of modeling, changes are difficult to incorporate later on, low-level tasks are highly predictable and require little creativity, different groups of people with a wide range of specialist skills need to be coordinated, and there is an inherent order to the tasks which have to be carried out.

Historically, software development methodologies are derived directly from large-scale military construction. But software developments projects do not (or need not) have any of the above characteristics. This mismatch is evidenced by the unacceptably high number of software projects, which fail.

Agile processes emphasize the other two categories of techniques. Rather than trying to remove change and uncertainty, they accept them as inherent and provide better mechanisms to achieve the required objectives. Rather than trying to make success independent of people, they recognize their importance and seek to utilize their creativity and encourage self-reliance. Even on traditionally-run projects it has been found that these techniques correspond much more closely with project success than adherence to the in-place methodology.

What is the Relationship between Agile and Extreme Programming?

Extreme Programming (XP) is a specific, documented approach to the software development process. "Agile" refers to a family of approaches, of which XP is an example. Other well-known examples are:

Scrum
DSDM
Feature Driven Design (FDD)

These approaches are all based on the precept that traditional IT methodologies do not adequately address the main factors contributing to project success, such as team dynamics, communication mechanisms, feedback, handling uncertainty and change. Furthermore, they assert that traditional methodologies add an unnecessary overhead that can contribute directly to project inefficiencies and failure - such methodologies are therefore described as "heavy-weight".

In February 2001 the main exponents of these new approaches met to understand how their individual processes overlapped, and to remove some of the confusion arising for newcomers to the area caused by the range of "competing" approaches on offer. The term "Agile" was agreed on at this time as an umbrella name (although it should be noted that the benefits of these processes are more than just the ability to handle change).

The group became the agile alliance, a group of individuals, organizations, and companies who subscribe to and promote the principles embodied in the Agile Manifesto .

What is Special about Extreme Programming?

Agile processes in general are about how to manage the software develop process to make projects more successful. Extreme Programming (XP) is unique in that it incorporates techniques, which are specific to the development activity itself.

These techniques address one of the major problems with incremental delivery: working and tested code has to be continually modified. For this reason XP, while usable as a full process in its own right for small projects, has also been integrated with other agile processes such as Scrum (see www.controlchaos.com) and DSDM (www.dsdm.org ) for tackling larger projects.

XP (Extreme Programming) is only one example of a family of new approaches to software development that are collectively termed "agile". However, XP has received the lion's share of the headlines, generated the fiercest debate, and has the largest adoption profile. Furthermore, XP is now being used alongside other agile approaches, rather than in competition (see scrum and XP, DSDM and XP). What makes XP stand out from the crowd is that it incorporates a technique which could be as profound for the way that code is written as the introduction of object-oriented techniques was in the 1980s. The technique in question is Refactoring, which is incorporated into the more fully developed technique of Test-Driven Design.

Does an Agile project cost more or less?

An agile project should cost less.

Some agile practices will clearly add to the cost. Pair programming in Extreme Programming is an obvious example. Incremental delivery can also add to the cost, through changing existing code, additional testing, and supporting early releases.

These costs should be more than offset by savings elsewhere. It is inherent in a 'light-weight' process that overheads are reduced, such as producing detailed up-front documentation, and its subsequent maintenance. Management overhead in particular should be significantly reduced. Any investment in quality, such as pair programming, regression testing, keeping the design consistently high (refactoring), continuous integration, and eliciting user feedback, should all provide returns in the later stages of the project.

However, the major cost savings are derived by simply implementing less functionality. An analysis of any application, which is specified up-front, will identify a percentage of functionality, which is never or seldom used. Indeed, it can be argued that there is a need when defining requirements to build in a safety margin - to leave out a function that might be important would be unprofessional.

In our experience, as a conservative estimate, non-essential functionality can account for upwards of 30% of an applications cost, taking into account its impact on such things as complexity, performance, and usability.

How do you estimate an agile project?

Estimating an Agile project is similar to producing a budgetary estimate for any project. A short scoping exercise is used to produce a high-level costing which is refined over time.

Agile techniques differ in that:
  • More emphasis is placed on the impact of team issues
  • Higher levels of communication and feedback are incorporated during the estimation process (for example, holding planning workshops, including on-the-fly estimation to help guide thinking)
  • The principles of prioritization would be adopted to keep focus on the key issues
  • Detailed task and dependency planning are not considered useful, as task definition, assignment, and interaction are much more fluid
  • Any decisions made to support the estimation process would not be imposed upon the resultant work

Generally, agile projects would not propose doing any more detailed top-down estimation. The degree of uncertainty across the whole set of project parameters is difficult to predict and cannot be fully eradicated by prior analysis.

Agile processes accept the inherent uncertainty of estimates. They propose that effort and process is better spent making sure the error does not cause project failure (through prioritization and feedback) rather than trying to increase the accuracy.

Can I use Agile on a fixed price project?

Yes. Fixed price projects typically involve developing a system to a fixed budget against a detailed scope with the developer holding the contingency and assuming the majority of the development risk. As such, this disables the ability to invoke one of agile's most powerful benefits - flexibility of scope.

The techniques that can bring about the largest benefits for a project involve developing the simplest system possible to meet the users' requirements. As these requirements evolve over the life of the project, agile techniques allow a development to capture and embrace this change as it happens. By trying to capture every requirement at the start of the project and then minimize change throughout a development lifecycle, fixed price projects work against this agility.

However, many other agile techniques can still bring benefit within a traditional fixed price approach. Techniques such as pairing, test driven design and others encourage communication between team members and greatly increase quality, ultimately reducing the overall lifetime costs for a system.

If a new project is being considered there are other commercial models that work to an agreed budget, but without the constraints of a full fixed price environment.

How do you control an agile project?

Agile projects use small iteration cycles to provide early and frequent feedback on real progress.

The feedback concentrates on what is completed, to a releasable standard. This makes the quality of information much higher than on traditional projects where the criteria for 'completion' of an interim task are more subjective - when is a specification complete?

The tasks carried out within each iteration of an agile project are broadly constant. Information gathered for any one iteration can therefore be used to effectively improve subsequent iterations. The manager has the choice of level at which to monitor and intervene in the project. At the end of each iteration if progress is less than anticipated then he may choose to monitor closely within an iteration, although this is not usually required.

The short iteration cycles mean that problems cannot remain 'hidden' for long periods of time. If more immediate information is required management can easily 'dip' into the development cycle within an iteration. Daily Scrum meetings and feedback from pair programming provide clear indications as to the current state of iteration. Additionally experience suggests that teams with collective responsibility, as engendered through agile, are more likely to communicate issues upwards.

Back to the previous page 
Web site design and web development, Internet and Intranet applications
 > Site map  > Home     > About Us     > Services     > Products     > Help     > Demos     > Contact Us

Website Design, Web Applications Development - Progma, Inc. - serving Greater Chicago since 1994
Located in Deerfield, Illinois - just 25 miles north of downtown Chicago
© 2006, Progma, Inc.