Traditionally, software development projects started out with an idea and then tried to identify all the requirements needed to make that idea "complete" for the intended users. This long process was expensive (and sometimes ended in a “no-go” decision only after a great deal of money was spent) and did not place enough emphasis on value returned for the investment made. Agile has a tool that can help organizations re-focus on return on investment: value-driven user stories. Value-driven user stories are created specifically to link features with their users and the value the features have for their users. They can be created from a list of high-level features or a list of values and users centered on a general idea.

It has been argued that agile methods only work for small, collocated, self-directed teams that include on-site customers. But what if your customer cannot be on-site full-time, or your development team is distributed around the world, or your developers lack self-directed team skills? Does this mean you cannot take advantage of agile methods? This article presents a case for using key agile practices along with recommended extensions on a broader range of projects, including large and physically distributed efforts. The article motivates the use of agile methods by exposing common myths and providing information that can help managers and customers facilitate practical agility within their organizations.

This compilation of three brief articles by IBM Rational thought leaders describes how the IBM Rational Unified Process, or RUP, is not only "agile" in its own right, but also encompasses much of the guidance teams need to scale agile techniques successfully.

This overview helps project management and teams in selecting the best iterative method(s) for their projects, based on the major risks they want to tackle. The overview highlights the focus of the different methods, ie. which risks are mainly addressed. This is not a detailed course on all the methods, but references to literature are provided.

With so many Continuous Integration (CI) servers to choose from, it can be difficult to decide which one is right for you. This article looks at a handful of open source CI servers, including Continuum, CruiseControl, and Luntbuild, using a consistent evaluation criteria and illustrative examples.

The idea of driving development with tests has been popularized by the agile development movement. The fact is that testing and coding are inseparable components of software development. We get the best results with testers and programmers work closely together. How can we deliver real value to the business frequently? How can we know how much testing is enough? Let’s look at how testers and programmers collaborate to produce high-quality software.

While Continuous Integration (CI) can be extremely effective at reducing risks on a project, it requires a greater emphasis on your day-to-day activities related to coding. In this installment of Automation for the people , automation expert Paul Duvall, lays out a series of CI anti-patterns, and more importantly, shows how to avoid them.

In the past few years there's been a blossoming of a new style of software methodology - referred to as agile methods. Alternatively characterized as an antidote to bureaucracy or a license to hack they've stirred up interest all over the software landscape. This essay explores the reasons for agile methods, focusing not so much on their weight but on their adaptive nature and their people-first orientation.

This article takes the form of a tale to explain the differences between the different "driven development" approaches... and makes us think why there are so many of them?

Does an agile software development process require real organizational change or can an existing organization become more agile? How do the many traditional information technology (IT) roles such as the business analyst, architect, and tester become a more integrated part of an agile process? Some recent work [1] debunks the myths that agile processes require on-site customers, produce ad-hoc requirements and design, and cannot scale to large projects. This article furthers this work by introducing innovative techniques from a new agile process developed and used by projects within Microsoft. These techniques span the traditional IT roles such as the business analyst, project manager, architect, developer, tester, and release manager.